I understand your point of view. However, personally, I like to comply as
much as possible with the specifications. A combinator has no free
variables; that is, variables visible outside the enclosing functions; for
example, in λ-calculus the expression,
(λx.f(x x))(λx.f(x x))
is not closed because f is a free variable visible outside the enclosing
functions. In contrast,
Y = λf.(λx.f(x x))(λx.f(x x))
is stateless (i.e., λf.(λx.f(x x))(λx.f(x x)) is closed) and it is a
combinator ("A combinator is a closed lambda expression, meaning that it
has no free variables.").
Furthermore, "In programming languages that support anonymous functions
[such as J], fixed-point combinators allow the definition and use of
anonymous recursive functions, i.e. without having to bind such functions
to identifiers. In this setting, the use of fixed-point combinators is
sometimes called anonymous recursion." Therefore, if a Y's product,
>> t=. almost_fibonacci Y
>>
>> t 10
>> 55
>>
>> erase'almost_fibonacci'
>> 1
>> t 10
>> |value error: almost_fibonacci
>> | (5!:1<'g') u y
relies on binding a function to an identifier then I would not call it
anonymous recursion.
It seems to me that, by including a stateless version of Y (arguably, the
one without Defer), which nevertheless produces verbs which are not
stateless, you stopped halfway.
In any case, I guess, there is no much harm since interested readers can
realize that the general non-tacit and the tacit versions are fully
stateless and both implement anonymous recursion in J.
On Tue, Dec 4, 2018 at 11:27 AM Raul Miller <[email protected]> wrote:
> On Mon, Dec 3, 2018 at 6:49 PM Jose Mario Quintana
> <[email protected]> wrote:
> > > Ok, I now see what you are saying.
> > >
> > > And, I've updated the rosettacode explicit implementation of the
> > combinator.
> > >
> > > Thanks,
> >
> > You are welcome.
> >
> > I also added my non-tacit version(s) of the Y combinator there.
> >
> > I would suggest for the explicit version to leave only the form,
> >
> > Y=:2 :0(0 :0)
> > NB. this block will be n in the second part
> > :
> > g=. x&(x`:6)
> > (5!:1<'g') u y
> > )
> > f=. u (1 :n)
> > (5!:1<'f') f y
> > )
> >
> > and forget about Defer; otherwise, Defer could be regarded as a "free
> > variable" and Y would no longer be considered to be a combinator
> (actually,
> > that was my original point).
>
> I think that that approach would detract from the exposition, and make
> i even more difficult for relative newcomers to J to digest (a bulk of
> the rosettacode audience are not J veterans - even if we limit our
> scope to people with an interest in J).
>
> Also, as far as I know, there's nothing in the definition of
> "combinator" which states that they cannot be built out of other
> "combinators". (Is there something I've overlooked here?) But even if
> there was, at most this would require a relabelling of the definition
> which depends on Defer.
>
> Remember that the primary point of the rosettacode site is to
> communicate with people - to convey how ideas represented in one
> programming language carry over to other programming languages.
>
> Thanks,
>
> --
> Raul
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
