[Jprogramming] Tacit Expressions with Explicit J Syntax

Wed Sep 27 13:33:48 UTC 2017

Hi all !

See comments below.

There are still two unanswered questions. You are not required to answer 
them, of course.

Cheers,

Erling Hellenäs

On 2017-09-27 13:36, Henry Rich wrote:
> The syntax is that of explicit J but missing some things, like control 
> words and assignment, and perhaps the ability to write multiline 
> expressions.  If it produces tacit J, it's also not going to be able 
> to define modifiers.
>
I don't know what question this answers. JWithATwist handles modifiers 
during interpretation, in the same way I think tacit J does. To set them 
at runtime you might have to use the same tricks as normal tacit J. Yes, 
I imagine the tacit-v expressions to have the same functionality as 
normal tacit J. No control words and no assignment.
> I just don't see that having a new way to write tacit verbs is a 
> change worth making, if it doesn't allow something that the old way 
> didn't.
And what you can do with a language is the only thing that counts? C++ 
is a million times better than J?
To discuss other arguments for and against the different notations would 
be of no use?
>
> Henry Rich
>
> On 9/27/2017 6:25 AM, Erling Hellenäs wrote:
>> Hi all !
>>
>> See comments below.
>>
>> Henry, you answered one of three questions.
>>
>> Cheers,
>> Erling
>>
>> On 2017-09-27 11:09, Henry Rich wrote:
>>> I have trouble contributing to this because I don't understand your 
>>> proposal as written.  One thing I don't understand is why you call 
>>> your new verbs 'tacit'.  It appeared to me that they used ] and [ as 
>>> tokens indicating the input arguments.  That would make them 
>>> explicit, by the definition of that word.
>> We can call them something different, I just choose tacit-v 
>> expressions for the purpose of my request.
>> They are very similar to tacit expressions. They have exactly the 
>> same functionality, just different syntax, and that syntax is the 
>> syntax of explicit J.
>>>
>>>
>>> The tacit language shows up inside lines of code.  When you write
>>>
>>> sortedbycol1 =: (/:  1&{"1) array
>>>
>>> there a little tacit code there.  We wouldn't want to lose that.
>>>
>>>
>> The tacit-v expression would be
>> sortedbycol1 =: (: ] /:  1 {"1 ] ):
>> if we choose the (: ): brackets. The brackets are needed here as long 
>> as present tacit J is the default.
>> The tacit-t version can be written like this.
>> sortedbycol1 =:  /: 1&{"1
>> Brackets are automatically added, creating the hook. If we directly 
>> compare the notation,
>> ] /:  1 {"1 ] is equivalent to
>> ( /: 1&{"1 )@] if we write code that can be moved between a monadic 
>> and dyadic context without rewrite.
>> However, as I said, the easiest implementation probably is to 
>> continue allowing the present tacit expressions in tacit-v expressions.
>> In the long run you would probably not want both ways to express 
>> exactly the same thing, you would want to let the new tacit-v 
>> expressions replace the present tacit expressions as I see it. There 
>> is a question about how it could be done. One way is to not allow 
>> them in tacit-v expressions from the beginning, as I propose, but 
>> there are other ways. To block them from the beginning would make the 
>> first implementation much harder.
>> sortedbycol1 =: (/: 1&{"1)
>>
>> sortedbycol1 i. _3 4
>>
>> 0 1 2 3
>>
>> 4 5 6 7
>>
>> 8 9 10 11
>>
>>>
>>> All the uninflected delimiters are taken, and {. }. and {: }: and <. 
>>> >. and <: >:; but (. ). and (: ): are available.
>>>
>>> It seems out of the question to redefine any of  { } [  ] as they 
>>> are used in so much existing J code.
>>>
>>> Henry Rich
>>>
>>> On 9/27/2017 4:33 AM, Erling Hellenäs wrote:
>>>> Hi all!
>>>>
>>>> It seems like fast function definitions is only for creating 
>>>> explicit J verbs, adverbs and conjunctions?
>>>>
>>>> This means it is only vaguely related to my proposal of tacit verbs 
>>>> with explicit J syntax?
>>>>
>>>> Maybe the fast function definition discussion should therefore have 
>>>> it's own thread?
>>>>
>>>> Let's say we wanted to implement tacit-v verbs.
>>>>
>>>> -Is there a construct like  { ... } or (. ... ). that could 
>>>> possibly be used for a new kind of bracket notation?
>>>>
>>>> -Would x and y or [ and ] be suitable as symbols of the left and 
>>>> right arguments? If so, which of them ? If not, what would be a 
>>>> suitable representation of the left and right argument ?
>>>>
>>>> -Could the interpreter be easily modified to allow the explicit J 
>>>> syntax in this new bracket construct, or would it be difficult or 
>>>> impossible to achieve?
>>>>
>>>> In the JWithATwist interpreter the difference between how brackets 
>>>> with explicit J code are handled and how tacit-v brackets are 
>>>> handled is about four lines of code. It think this indicates that 
>>>> this might not be such a revolutionary change in terms of actual 
>>>> code changes.
>>>>
>>>> Cheers,
>>>> Erling
>>>>
>>>> On 2017-09-26 22:34, Henry Rich wrote:
>>>>> Good point, colorization.  I never thought about that.
>>>>>
>>>>> The big difference between Fast Functions and 3 : functions is 
>>>>> that Fast Functions are recognized when a script is loaded, 
>>>>> instead of when the 3 : is executed.  It is the fact that 3 : is 
>>>>> executed like any other conjunction that prevents nesting of 
>>>>> multiline verbs: the nested verb can't be defined until it is 
>>>>> executed, and by then its definition is long gone.
>>>>>
>>>>> The innermost (. ).  is analyzed and replaced by (m : string). The 
>>>>> process continues for all nesting levels. This completes the prepass.
>>>>>
>>>>> The generated verbs - (m : string) forms - are handled as they are 
>>>>> now, when the : is executed.  That means nested verbs are not 
>>>>> processed until they are encountered during execution.
>>>>>
>>>>> Linear representation is used to make the (3 : string) form atomic.
>>>>>
>>>>> Yes, you would need to balance (. .
>>>>>
>>>>> Henry Rich
>>>>>
>>>>> On 9/26/2017 4:02 PM, Raul Miller wrote:
>>>>>> Prepass means essentially that this happens after word formation but
>>>>>> before parsing. That does eliminate some problems, but creates new
>>>>>> ones. It also suggests that you would be supporting explicit control
>>>>>> words. But it also means that you need to put a lot more thought 
>>>>>> into
>>>>>> how these would be represented (and stored) - there's no inherent
>>>>>> point to using linear representation to "unparse" here.
>>>>>>
>>>>>> (Do inner (. ). definitions get reparsed every time the outer
>>>>>> expression gets evaluated? That might be the simplest approach, but
>>>>>> does require significant changes in explicit handling.)
>>>>>>
>>>>>> Multiline means that you get into behavior somewhat like you get 
>>>>>> when
>>>>>> m :0 appears on a line. But getting out of that might be more
>>>>>> complicated than it is now (because you might not know if you 
>>>>>> need ).
>>>>>> or a sequence of them or ) to end it - for example after pasting
>>>>>> something big into your session).
>>>>>>
>>>>>> The complexities introduced by multi-line probably means that
>>>>>> interactive environments would want to colorize (. ). definitions
>>>>>> (especially incomplete definitions while being entered) based on the
>>>>>> presence/absence of mnuvxy seen so far (probably not the current 
>>>>>> line
>>>>>> though).
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>> 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