Hi all! See comments below.
Cheers, Erling On 2017-09-28 23:45, Louis de Forcrand wrote:
The main difference between tacit J and explicit J, as I see it, is not the syntax as such but that tacit J lacks mutable state.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.
I think that is the reason some people use it professionally.Anonymous verbs are easier to create. This will change if Henry's request is implemented. I have learned some things about how to simplify problem solutions when I messed with tacit J, but yes, if my request does not pass, I guess I will stick to explicit J.
I don't know in what way the tacit syntax could ever be better than what I describe. It is a lot more complex but it is not even shorter. I doubt it is good even for anything it was created to be used for.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.
Yes, well, there is a question if we should move on, work on more than one thread, have non-mutable state, have functions as primary citizens, have anonymous definitions of adverbs and conjunctions, integrate into development environments instead of working at a prompt and very much more, or if we should just keep on doing small changes to a language made for working at a teletype. Tacit J seemed like a step in the right direction because it lacks mutable state. I once thought it was functional programming but as I see it it isn't. Now we have to go back to explicit J because we recognized tacit J is not useful. It means we made very little progress since the teletypes?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, LouisOn 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äsOn 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
