[Jprogramming] Tacit Expressions with Explicit J Syntax

[Erling Hellenäs]

Hi all !

I imagine that there are big differences between tacit and explicit J. 
If your Fast Function Definition created something similar to tacit 
code, in the meaning that it avoided all mutable state - variables could 
not even be rewritten, did not have side effects which could possibly 
affect the result and if it would basically have explicit J syntax, I 
think it would be a killer implementation of my main thoughts around this.

Even explicit J seems fast these days.

I don't know if tacit code has a speed advantage any more. Long ago with 
APL, if you created any kind of loop, the code would be very slow. You 
could often make it 100 times faster or more if you didn't loop. This 
difference seems to have disappeared.

Does tacit code have any speed advantage?

My proposal is basically a fast function definition (. ) containing only 
x and y, Your proposal covers even all possible adverbs and 
conjunctions. I mention these possibilities in my proposal but I did 
not  implement it all.

You proposal for assignment in tacit code is also very good I think, as 
long as the variables are scoped in the tacit expression where the 
assignment is, can be read only in inner tacit expressions, and can not 
be set again or mutated before the tacit expression is entered the next 
time.

The "verb pipeline" proposal from Dan Bron is also related in the 
meaning that it would probably also be solved with my proposal.

Cheers,

Erling Hellenäs


Den 2017-09-26 kl. 16:33, skrev Henry Rich:
> I don't agree that "someone else has to fill in the details". Maybe 
> someone else has to implement it, but to get them interested there 
> needs to be a detailed proposal, and you're probably the only person 
> motivated to create one.
>
> The great thing about tacit forms is that they span a range from (+/ % 
> #) up to complex multiline verbs.  What distinguishes them is that 
> they have no word indicating an argument.
>
> It appears that you are adding words ] [ to indicate arguments. Why 
> not just use the system words x and y?  Then your proposal is very 
> similar to
>
> http://code.jsoftware.com/wiki/System/Interpreter/Requests#Fast_Function_Definition 
>
>
> isn't it?
>
> Henry Rich
>
> On 9/26/2017 9:31 AM, Erling Hellenäs wrote:
>> Hi all !
>>
>> If there is an interest in implementing this, someone else has to 
>> fill in the details.
>>
>> The easiest way to get this to a working implementation might be to 
>> include the tacit expressions we have now in the new tacit-v 
>> expressions, so that they could be used if the programmer finds a 
>> reason.
>>
>> Then there is a question of if the present tacit J expressions might 
>> fall into oblivion and we in the future might want to take them away. 
>> How that process would be handled in the best way.
>>
>> See comments below.
>>
>> Cheers,
>>
>> Erling Hellenäs
>>
>> Den 2017-09-26 kl. 14:35, skrev Raul Miller:
>>> I have a big problem with this: I have no idea what you think you 
>>> are saying.
>>>
>>> Taken literally, it looks like a request to merge
>>> https://github.com/andrimne/JWithATwist/blob/master/JWithATwist/Parser.fs 
>>>
>>> (and some other parts of that repo) into J. But I do not know what
>>> problems this would solve that would justify this kind of massive
>>> change to the language.
>> From my request: "My proposal is not that the tacit-v expressions 
>> should be like JWithATwist, but that they should be like explicit J, 
>> with the differences mentioned above and some differences mentioned 
>> below."
>>>
>>> In my mind, "J's syntax" means the grammatical rules which a computer
>>> follows when evaluating sentences. Specifically, the rules laid out at
>>> http://www.jsoftware.com/help/dictionary/dicte.htm
>>>
>>> Clearly, your change would require rewriting those rules in some
>>> fashion, and you seem to agree. Your sentence "It should not be
>>> possible to have tacit-t expressions within tacit-v expressions."
>>> suggests that those rules would be abandoned when running your code
>>> instead.
>>>
>>> But what are your new rules?
>>>
>>> J already struggles with documentation issues: We do need examples to
>>> supplement more formal documentation. But that does not mean that
>>> examples without that more formal documentation is going to make
>>> anything easier to understand.
>>>
>>> Meanwhile, your "it's not clear" clauses in this proposal, suggest
>>> that you have not really thought through what kind of syntax rules you
>>> are proposing.
>>>
>>> It's like you do not understand what J's syntax is.
>>>
>>> How would the dictionary have to change, to document the changes you
>>> are proposing?
>>>
>>> Or, if this is not really about J programming (and it might not be),
>>> perhaps this kind of thing really belongs in the chat forum?
>> It's a proposal for a change of the J interpreter, which might be 
>> accepted and implemented or not. In full or in part.
>>>
>>> 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