Hi all ! I think my blog post describes my view: https://erlhelinfotech.wordpress.com/2016/08/01/jwithatwist-or-tacit-j/It is in no way exhaustive in terms of problems I find in tacit J, but I think it was more than enough for taking the decision.
"The tacit J syntax is a total mess of utter complexity.""As you can see the choice could not be easier and I have chosen the modified explicit J syntax for JWithATwist."
Cheers, Erling On 2017-09-29 01:46, Ric Sherlock wrote:
Hi Erling, Just want to suggest that statements like "we recognized tacit J is not useful" seem a little premature unless "we" is the royal "we" i.e. "I". Even then I suspect a more accurate statement would be "I don't see the benefits of tacit J". So far my understanding of your position is that you find that hooks and forks are hard to parse and so want to make the syntax more linear while retaining the benefits of not explicitly naming arguments in verbs. Please feel free to correct me if I've misunderstood. I had a brief read of your blog, on the matter and so far am not convinced that this proposal provides more readable code in all or even many cases. I agree that long tacit expressions can be hard to parse - I think this is true of any long sentences. I think there are some expressions that are very much simplified by the use of forks and hooks. I also agree that tacit expressions can become unwieldy when dealing with more than 2 arguments. Currently I favour a mix of tacit and explicit forms where they best fit. I think I'd need to see a lot more examples of how your proposal would improve current code to change my view. Cheers, On Fri, Sep 29, 2017 at 12:20 PM, Erling Hellenäs <[email protected]> wrote:Hi all! See comments below. Cheers, Erling On 2017-09-28 23:45, Louis de Forcrand 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.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 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.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.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.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.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?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/forum s.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
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
