Raul Miller-4 wrote:
>
> On Thu, Nov 27, 2008 at 10:23 AM, Tracy Harms <[EMAIL PROTECTED]> wrote:
>> My take on the matter is this: Amb involves closures. J does not.
>>
>> http://www.jsoftware.com/jwiki/Guides/Lexical_Closure
>
> It might, if that were made a part of the spec.
> [...]
> Also, as Oleg points out on that page, J's locales can
> be used to implement lexical closures. So I am not
> sure why I should agree with your "J does not." claim.
> [...]
>
But the truth is that the Graham's accumulator-generator problem can
be solved without any resort to lexical closures. One such solution,
based on the Burke's solution from the link above but without
cocreate is:
G =: 1 : 0
n=.'n',":?10000000000x
(n)=:m
3 : (n,'=:',n,'+y')
)
Generators are fundamental objects, like functions, but different,
and G is essentially based on the fact that ? is a generator of different
numbers.
Btw, What Graham is forgetting to mention is the whole history of the
problem
of closures in (Un)common LISP('s), and theirs relation to the functional
programming. So do you when you write:
> [...] monads are just syntactic sugar for how
> you write function arguments. The trick is that (for
> example) Haskell's IO monad involves a compiler
> based "cheat" that treats external data sources as if
> they were mathematical arguments. This would not
> have to be a "cheat" if the language were specified
> differently.
>
which does not mention that, in fact, monads are exactly
the solution to the problem of how to introduce statefull
functions (or, in other words, side-effects) into a pure-functional
language.
Let me put this whole n-decades old history differently, in the
present context, in reply to:
> Also, it's quite reasonable to treat both adverbs and
> conjunctions as functions.
>
Is then G (which is an adverb) also a higher-order function that
maps numbers into functions? Let's see:
(0 G) -: 0 G
─┬─┬──────────────────────────┐│-:│┌─┬─┬──────────────────────────┐│
││3│:│n6971708535=:n6971708535+y││ ││3│:│n3429567695=:n3429567695+y││
│└
Now we notice this: while
(0 G) -: 0 G
can always be assumed to be equal 1, the value of this
expression that we actually get from the J interpreter will be 1
only if the two "dummy" variables nxxxxx and nyyyyy have the same
value at the moment of the evaluation of the expression.
Then,
0 G
both is and it is not equal to itself, depending on rather subtle
issues related to the semantics of side-effect evaluations. Just like
in LISP some 20+ years ago.
While Common LISP kept some balance between various programming
paradigms like no other language around did, we should also notice
that the Common LISP's super-elegant solution:
(defun(n)(lambda(a)(incf n a)))
is also a nightmare from the viewpoint of functional programming,
because the language is defined such that lambda function is only
sometimes function, and sometimes it is generator. But a generator
that requires little effort on programmer's part to implement, even if it
is all the same a theoretical monstrosity.
--
View this message in context:
http://www.nabble.com/Rosetta-Codes%3A-Amb-operator-tp20682749s24193p20742851.html
Sent from the J Programming mailing list archive at Nabble.com.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
