Tacit J can have mutable state. For example:
set=:1!:2&(<'state') get=:1!:1 bind (<'state') It's also possible implement mutable state in tacit J without using foreigns (nor the explicit conjunction), but (depending on your approach), it can get long. Thanks, -- Raul On Thu, Sep 28, 2017 at 7: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/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
