[Jprogramming] Tacit Expressions with Explicit J Syntax
Henry Rich
henryhrich at gmail.com
Sat Sep 30 19:48:38 UTC 2017
On 9/30/2017 3:38 PM, Erling Hellenäs wrote:
> So, tacit code creates composites of compiled code and explicit code
> is still interpreted each time it is called?
Broadly, that's right. But remember that interpretation embraces
parsing and bookkeeping. Tacit code still has the bookkeeping.
> There is nothing like a J JIT compiler? /Erling
No, because the bookkeeping would remain.
Henry Rich
>
> On 2017-09-30 21:22, Erling Hellenäs wrote:
>> Hi all!
>>
>> OK. Yes. Considering this the differences seem very small. Long ago I
>> remember looping programs I made 270 times faster by removing the
>> loop and using some recursive tricks. Now the looping solution can
>> often even be faster.
>>
>> No one want's to answer the question if explicit code can replace
>> tacit code everywhere? $: did not seem to work in explicit code, but
>> there is also no need for it there.
>>
>> I recognized you can even use explicit code in tacit. That's mean.
>> Global variables and all. Mutable state.
>>
>> a=: 0.01
>> (+/ (4 :'x % y+a') #) 1 2 3
>> 1.99336
>>
>> Cheers,
>> Erling
>>
>> On 2017-09-30 19:20, Henry Rich wrote:
>>> Bill hit the nail on the head:
>>>
>>> > IMO it doesn't matter whether to use tacit or explicit,
>>> > the more important thing is to understand how J works.
>>>
>>> u@:v y means 'Do v on y; then do u on that result'. It is exactly
>>> the same as
>>> (u v y).
>>>
>>> u at v y means 'Do v on the first cell of y; then do v on that; repeat
>>> for all cells'
>>> If there are many cells in y, you will be repeating the overhead
>>> of starting v and then u.
>>>
>>> What is that overhead? In your examples using @, (1) parsing and
>>> (2) bookkeeping.
>>> Parsing: (3 :'-y')@- v is slow partly because every sentence of an
>>> explicit entity is parsed anew when the sentence is executed. Thus
>>> the sentence '- y' is parsed repeatedly. In
>>> - at - y the verb, - at -, is parsed once.
>>>
>>> Bookkeeping: every J noun can be an array with any type. Every time
>>> you start a verb, each argument must be analyzed.
>>> (3 :'-y')@- v starts 3 verbs for each cell: -, (3 :'-y'), and -
>>> again. The - starts are quick, because they follow an optimized
>>> path for arithmetic on singletons. (3 :'-y') is another story:
>>> starting an explicit definition means getting ready for control
>>> structures, creating a namespace, initializing the names xymnuv, and
>>> a bit more. That's where most of the time is being spent.
>>> - at - starts just the 2 verbs - and -, each of which is fast.
>>>
>>> There are other overheads to the explicit form: (1) executing -y
>>> requires looking up the name y (2) assigning the result of - to the
>>> name y means that -y cannot be executed in-place, which is slower.
>>>
>>> Finally, there is an overhead for splitting v into cells and
>>> assembling the cell-results into a single array. This is small.
>>>
>>> When you write u@:v, you have only 3 verbs to start: (u@:v), v, and
>>> u. If u is explicit, you have the extra explicit overhead just
>>> once. If you ran a test using @: on long v, I would expect the
>>> tacit code to take less memory and time mostly because -@:- executes
>>> the first - in-place while
>>> 3 : '-y'@:- doesn't.
>>>
>>>
>>> Henry Rich
>>>
>>>
>>> On 9/30/2017 10:24 AM, Erling Hellenäs wrote:
>>>> Hi all!
>>>>
>>>> Yes, well, I wanted to measure differences between tacit and
>>>> explicit expressions as such, so I tried to avoid unrelated
>>>> processing time. In case you have significant operations, these
>>>> differences disappear, of course, and the processing time in these
>>>> operations dominate over interpretation time or small differences
>>>> in the code generated.
>>>> It seems better to create an internal loop then to have ts loop a
>>>> big number of times over a very small load, since the measurement
>>>> process as such might dominate in the latter case.
>>>> The way you measure, you have to set v low and n high to avoid
>>>> processing time, and it seems you didn't.
>>>> I understand that these differences might not be important in
>>>> practice. Thanks for your judgement on that.
>>>> Any other opinions about performance differences between tacit and
>>>> explicit code? Are there any cases when they are big?
>>>>
>>>> ts=: 6!:2 , 7!:2@] NB. Time and space
>>>> v=.1
>>>> n=.5000000
>>>> n ts'(3 :''-y'')@:- v'
>>>> 3.03253e_6 6784
>>>> n ts'(-)@:- v'
>>>> 4.83682e_7 1152
>>>> v=.?~n
>>>> ts'(3 :''-y'')@- v'
>>>> 1.8912 1.34712e9
>>>> ts'(-)@- v'
>>>> 0.93178 1.34711e9
>>>>
>>>> Cheers,
>>>> Erling
>>>>
>>>>
>>>>
>>>>
>>>> On 2017-09-30 13:13, bill lam wrote:
>>>>> Since the time taking is small, better to run n times
>>>>> to obtain an average.
>>>>>
>>>>> + and - are scalar functions of rank-0, but J has
>>>>> integrated rank support so that there will be no
>>>>> performance penalty if its arguments are arrays.
>>>>>
>>>>> @ will inherent the rank of - , better to use @: in
>>>>> this case.
>>>>>
>>>>> 50 ts'(3 :''-y'')@- v'
>>>>> 0.183617 8.39565e6
>>>>> 50 ts't at - v'
>>>>> 0.105698 8.3904e6
>>>>>
>>>>> 50 ts'(3 :''-y'')@:- v'
>>>>> 0.00245378 1.67837e7
>>>>> 50 ts't@:- v'
>>>>> 0.00206336 8.39002e6
>>>>>
>>>>> IMO it doesn't matter whether to use tacit or explicit,
>>>>> the more important thing is to understand how J works.
>>>>>
>>>>>
>>>>> Сб, 30 сен 2017, Erling Hellenäs написал(а):
>>>>>> Hi all !
>>>>>>
>>>>>> Can tacit and explicit J be interchangeably used everywhere ?
>>>>>>
>>>>>> Examples of use:
>>>>>>
>>>>>> 4 (3 :'- y')@:(4 :'x + y') 5
>>>>>> _9
>>>>>> 3(4 :'(1: x + y)#''x'' ')`(4 :'(1: x + y)#''y'' ')@.(4 :'x <
>>>>>> y')4
>>>>>> y
>>>>>>
>>>>>> What are the performance implications of using explicit J instead
>>>>>> of tacit
>>>>>> J?
>>>>>>
>>>>>> This little example indicates that tacit J is about twice as fast?
>>>>>>
>>>>>> v=.?~1000000
>>>>>> 10{.v
>>>>>> 733026 963097 739111 754321 510732 704647 209066 833891 281909
>>>>>> 851842
>>>>>> #v
>>>>>> 1000000
>>>>>> t=: -
>>>>>> e=: 3 :'-y'
>>>>>> ts't at - v'
>>>>>> 0.49503 2.6439e8
>>>>>> ts'e at - v'
>>>>>> 0.743922 2.6439e8
>>>>>> ts'(3 :''-y'')@- v'
>>>>>> 0.38011 2.64395e8
>>>>>> ts'(-)@- v'
>>>>>> 0.186993 2.6439e8
>>>>>> ts'- at - v'
>>>>>> 0.182542 2.6439e8
>>>>>> ts'(3 :''- <: >: y'')@- v'
>>>>>> 0.465578 2.64395e8
>>>>>> ts'([: - [: <: [: >: ])@- v'
>>>>>> 0.25002 2.64391e8
>>>>>> *./ (t at - v) = v
>>>>>> 1
>>>>>> *./ (e at - v) = v
>>>>>> 1
>>>>>> *./ ((3 :'-y')@- v) = v
>>>>>> 1
>>>>>> *./ ((-)@- v) = v
>>>>>> 1
>>>>>> *./ (- at - v) = v
>>>>>> 1
>>>>>> *./ ((3 :'- <: >: y')@- v) = v
>>>>>> 1
>>>>>> *./ (([: - [: <: [: >: ])@- v) = v
>>>>>> 1
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Erling
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2017-09-29 20:10, Erling Hellenäs wrote:
>>>>>>> An additional comment. see below. /Erling
>>>>>>>
>>>>>>> On 2017-09-29 04:45, Henry Rich wrote:
>>>>>>>> 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).
>>>>>>> This is a strange comparison, (+ i.) is comparable to + i. with
>>>>>>> explicit
>>>>>>> syntax. [ ( + i. ) ] is comparable to x + i. y and ([ (+ i.) ]) is
>>>>>>> comparable 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
>>>>>>>>>> <olius at bluewin.ch> 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
>>>>>>>>>>>> <rauldmiller at gmail.com> 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
>>>>>>>>>>>> <erling at erlinghellenas.se> 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
>>>>>>>>>>>>>> <erling at erlinghellenas.se>
>>>>>>>>>>>>>> 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
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>>
>>>>>> 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
More information about the Programming
mailing list