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
