Yes, sorry Raul, my mistake re spandd. Henry pointed out in answer to my query on this in a parallel thread that the embedded fn needs to be global. Try span0 =: ... or, better, define spandd0 =: ... in order to avoid confusing the conventional sub function and its dd alter ego.
In my tests, spandd worked until I erased span0 as a global, which I should have done before posting, of course! I’ve just checked g span 0 on this iPad using J701 after copy & paste from this email’s history, below. It seems ok here, so I’m puzzled by your domain error with that. It’s still quite nice to be able to have sort of self-contained functions. Mike Sent from my iPad > On 4 Nov 2020, at 04:04, Raul Miller <[email protected]> wrote: > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
