I get a domain error from both g spandd 0 and from g span 0. FYI,
-- Raul On Tue, Nov 3, 2020 at 5:44 PM 'Michael Day' via Programming <[email protected]> wrote: > > Actually, I was a bit premature. The example should work but doesn't > yet. The embedded > span0 throws an error; spandd was using the global span0! > > Also, span0 canNOT be anonymous; Henry explained to me recently that > self-reference isn't > defined for explicit verbs. > > Nevertheless, I think spandd is illustrative of nested functions, once > I get it right! > > Mike > > > On 03/11/2020 21:33, 'Michael Day' via Programming wrote: > > Sorry if you're only commenting on John Baker's "brain-fart" - his > > expression! - but it looks > > as if you're also objecting to DDs in general. > > > > Here's one benefit, in my opinion. > > > > I've been a fan of Dyalog APL's direct definitions (dfns) for a long > > time. I quite often raid > > the late John Scholes' example functions. Recently, but before J902 > > emerged, I imported his > > "span"; it returns a spanning tree starting from a given vertex in a > > given graph. > > > > This named APL direct-definition function contains an anonymous > > operator (adverb) within > > its definition. Previously, I had to define span0 as an auxiliary > > adverb: > > > > span =: 3 : 0 NB. fixed font best here > > : > > graph =. x > > l =. _2 + y e.~ i.#x > > l (graph span0) y > > ) > > > > span0 =: 1 : 0 > > : > > ix=. [-.-. NB. intersection is an APL primitive > > if. 0 = #y do. > > x > > else. > > graph =. m > > next =. (y { graph) ix each < I. x = _2 > > back =. y (+ 0&*)each next > > tree =. (;back) (;next) } x > > tree (graph span0) ~. ; next > > end. > > ) > > > > eg > > g =: 1 2;2;1 3;0 4;2 > > g span 0 > > _1 0 0 2 3 > > > > But now, with J's new direct definitions: > > (comments lifted from John's original dfns listing, apart from ix) > > > > spandd =: {{)v NB.breadth-first spanning > > tree > > : > > graph =. x NB. x is graph vector > > span0 =. {{)a > > ix=. [-.-. NB. intersection is an APL primitive > > NB. x is partial spanning > > tree > > if. 0 = #y do. NB. No vertices : done > > x > > else. > > graph =. m > > next =. (y { graph) ix each < I. x = _2 NB. untravelled edges > > back =. y (+ 0&*)each next NB. back link per edge > > tree =. (;back) (;next) } x NB. partial spanning tree > > tree (graph span0) ~. ; next NB. advanced wave front > > end. > > }} > > l =. _2 + y e.~ i.#x NB. partial spanning tree > > l (graph span0) y NB. y: next wave of > > vertices to visit > > }} > > > > g spandd 0 > > > > _1 0 0 2 3 > > > > > > (span0 can be anonymised within spandd, but it renders the example a > > bit more opaque.) > > > > Sorry it's not a more concise example. > > > > Cheers, > > > > Mike > > > > On 03/11/2020 18:15, Hauke Rehr wrote: > >> Hi all, > >> > >> I didn’t even see the point of DDs in the first place. > >> After all, the parser by the very nature of code being text > >> will always see strings, so why not explicitly show that off? > >> 'one two three' =. arr > >> makes me more aware of what must be going on behind the scenes: > >> a string being parsed into names in a namespace the interpreter > >> needs to do bookkeeping with etc. > >> The same goes for all that DD stuff. The parser will treat text > >> first and that’s where all the magic the {{…}} construct shadows > >> happens. Maybe I’m ignorant but I just don’t see the point. > >> imo, {{…}} is unnecessary but if it wouldn’t interfere with J’s > >> rules for builtin names, I’d say give the people what they think > >> they need – and everyone may use J their way > >> > >> And considering {{this * that ^ more}}=: arr, I’d expect > >> * and ^ to be redefined, not executed > >> J IS NOT PYTHON, we don’t need list comprehensions > >> sorry, this suggestion looks a bit like introducing them. sort of. > >> > >> … and then, =: is meant to be an assignment. > >> If the expression will be evaluated, we have a lhs that > >> • doesn’t have anything in common with the rhs > >> • isn’t bound by any name > >> Very counterintuitive semantics for syntax like {{…}}=:RHS > >> > >> {{+/a * b % c ^ d - e}}=. {{5 # this * that ^ more}}=: arr > >> You may want to use this with arr having 3 items. > >> You may as well want to use this with arr haveng 2 items > >> and the name 'that' already bound to some value. > >> Just as 5 already is a value and will hopefully not be bound > >> to the first item of arr > >> How to make that consistent‽ > >> > >> One last point: this all doesn’t look very J-ish. > >> We’re doing array processing. If you need to process > >> an array’s elements the way you show here, > >> I’d say throwing them into a common array may have > >> been a design flaw to start with. > >> Do you regularly have use of different verbs being > >> applied in between items of an array in J? > >> (and yes, one might use gerunds but I still consider > >> this an abuse of arrays: I said “everyone may use > >> J their way” but that one was about syntax ({{…}}), > >> not about design: I don’t want to see this abuse > >> encouraged by the proposed new semantics of {{…}}) > >> > >> Just my 2¢, I’d like to read different opinions on this. > >> > >> > >> Am 03.11.20 um 17:07 schrieb John Baker: > >>> I had a little brain fart this morning. What might it mean to assign > >>> direct definition forms? > >>> > >>> In current J we have the ugly but extremely useful form: > >>> > >>> 'this stuff gets array items'=: arr > >>> > >>> The names get parsed in the string and assigned corresponding array > >>> items. > >>> This has been in J forever and is so handy we tolerate the hideous > >>> QUOTED > >>> code. > >>> > >>> Suppose: > >>> > >>> {{this stuff gets array items}}=: arr > >>> > >>> No more ugly quoted code. But why stop there, consider a general DD > >>> with > >>> unbound names. > >>> > >>> {{this * that ^ more}}=: arr > >>> > >>> One way to approach this is to treat the names in the DD like a > >>> regular J > >>> expression accessing global names in it's namespace. > >>> The names are bound by matching corresponding names with array > >>> items, just > >>> like the current 'this that more'=: array, and then the expression is > >>> evaluated as always. > >>> > >>> This opens up a world of possibilities like: > >>> > >>> {{+/a * b % c ^ d - e}}=. {{5 # this * that ^ more}}=: arr > >>> > >>> This is only a slight generalization of what's already in J. I'm not > >>> suggesting immediate implementation - just curious as to what others > >>> may > >>> think. > >>> > > > > > > > > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
