[Jprogramming] Tacit Expressions with Explicit J Syntax

[Erling Hellenäs]

Hi all !

Here is a related blog post: 
https://erlhelinfotech.wordpress.com/2016/08/01/jwithatwist-or-tacit-j/

Cheers,
Erling

On 2017-09-27 12:25, 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