Hi all !
Is improving explicit J the way forward? Or is tacit J and improving
tacit J the way forward?
I also think that "Henry's" proposal, which is similar to what I have
been writing about for a long time, is great. It is easy to do and have
great benefits for people working in explicit J. They will not have to
type lots of double quotes, or write their own J versions with special
duplicate quote functionality.
That doesn't mean that tacit J could not also be improved?
Henry's proposal is nearly identical to my proposal but mine is about
tacit J, it is addressing problems with tacit J. His is about explicit
J. It is addressing problems with explicit J, the quote duplication
problem. I am addressing problems with tacit J, mainly the problem
which makes people write cross-compilers from explicit to tacit J or
programs to automatically pack verb sequences in tacit J into their
packages of brackets and phony "compositors", like this -
f@:(g@:(h@:(i@:(j@:])))). People who are working professionally with
tacit J and who knows that cheating and writing tacit J like most other
people do will slow their programs much too much?
Cheers,
Erling
On 2017-09-29 03:13, Joe Bogner wrote:
I also like Henry's suggestion of fast function definition. It's also
unclear to me on how the Erling's suggestion improves upon that.
On Thu, Sep 28, 2017 at 5:45 PM, Louis de Forcrand <[email protected]> wrote:
I don't really understand what you wish to add either, Erling.
If you want to use explicit J syntax, you could write an explicit verb.
You write:
Particularly to create what you most commonly need, a sequence of
monadic verbs, each acting on the result of the verb to the right.
Well, it is not complicated as such, but for some reason people don't
like
the obvious way to do it, which is [: f [: g [: h ]. Then they dive into
a
mess of complications. I mean the cap should not be necessary. That
simple
right to left execution should be the default, possibly modified with
parenthesis. That tacit and explicit J should have the same basic syntax.
f@:g@:h?
In addition, I disagree with your last two sentences. What's the point of
having tacit syntax if it's the same as explicit syntax? If you want
explicit syntax, write an explicit verb; other times tacit syntax is really
practical.
In an explicit verb, simple right to left execution *is* the default.
In any case I don't really see how the rest of your suggestion differs
from Henry's (.). verbs, which I like very much by the way.
Cheers,
Louis
On 28 Sep 2017, at 14:53, Raul Miller <[email protected]> wrote:
Jose's work is impressive, but I try to avoid it because of the extra
complexity it creates when I want to (for example) provide a parameter
in clauses for conjunctions like &. -- the extra complexity can be a
nice mental exercise and maybe even a cure for boredom, but I feel
that I have the right to treat it as unnecessary.
Thanks,
--
Raul
On Thu, Sep 28, 2017 at 8:33 AM, Erling Hellenäs
<[email protected]> wrote:
Hi all !
I am very impressed by Jose's work and I think it is an excellent
illustration to why we need the modification to J I propose.
It is extremely complicated to do these things which should be simple,
as I
see it. Particularly to create what you most commonly need, a sequence
of
monadic verbs, each acting on the result of the verb to the right.
Well, it is not complicated as such, but for some reason people don't
like
the obvious way to do it, which is [: f [: g [: h ]. Then they dive
into a
mess of complications. I mean the cap should not be necessary. That
simple
right to left execution should be the default, possibly modified with
parenthesis. That tacit and explicit J should have the same basic
syntax. I
tried my ideas of a different tacit J in a test implementation and it
was
great.
Cheers,
Erling Hellenäs
On 2017-09-28 05:29, Jose Mario Quintana wrote:
Hi Erling,
You are right, the adverb (At) produces tacit sentences but it is
really
an
implementation of Dan's pipeline proposal using strand notation via a
Curried adverb (aka, recurrent adverb and multiple adverb).
However, I have written (tacitly) a tacit Curried adverb (xi) which,
using
a lambda-style syntax, produces a tacit verb which in turn, given its
arguments, produces tacit entities. You might find xi interesting; the
general form is,
t=. [: v0 v1 ... vn '...' xi
The names v0 v1 ... vn should be syntactically verbs (recall, xi is a
Curried adverb) but they can represent nouns, verbs, adverbs, or
conjunctions. I use undefined names since those are regarded by
default
as
verbs (even if xi does not affect in any way the named verbs). The
literal
'...' represents a quoted J (or more generally a Jx) sentence.
This is how your example can be written using xi,
erase 'b v'
[: v '([: b ''<:b++/\b-~-.b'' xi <''\''=v){."0 v' xi <'\\\//\\\//'
\
\
\
/
/
\
\
\
/
/
There is the nuisance of quotes within quotes and the argument must be
boxed; however, this allows, in general, the verb (t) to produce a
noun, a
verb, an adverb, or a conjunction and to take multiple boxed nouns,
verbs,
adverbs, or conjunctions as its argument. The following verb (t) acts
directly on a couple of (boxed) verbs and produces a verb,
t=. [: u v 'u/@:v' xi
t[:+*:]: NB. Sum of squares
+/@:*:
t[:+*:]: 1 2 3 4 5
55
t[:-%:]: NB. Difference of square roots
-/@:%:
t[:-%:]: 1 2 3 4 5
1.55390522
Note that the Curried higher-order verb (t) is, in effect, acting on
two
arguments: [:-%:]: and 1 2 3 4 5; furthermore, t [:-%:]: performs a
partial
application of the verb (t) acting on [:-%:]: .
The following are variations of the verb produced in [0], the verb (t)
acts on a (boxed) conjunction and produces an adverb,
t=. [: u '(ver adv u)&:train/adv' xi
]`{.`{:`{: (t [:(<adv@:)]:) NB. Use [:(<'@:')sb in J
]@:({.@:({:@:{:))
]`{.`{:`{: (t [:(<adv@ )]:) NB. Use [:(<'@ ')sb in J
]@({.@({:@{:))
]`{.`{:`{: (t [:(<adv&:)]:) NB. Use [:(<'&:')sb in J
]&:({.&:({:&:{:))
These non-compliant features are not provided by the Jx interpreter;
they
are, in fact, inherited from the J interpreter, the Jx facilities just
make
them a lot more accessible. Actually, I have written a version
(admittedly
cumbersome) of xi in J; see [1] for a link to a zip archive and the
path
to
a script where xi is defined.
PS.
erase'u0 u1 u2'
1 1 1
[: u0 u1 u2 'u0 + u1 + u2' xi 1 ; 2 ; 3
6
erase'α β γ'
1 1 1
[: u0 u1 u2 'u0 + u1 + u2' xi [:α β γ]:
α + β + γ
References
[0] [Jprogramming] Gerund composed application
http://www.jsoftware.com/pipermail/programming/2017-
September/048797.html
[1] J Wicked Toolkit
http://www.2bestsystems.com/foundation/j/Jx.zip
\Jx\J\J Wicked Toolkit.ijs
On Wed, Sep 27, 2017 at 5:10 AM, Erling Hellenäs
<[email protected]>
wrote:
Hi all !
Pascal, I will come back to your post later.
Here is a little compiler written in Jx and compiling, as I understand
it,
tacit code with explicit J syntax into tacit J. I did not test it, I
just
read the post.
http://www.jsoftware.com/pipermail/programming/2017-
August/048143.html
The code snippet Farey is an example of the source code of the little
compiler.
I just think we should not have to use a tacit J compiler from
explicit J
to be able to use explicit J syntax and get a tacit result, a single
verb.
It would obviously be better to use explicit J syntax in the first
place,
as i see it.
Cheers,
Erling
------------------------------------------------------------
----------
For information about J forums see http://www.jsoftware.com/
forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
