My opposition to modifiers that produce modifiers is esthetic and
personal. They're in the language, so you're allowed to use them, it's
just that I don't like the code that results. I think Raul is right
that these ideas need to be motivated by practical examples from the
beginning.
----
While enthusiastic about your proposal, I question your analysis:
x u [.. v y = x u (x v y)
x u ].. v y = (x u y) v y
x ((f ].. g) [.. h) y = x (f ].. g) (x h y)
= (x f (x h y)) g (x h y)
This is not a fork.
----
BTW I have put (C0 C1) -> conj ((u C0 v) (u C1 v)) in for the next
beta. Still thinking about (V0 V1 N2) which really seems to be called for.
----
Your proposal for (C0 C1 C2) -> conj ((u C0 v) (u C1 v) (u C2 v)) is
incompatible with current uses of
(C0 : C2)
and we would need more consensus before making such a change. Consensus
here includes ensuring that old texts are not invalidated.
Henry Rich
On 9/29/2021 5:04 AM, Elijah Stone wrote:
On Wed, 29 Sep 2021, Raul Miller wrote:
(2) I do not understand what your [.. and ].. would produce,
individually. How would you model them?
[.. =. {{[ u v}}
].. =. {{u v ]}}
Conceptually, the derived verb 'f [.. g' has a root of f (at which it
points), but uses g to augment its right parameter.
It might be better written as:
[.. =. {{y u v y}} : {{x u x v y}}
Instead of defining it in terms of fork, because it is really more
primitive than fork. A fork (f g h) augments the left and right
parameters of g at the same time with f and h (respectively), and so
can be written as (f ].. g) [.. h.
(1) It would be Really Nice if examples were included with these
suggestions. Specifically: useful code in some domain, with
accompanying plausible tacit code. This sort of thing helps keep
coding sane... (Specifically, it helps us avoid turing tarpits and
their associated open ended costs.)
I gave definitions of of fork, hook, and compose, which I think are
rather practical and can't easily be defined in terms of existing
primitives! Here also is left hook: ~ [.. (@]) ~.
Here is what first sent me on this journey:
(]:={.) ].. ([;{.;}.)
It is a parser combinator adverb. A parser, in this system, takes a
string to be parsed, and produces a boxed three-vector of: boolean
success/failure; result (arbitrary); and the remainder of string to be
parsed (whatever was not consumed). The adverb takes a character and
produces a parser which matches a string starting with that character.
I previously wrote it as follows, in terms of hook (h):
([;{.;}.)~ h (]:={.)
But I much prefer the version using left fork. It doesn't need to be
commuted (because hook always augments the right argument, where with
fork we get to decide); and it points directly at the root verb. And
left and right fork generalise much more nicely; just as regular forks
are far more useful than hooks and can replace them in all cases, so
do I think left/right fork is critical for inclusion compared with
C0C1 hooks.
Note also that as there is currently no hook conjunction, defining in
terms of hook would either need to use such a definition, use it
inline (replacing h with ([.].), assuming C0C1 is in fact added), or
use a constant conjunction (see below).
(3) Inspecting your P.P.S. proposal, I think when you say "constant
conjunction" you mean "an adverb which produces a conjunction which
replaces one of its arguments with the adverb's argument"
I mean an adverb which produces a conjunction which always produces
the same value (which being the argument to the adverb). Just as x
(5"_) y will always be 5, u (+ CONST) v should always be +. (So it
can simply be 1 :'2 :(5!:6<''u'')'.)
Henry seems to be opposed to adverbs or conjunctions which do not
produce verbs or nouns (except in exceptional circumstances, like :),
which I think is reasonable. It is possible to write (+ CONST) as
(+[.@); it is just slightly ugly since the @ is useless (and could be
replaced by any other conjunction).
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
