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
