>Note for those who have not been using J for
>more than 10 years: the
>original tacit
>language allowed trains that produced modifiers.
What is the latest J version that had this? Is it available somewhere?
--------------------------------------------
On Fri, 9/29/17, Henry Rich <[email protected]> wrote:
Subject: Re: [Jprogramming] Tacit Expressions with Explicit J Syntax
To: [email protected]
Date: Friday, September 29, 2017, 11:45 AM
Taking your last sentence first,
you would have to supply some evidence
to
make me believe that tacit forms have any intrinsic
performance penalty.
It is
dawning on me that you want fast function definition, but
that you
want it to produce tacit code.
You find the current tacit language
difficult, and you propose to replace it with
something that looks more
like the explicit
language. That seems like a mistake to me, because:
1. Most of the responders on
this Forum don't agree with you that the
tacit language is opaque
2. Even with a fast function definition, many J
programmers (I dare not
say all J
programmers with a soul) will always prefer (+ i.) to (. x +
i. y).
3.
Tacit code is a different mindset from explicit code.
It's
functional. It doesn't have
assignments or control words
4. Operands to modifiers cannot be arguments to
tacit code
5. Explicit
syntax is an improvement in some cases, not all. +/ *: y
is
a little lighter than +/@:* y but (+/ y)
% #y is heavier than (+/ % #) y
6. So: even if I were redesigning the language
from scratch, I wouldn't
represent
tacit forms your way. I would, as Roger has observed,
switch
the meanings of (u v) and (u@:v),
but I would keep the rest as is.
[Note for those who have not been using J for
more than 10 years: the
original tacit
language allowed trains that produced modifiers. That
was, to me, Ken's finest achievement: a
really beautiful language,
immensely
supple, even though it had no syntactic elements but the
primitives and parentheses. I never found it
wanting. It was fully
understood by no
more than half a dozen people, I think. It was removed
from J because explicit forms could produce the
same results: a good
business decision, but
a loss to computer science and art.]
7. The bottom line: tacit forms work pretty
well as they are, and an
incompatible
change to them could be justified only by a huge
improvement in readability or efficiency. You
haven't shown that.
Henry Rich
On
9/28/2017 10:09 PM, Erling Hellenäs wrote:
> 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
---
This email has been checked for viruses by
AVG.
http://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
