[Jprogramming] Tacit Expressions with Explicit J Syntax

[Henry Rich]

I am sorry, but I have not been able to make sense of the last several 
messages.  JWithATwist is outside my area of interest.  If you can 
describe this idea fairly precisely, and explain why it should be 
implemented, I will try to understand it.

To me, yes, what you can do with a language is the only thing that counts.

Henry Rich

On 9/27/2017 10:13 AM, Erling Hellenäs wrote:
> So it would be relevant to discuss this request in terms of programmer 
> productivity?
> Any opinions? /Erling?
>
> On 2017-09-27 16:01, Don Guinn wrote:
>> If you want the most powerful programming language it has to be 
>> assembly.
>> It can do everything that every other programming language can do and so
>> much more. But what is the purpose of languages like J and C++? They 
>> are to
>> make people more productive, not computers.
>>
>> On Sep 27, 2017 7:34 AM, "Erling Hellenäs" <erling at erlinghellenas.se> 
>> wrote:
>>
>> 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
>>>
>>
>> ----------------------------------------------------------------------
>> 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