Yes, and the @:]"_ is redundant for any and all verbs u1 u2 u3 and u4.
And ([: u1 [:u2 u3@:u4) is another example equivalent...

Moreover, for a good example, the choice of u1 u2 u3 and u4 also matters.

More generally, though, it's good to focus on the practical problem
solving issues first and then bring the language to bear on solving
that problem. Doing it the other way around leads to bad language
decisions.

Cheesy examples can be useful in some contexts (for example, in
debugging), but they tend to be rather bad for language design.

That said, note that getting into real examples also allows rephrasing
based on the meaning of what is being dealt with.

For a hopefully-not-too-cheesy example, consider:

  u1=: -&1
  u2=: ^&0.5
  u3=: +&1
  u4=: ^&2

Since u1 @: u2 @: u3 @: u4 (or other variants) winds up being an
algebraic expression, you can use algebra to rephrase the expression.
But this is a good thing.

Thanks,

-- 
Raul

On Wed, Aug 3, 2016 at 3:25 PM, robert therriault <[email protected]> wrote:
> I believe it could also be expressed as
>
> u1 @: u2 @: u3 @: u4 @: ]"_
>
> Cheers, bob
>
>> On Aug 3, 2016, at 12:18 PM, Erling Hellenäs <[email protected]> 
>> wrote:
>>
>> As far as I can understand the pattern of the strawman, [: u1 [:u2 [: u3 [: 
>> u4 ] , is the only expression in tacit J with the meaning of 4  monadic 
>> verbs ux in sequence. All other similar expressions have a more complex 
>> meaning. Correct me if I'm wrong. /Erling
>>
>> On 2016-08-03 20:31, Erling Hellenäs wrote:
>>> Here the scientific view. It's an old mail which got "lost" when I did 
>>> Reply-to-list. It does not fit perfectly in this discussion.
>>>
>>> Passive and Reflexive (~) are of course also used to get the right argument 
>>> to the right function, giving even more complex ways to express the most 
>>> simple thing.
>>> That constants and even string constants have to be considered as constant 
>>> functions is also very peculiar, I think. That this is covered up by in 
>>> some cases writing them as normal constants makes it even more peculiar.
>>> This adds to the total messiness of tacit J, at least in my eyes.
>>> We removed not only the name of data types/variables but also all 
>>> references to them, except for Left and Right which are references to noun 
>>> arguments. Still these same data types still exist and most often are the 
>>> real arguments. Functions still are not primary citizens of the language. 
>>> Tacit expressions can be function argument to built in adverbs and 
>>> conjunctions. There is a macro-like way in which "adverbs" and 
>>> "conjunctions" can be defined by the user but where macro expansion takes 
>>> them away before execution.
>>> Well, and data does not have a type in J, so data in tacit J has most often 
>>> neither a name, nor a type nor any reference to it whatsoever. It is 
>>> something the reader by rational thought has to construct in his mind when 
>>> he tries to analyze expressions.
>>> Here we can read about how efficient humans are at rational thought:
>>> - Cognitive Miser. http://tinyurl.com/h5e8aym<https://t.co/ug1YbAdZIK>
>>> - How many objects can you hold in mind simultaneously? 
>>> <https://t.co/tOfF8fsfvT>http://tinyurl.com/hr37f59
>>> There is a science called Cognition which describes human cognitive 
>>> capabilities in detail.
>>> To be able to read something like this we have to remember sequences and 
>>> patterns and what they do. When we express the same thing in many ways this 
>>> gets very difficult. Like if you have hundreds of words for every concept. 
>>> When we fail we have to resort to rational thought, which in the best case 
>>> is very slow, often fails and often is far over the capacity of the 
>>> individual. Or we have to debug the expressions at a terminal, which is 
>>> even slower.
>>>
>>> /Erling
>>>
>>> On 2016-08-03 17:04, Erling Hellenäs wrote:
>>>> See comments below.
>>>>
>>>>
>>>> On 2016-08-03 15:47, Marc Simpson wrote:
>>>>> On Wed, Aug 3, 2016 at 1:21 AM, Erling Hellenäs
>>>>> <[email protected]> wrote:
>>>>>> My article contains some points supposed to show that the tacit J syntax 
>>>>>> is
>>>>>> a "total mess of utter complexity".
>>>>> This is the crux of the discussion, I think. It's one thing to argue
>>>>> that tacit expressions can be confusing as they involve rewriting
>>>>> equivalent explicit phrases (which is a fair point), it's another to
>>>>> then ignore their utility and expressiveness in a dismissive way (both
>>>>> here and in your article).
>>>> The reason is simply that I didn't find any significant advantages of the 
>>>> tacit J notation compared to the modified explicit J notation. If I knew 
>>>> of any such significant advantage I would have included it.
>>>>
>>>> The tacit J notation gives some support for the imagination when you do 
>>>> math work with functions. I did not consider this a significant advantage.
>>>>
>>>> I think I have understood the tacit J notation. There is another article 
>>>> where I describe this: 
>>>> https://erlhelinfotech.wordpress.com/2016/05/30/j-a-functional-language/
>>>>
>>>> If there is any such significant advantage, please tell.
>>>>>
>>>>> Put differently: it's great to see your work in this area (thanks for
>>>>> sharing) but the tone strikes me as problematic if you're actually
>>>>> looking to invite constructive comments.
>>>>>
>>>>> I can appreciate your focusing on regular parsing rules (as per K, Q
>>>>> and Dyalog d-fns) but stating things like "The tacit J syntax is a
>>>>> total mess of utter complexity" just seems lazy. Further, as Raul
>>>>> points out, [: – [: – [: – [: – ] is a rather boring example (and yes,
>>>>> a strawman). To me this scans as:
>>>>>
>>>>>   "Hey, look how terrible Your Favourite Language L is, where to raise
>>>>> something to the power of 5 you have to do: X * X * X * X * X"
>>>>>
>>>>> never mind that there's an exponentiation operator; move along, move 
>>>>> along.
>>>> Maybe we can discuss facts and allow me to have the feelings I have and 
>>>> express them?
>>>>
>>>> I started working with APL 1979. I have been hanging out in the J forum 
>>>> for years. Now I spent 2 months writing a different J. Believe me, I am 
>>>> not your enemy, I only have a strong will to change things for the better.
>>>>
>>>> I once wrote down all combinations of two and three verbs which are 
>>>> commonly used. It was a lot. I guess there is between 50 and 100 different 
>>>> ways to get the right argument to the right function in a hook and a fork.
>>>>
>>>> I will add a more scientific view to this point in some hours.
>>>>>
>>>>> More constructively: See Roger's comments on whether J should have
>>>>> provided a hook conjunction rather than the train syntax we have now;
>>>>> to me, that's a more interesting discussion and touches on some of
>>>>> your criticisms of length, arity, etc.
>>>> Can you provide a link?
>>>>>
>>>>> Personally I think forks are one of the most important ideas in J.
>>>> I describe the fork in a different way in my article than how it is 
>>>> normally described. I describe one of the differences between explicit and 
>>>> tacit J as taking away the default composition operation between two 
>>>> verbs. Any opinions about this description?
>>>>> ----------------------------------------------------------------------
>>>>> 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

Reply via email to