Okay, so there /is/ a benefit here, but the
issue at hand is rather of syntactical nature.
The only thing we need in order to achieve
what you are talking about is a syntax for
nestable multiline constructs.
Nestable strings would suffice and one could
use them to build nested functions (verbs, adverbs, …)
but that would seem like a workaround for a missing
language feature (syntax). So yes, I’d actually like to
see some kind of general nestable multiline definitions.
This is all about syntax, so forgive me some detour
praising another language’s solution: I think as far
as nested multiline strings (and comments, for that
matter) go, lua has an (imo) excellent construct:
[[
this is a
multiline string
]]
[=[
this is a
[[multiline string]] with nested brackets
]=]
-- this is a single line comment
--[====[
this is a
multiline comment: just a multiline string
with the -- comment introducer prepended
there may be any number of = signs
and the text (string or comment) runs
to the matching ]] with the same number
of = signs, so ]=] here won’t close it.
for commenting/uncommenting code, just
prepend the closing ]=…=] construct with
--, too, so you only need to toggle the
-- on the opening line
]====]
For completeness sake, I’ll try and give a constructive answer
but I’m not really sure if it would be a good thing to support
multiline constructs this way – just another “brain fart”
How about using multiple colons in a row for definitions,
closed by a matching number of closing parentheses at the
start of a line, and on its own, like this:
outer =: 3 : 0
inner =. ];._2 ] 0 ::: 0
sator
arepo
tenet
opera
rotas
)))
(];|:;|.@|."1) inner
)
It does interfere a bit with ::, though, and is on par with
{{…}} – or even worse – as far as bending microsyntax of builtins
(well, technically, this wouldn’t be a builtin since it would
be replaced with a local : and ) by the parser, I guess)
is concerned.
But it doesn’t look like we introduced something completely new.
And it could be made to support the mdvacn indication of
intended part of speech which I consider a Good Idea™.
(Do you also read a misspelled “advance” in “mdvacn”?)
Like this:
outer =: :v)
inner =. ];._2 ] :::n)
same as above
)))
inner
)
or maybe
inner =. ];._2 ] :n)))
then it would look a bit like HERE documents,
another solution present in a couple of languages
one could then use any delimiter and not be
constrained to using runs of )
But maybe, for the J community, that’s too much of a departure
from the syntax we’re used to.
Am 03.11.20 um 22:33 schrieb 'Michael Day' via Programming:
> 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.
>>>
>
>
>
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
