The Curried adverb xi, produces tacit verbs (which might be higher-order verbs); however, in contrast to the tacit translator 13 : '...' , the product is not a translation to tacit code (i.e., it is not really a compiler). Instead, the product consists of a description of the position of the parameters within a compressed list of the sentence components, the list itself, together with the structure of the sentence and this description is bonded to a fixed tiny interpreter which acts on its arguments; substituting their corresponding parameters by them and interpreting the sentence (the last bit is a remake of one of Dan Bron's previous contributions).
I wrote it for various reasons: to translate some explicit entities written explicitly by other people without having to think about it (in particular, to produce tacit verbs when the tacit translator failed); to quickly produce adverbs and conjunctions acting as macros; to have the ability to refer directly to multiple parameters; and allowing the parameters to represent adverbs and conjunctions in addition to just verbs and nouns. I agree with you, at least partially: some adverbs and conjunctions are a lot easier to write with an explicit/lambda style notation. PS. Xi is limited to one-liner sentences; then again, the word limited might be misleading since J one-liners are Turing complete. On Thu, Sep 28, 2017 at 10:09 PM, Erling Hellenäs <[email protected]> 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/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
