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.
>
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
