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

Reply via email to