On a related note, lambda syntax is not really simple.
Consider:
((lambda (x y) (+ x y)) 2 3)
5
There are four left parenthesis here, and counting from left to right:
The first left parenthesis marks the beginning of a function
application (what a J programmer might call a noun phrase).
The second left parenthesis marks the beginning of a function
definition (what a J programmer might call a verb phrase).
The third left parenthesis marks the beginning of an argument list (J
uses implicitly named arguments or unnamed arguments, but you can
achieve something analogous on the left hand side of =:)
The fourth left parenthesis marks the beginning of a function definition.
So what's the consistent system here?
On a related note, (lambda (x y) (+ x y)) by itself would still be a
function definition. However, (x y) by itself would not be an argument
list.
To make sense of this all you have to introduce another level of
abstraction (which might be called a macro system). And this is a
slippery slope which carries with it all sorts of other implications.
Anyways, "lambda" is a leaky abstraction - I guess maybe all
abstractions leak to some degree.
That said... I started working on an sexpr parser, and I ran into what
looks like an interpreter bug:
LPAR=: {.;:'('
RPAR=: {.;:')'
parsexpr=:3 :0
tokens=:;:y
({.tokens) parsexpr }.tokens
:
if. x-:LPAR do.
assert. 0<#y
'a d'=. t=.({.y) parsexpr }.y
smoutput t
assert. ({.d)-:RPAR
d=.}.d
if. #d do.
(<a),<({.d) parsexpr }.d
else.
a:
end.
else.
if. 0<#y do.
if. ({.y)-:RPAR do.
smoutput t=.(x,a:),&< y
t return.
else.
x,<({.y) parsexpr }.y
end.
else.
x
end.
end.
)
parsexpr '((lambda (x y) (+ x y)) 2 3)'
┌────┬─────────────────────┐
│┌─┬┐│┌─┬─┬─┬─┬─┬─┬─┬───┬─┐│
││y││││)│(│+│x│y│)│)│2 3│)││
│└─┴┘│└─┴─┴─┴─┴─┴─┴─┴───┴─┘│
└────┴─────────────────────┘
┌─┬────────────────────────────┐
│x│┌────┬─────────────────────┐│
│ ││┌─┬┐│┌─┬─┬─┬─┬─┬─┬─┬───┬─┐││
│ │││y││││)│(│+│x│y│)│)│2 3│)│││
│ ││└─┴┘│└─┴─┴─┴─┴─┴─┴─┴───┴─┘││
│ │└────┴─────────────────────┘│
└─┴────────────────────────────┘
|assertion failure: parsexpr
| ({.d)-:RPAR
Now I feel sad.
--
Raul
On Sun, Feb 1, 2015 at 6:30 PM, Jose Mario Quintana
<[email protected]> wrote:
> There are, in my mind, at least two potential reasons:
>
> 0. Quoting code can be annoying (when quoting quoted code, etc.) but the
> quoted code becomes a noun and fits within the current relatively simple
> parsing rules mold. It is virtually certain that balanced symbols could be
> used to implement a modified explicit syntax ( see,
> http://www.jsoftware.com/pipermail/programming/2009-December/017425.html );
> but, new punctuation and parsing rules would have to be introduced.
> Arguably, lambda style syntax could also be implemented but it would
> require even more complications.
>
> 1. Lambda style syntax is unnecessary for tacit programming (functional
> programming without reference to argument names). Backus himself noted
> that APL introduced new functional forms which do not depend on lambda
> expressions. J enriched the functional forms further and the tacit dialect
> for programming verbs became, at some point, Turing complete.
>
> In addition, adverbial tacit programming is also complete in the sense that
> any explicit adverb can be rewritten tacitly. However, sometimes the tacit
> writing of very simple adverbs seems tedious to me, even with the use of
> black magic (that is, by blurring the orthodox distinction between verbs,
> adverbs and conjunctions), when compared to a lambda style syntax; it can
> be done easily but is an overkill akin of using J to compute 2 + 3 % 4.
>
> Thus, recently I decided to write my own tacit lambda adverb for a certain
> kind of J expressions using an unofficial extended version of the
> interpreter (not released yet). Lambda is an adverb that takes a variable
> number of arguments in strand notation (an n-tuple, so to speak, in
> Pascal's (extended) terminology). The following is a tease, suppose that
> we would like to produce the form <@:v u} ]
>
>
> JVERSION
> Installer: j602a_win.exe
> Engine: j701/2012-12-06/12:20/x
> Library: 6.02.023
>
> It can be done sequentially,
>
> v0 [: v (<@:v u} ]) lambda NB. u is free, v is bound
> <@:v0 u} ]
>
> u0 [: u v0 [: v (<@:v u} ]) lambda lambda NB. both u and v are bound
> <@:v0 u0} ]
> 0 [: u < [: v (<@:v u} ]) lambda lambda NB. both u and v are bound
> <@:< 0} ]
>
> Or all at once,
>
> u0 v0 [: u v (<@:v u} ]) lambda
> <@:v0 u0} ]
> 0 ^ [: u v (<@:v u} ]) lambda
> <@:^ 0} ]
>
> h=. [: u v (<@:v u} ]) lambda NB. It does not have to be
> anonymous
>
> 0 ^ h
> <@:^ 0} ]
>
> u v h
> <@:v u} ]
>
> Counting [:, lambda in the expression ([: u v (<@:v u} ]) lambda) is a
> quadruple adverb that produces a double adverb (h) but lambda can take many
> arguments.
>
> Now, it is kick-off time!
>
>
> On Tue, Jan 27, 2015 at 1:24 PM, Tobia Conforto <[email protected]>
> wrote:
>
>> I, for one, found Raul's solution an interesting challenge to decode by
>> myself, purposely not looking at his explanation until I had cracked it
>> myself.
>>
>> Coming from a traditional and functional programming background, with some
>> recent APL study, I find explicit definitions much easier to understand
>> than J's verb trains. I still don't understand the philosophical reason why
>> J won't have a nice lambda syntax, analogous to {…} in modern APL or the
>> countless variations of (lambda …) or function() {…} in other languages.
>>
>> It would make it easier to nest function definitions, avoid unnecessary
>> string escaping, and introduce nested local (lexical) scoping, something
>> that seems conspicuously missing in J to my novice eyes. I'm sure there is
>> a reason, but I cannot see it yet. I get that { and } were too valuable as
>> standalone characters, but then I'm sure the authors could have found a
>> different pair of balanced symbols to use for this purpose, if they wanted.
>>
>>
>> On Tue, Jan 27, 2015 at 3:43 PM, Raul Miller <[email protected]>
>> wrote:
>>
>> > Are you asking for this?
>> >
>> > f=:13 :'y </.~ +/\ t * _1 |. t=. y ~: {.;:''&'''
>> >
>> > Thanks,
>> >
>> > --
>> > Raul
>> >
>> > On Tue, Jan 27, 2015 at 4:22 AM, Linda Alvord <[email protected]>
>> > wrote:
>> > >
>> > >
>> > > Here's a challenge:
>> > >
>> > >
>> > >
>> > > Just because @ might show up in third grade, that doesn't include all
>> its
>> > > little cousins like @: & and &:
>> > >
>> > >
>> > >
>> > > To me, minimal documentation begins with the data using capital letters
>> > for
>> > > the name. Since F is not a verb, don't start here.
>> > >
>> > >
>> > >
>> > > F=: </.~ +/\@(-.@+._1&|.)@:=&(<,'&')
>> > >
>> > >
>> > >
>> > > Also it is a very tangled verb:
>> > >
>> > > 5!:4 <'F'
>> > >
>> > > -- ~ --- /. ---- <
>> > > │ -- \ --- / --- +
>> > > │ │
>> > > │ │ -- -.
>> > > --+ -- @ -+ -- @ -+- +.
>> > > │ │ │ │
>> > > │ -- @: --+ L-----+ -- _1
>> > > │ │ │ L- & -+- |.
>> > > L- & -+ L- =
>> > >
>> > >
>> > >
>> > > Begin here with the data:
>> > >
>> > > L- <,'&'
>> > >
>> > > ]T=: ;:'4&count int 3 8&inrange'
>> > >
>> > > --T-T-----T---T---T-T-------┐
>> > > │4│&│count│int│3 8│&│inrange│
>> > > L-+-+-----+---+---+-+--------
>> > >
>> > >
>> > >
>> > > Here's the challenge. Just for fun, write a single line direct
>> > definition of
>> > > F. Use simple J. You may use @ and name the verb f.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > f=: 13 :' (direcct defn) '
>> > >
>> > > f T
>> > >
>> > > ------------T-----T---------------┐
>> > > │--T-T-----┐│----┐│----T-T-------┐│
>> > > ││4│&│count│││int│││3 8│&│inrange││
>> > > │L-+-+------│L----│L---+-+--------│
>> > > L-----------+-----+----------------
>> > >
>> > >
>> > >
>> > > Apply f to T to get the result.
>> > >
>> > >
>> > >
>> > > That is usually enough information for sending a question to the forum.
>> > > Advanced programmers could use tacit verbs like Pascal's verb. Often
>> you
>> > can
>> > > only explain these parts in words. Having a sample of your data and an
>> > > indication of whether you are planning one or two arguments for your
>> verb
>> > > will help.
>> > >
>> > >
>> > >
>> > > Linda
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Message-----
>> > > From: [email protected]
>> > > [mailto:[email protected]] On Behalf Of Cliff
>> > Reiter
>> > > Sent: Monday, January 26, 2015 3:46 AM
>> > > To: [email protected]
>> > > Subject: Re: [Jprogramming] A parsing challenge
>> > >
>> > >
>> > >
>> > > Lovely. Tiny remark:
>> > >
>> > >
>> > >
>> > > <mailto:-.@> -.@+. could be replaced by +:
>> > >
>> > >
>> > >
>> > > On 1/26/2015 1:00 AM, Raul Miller wrote:
>> > >
>> > >> A note of explanation...
>> > >
>> > >>
>> > >
>> > >> (I have been noticing that far too much software is poorly documented.
>> > >
>> > >> And while I cannot do an adequate job of documenting other people's
>> > >
>> > >> software, I can document software I write.)
>> > >
>> > >>
>> > >
>> > >> F=: </.~ +/\@( <mailto:-.@+._1&;|.)@:=&(%3c,'&')>
>> > > -.@+._1&|.)@:=&(<,'&')
>> > >
>> > >> T=: ;:'4&count int 3 8&inrange'
>> > >
>> > >>
>> > >
>> > >> The first thing I do is find out where & appears:
>> > >
>> > >> =&(<,'&') T
>> > >
>> > >> 0 1 0 0 0 1 0
>> > >
>> > >>
>> > >
>> > >> The second thing I do is rotate to the right and combine:
>> > >
>> > >> (+. _1&|.) =&(<,'&') T
>> > >
>> > >> 0 1 1 0 0 1 1
>> > >
>> > >>
>> > >
>> > >> Except I want to mark the beginning of each section with a 1, and
>> > >
>> > >> right now they are zeros.
>> > >
>> > >> ( <mailto:-.@> -.@+. _1&|.) =&(<,'&') T
>> > >
>> > >> 1 0 0 1 1 0 0
>> > >
>> > >>
>> > >
>> > >> As an aside, note that I could have cut that step out if I had started
>> > >
>> > >> by identifying where & does not appear (and then combine using logical
>> > >
>> > >> and instead of logical or):
>> > >
>> > >>
>> > >
>> > >> (* _1&|.) ~:&(<,'&') T
>> > >
>> > >> 1 0 0 1 1 0 0
>> > >
>> > >>
>> > >
>> > >> Next, I use plus scan to turn my markers into keys:
>> > >
>> > >>
>> > >
>> > >> +/\ (* _1&|.) ~:&(<,'&') T
>> > >
>> > >> 1 1 1 2 3 3 3
>> > >
>> > >>
>> > >
>> > >> Finally, I use these keys to group the original elements:
>> > >
>> > >>
>> > >
>> > >> T </.~ +/\ (* _1&|.) ~:&(<,'&') T
>> > >
>> > >> +-----------+-----+---------------+
>> > >
>> > >> |+-+-+-----+|+---+|+---+-+-------+|
>> > >
>> > >> ||4|&|count|||int|||3 8|&|inrange||
>> > >
>> > >> |+-+-+-----+|+---+|+---+-+-------+|
>> > >
>> > >> +-----------+-----+---------------+
>> > >
>> > >>
>> > >
>> > >> And that exposition pretty much follows the thought process I
>> > >
>> > >> originally used to compose the sentence.
>> > >
>> > >>
>> > >
>> > >> Thanks,
>> > >
>> > >>
>> > >
>> > >
>> > >
>> > > ----------------------------------------------------------------------
>> > >
>> > > For information about J forums see <
>> http://www.jsoftware.com/forums.htm
>> > >
>> > > http://www.jsoftware.com/forums.htm
>> > >
>> > > ----------------------------------------------------------------------
>> > > For information about J forums see http://www.jsoftware.com/forums.htm
>> > ----------------------------------------------------------------------
>> > For information about J forums see http://www.jsoftware.com/forums.htm
>> >
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
