I do not know of any definition of "namespace" such that @: creates a namespace.
Why do you think that @: creates a namespace? Thanks, -- Raul On Thu, Sep 28, 2017 at 10:57 PM, Erling Hellenäs <[email protected]> wrote: > About this question: > f@:g@:h? > I think we had a long thread recently about how to write this. I think each > @: will generate a namespace with ([: f ]) and that this means some more > copies of variables than [: f [: g [: h ]. The interpreter does not handle > @: directly from what I remember from this thread. And the result of > cheating and writing f@g@h took ten times longer or something for a test in > this thread. > I think the "correct" way to write when you use @: is f@:(g@:(h)) according > to the discussions in this thread. Mathematically it is f(g(h)) so it seems > logical? At least there is a problem with J not tying to combinations of > verbs with adverbs and conjunctions to the right. > Maybe someone else finds this thread? With lots of measurements and > discussions about how to write a sequence of verbs in tacit code. > /Erling > > > On 2017-09-29 04:09, 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 <[email protected]> >>> 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 <[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 > > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
