[Jprogramming] Tacit Expressions with Explicit J Syntax
Erling Hellenäs
erling at erlinghellenas.se
Sat Sep 30 19:38:55 UTC 2017
So, tacit code creates composites of compiled code and explicit code is
still interpreted each time it is called?
There is nothing like a J JIT compiler? /Erling
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
More information about the Programming
mailing list