Henry's just explained that the internal function needs to have a global
definition if it
needs to call itself recursively.
So I think the example, spandd, will work as intended provided its
embedded function,
span0, is assigned with =: rather than with =.
Not quite so satisfying, but not too bad.
Cheers,
Mike
On 03/11/2020 22:44, 'Michael Day' via Programming 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
