Talk:Anonymous recursion: Difference between revisions
m
→Task description is a bit childish
(Trying to squeeze my comments into this overly long talk page.) |
|||
| (11 intermediate revisions by 5 users not shown) | |||
Line 185:
:: Is there something I'm doing wrong? The above version of 'fib' just returns its argument. --[[User:Abu|Abu]] 09:15, 12 January 2011 (UTC)
::: You probably used Ruby 1.8, while I used Ruby 1.9. They changed the rules for when a block parameter has the same name as a variable outside the block. I misunderstood the rules for Ruby 1.8, and wrote a recursive singleton method, when a recursive block would have worked. --[[User:Kernigh|Kernigh]] 04:04, 11 February 2011 (UTC)
:::: Make sure you use the {{tmpl|works with}} template to document which version of Ruby is required. Let's ''capture'' that information properly instead of leaving it languishing in a comment on a talk page! –[[User:Dkf|Donal Fellows]] 10:45, 11 February 2011 (UTC)
:Concerning "recursion implies a function", it depends on what you consider a function. The GOSOB in the Basic code snippet is not really a function call. That's why I used the term "call" instead of "function". A Forth solution would involve two or three new immediate control words, similar to BEGIN/WHILE/REPEAT. In the PicoLisp version (and also in your second Ruby version, if I understand it right), the first pass through the 'recur' body does not actually involve a function call, but it is executed in the context of the surrounding function. --[[User:Abu|Abu]] 07:57, 9 January 2011 (UTC)
Line 194 ⟶ 195:
* Ruby is different from PicoLisp here: the first pass through the 'recur' block really is a function call! For example, <tt>recur { recurse }</tt> would be an infinite loop (until I run out of memory, with a very long stack trace), but <tt>recur { next 5; recurse }</tt> would return 5, because 'next' is the Ruby keyword to return from a block.
* I cannot find the difference between an ''invisible function'' and a ''function-that-is-not-considered-a-function''. If the wrong solutions use the invisible functions, and the correct solutions use the functions that are not considered functions, then I cannot know whether each solution is correct or wrong! --[[User:Kernigh|Kernigh]] 04:04, 11 February 2011 (UTC)
== Clarity needed - Confusion between task and examples ==
: While some of this stuff, including article on WP which are marked needing expert help, aren't the easiest to understand, it seems that a number of the examples are probably/maybe incorrect (I don't claim to understand all the solutions).
:# [[wp:Fixed_point_combinator]]
:# [[wp:Anonymous_function]]
:# [http://stackoverflow.com/questions/156369/which-languages-support-recursive-function-literals-anonymous-functions] discussion on stack-overflow --[[User:Dgamey|Dgamey]] 22:58, 20 July 2011 (UTC)
:Examples that look like simple recursion no hidden function, no function not bound to an identifier (per #2).:
:* AutoHotkey, Forth
:Forth is already marked incorrect. I think AutoHotKey should be too.
:Examples with nested functions (do these really qualify, maybe but not sure):
:* Ada, C, C++, Common Lisp, F# (one example), Factor, Nemerle, Unix shell
:Nested functions and binding to a local variable seem equivalent on one level, so maybe nested functions are fine.
:--[[User:Dgamey|Dgamey]] 22:01, 20 July 2011 (UTC)
:: It seems that the task just wants the recursive function not polluting global namespace. The AutoHotkey and Forth examples are definitely incorrect. For the nested functions, it depends on if a nested function is visible outside of the scope or not. In most languages it shouldn't be, but not always: if you define a Perl5 function nested inside another function, it's still in the package namespace, not the lexical one. For your list:
::# Ada I don't know;
::# C nested function is not visible outside as demonstrated (I wrote it);
::# C++ nested class definition (actual_fib) is not visible outside;
::# Common Lisp nested defun (fib1) is not visible;
::# F# fib2 is not visible;
::# Factor I have no idea what it's doing, but I guess it effectively creates a one-time eval-ish function to do the recursion; if so it would be ok;
::# Nemerle does some handwaving, I don't know the actual effect;
::# Unix shell creates a subshell which aims to not pollute the namespace in parent ''process'', but it does pollute the namespace in the same ''source file''. I would say it's not ok. Then again, you don't tend to write very large programs in shell script, so it's probably moot.
::--[[User:Ledrug|Ledrug]] 22:44, 20 July 2011 (UTC)
:: Your observation of "not polluting the global name space" seems to me to be spot on on how this is being interpreted and implemented. But I'm not certain that I know enough about the task author's intent to say. That raises the question, should the task be changed? Clarified? Renamed? Both? Should implementations be marked incorrect? Given the number of solutions in place, the last choice is not one I'd take. If the intent was missed change the task and if desired create a draft with a better description of the intent with clearer guidelines. --[[User:Dgamey|Dgamey]] 23:02, 20 July 2011 (UTC)
::: This was created by Abu in November - can you way in.
:::: Well, the author listed 3 disadvantages, the first two are about the namespace issue; the third one is, IMO, bogus, because immediately after saying "interrupting program flow", the Y combinator is suggested, which interrupts code flow like there's no tomorrow. I think most examples are fine, although some are doing the task for the task's sake (such as the Go Y combinator solution) with no practical benefit. As it stands, maybe only a few examples need to be marked incorrect, while others do show some useful techniques. It never hurts to clarify the task, though. --[[User:Ledrug|Ledrug]] 23:27, 20 July 2011 (UTC)
== Task description is a bit childish ==
While I think the task is interesting, as a few languages permit this directly or at least clean workarounds, the arguments given are not very serious:
* ''You have to think up a name, which then pollutes the namespace'': if thinking up a name is a problem, consider another activity.
* ''Function is created which is called from nowhere else'' : It's called once. For some functions, it's enough to justify them. If it's really a problem, many languages have a way to make a function invisible from outside a given scope (for instance nested functions, static functions or namespaces), and even if there is no such thing, it's easy to add som prefix that make it very clear the function has "internal purpose".
* ''The program flow in the source code is interrupted'': that's the point of any flow control structure, and any function call. Again, if it's a problem, consider another activity.
I understand that making a program readable is important (it's one of my top priorities when writing programs, because I know ''I'' won't be able to maintain the program otherwise). However, it's silly to invent a problem where there is not really one. Thinking up a name and taking care of the program flow are basic tasks. Recursion is not adding complexity here. On the contrary, it usually simplifies things.
[[User:Eoraptor|Eoraptor]] ([[User talk:Eoraptor|talk]]) 15:19, 3 March 2019 (UTC)
| |||