The line "Use (. ... ). to be recognized as m : '...' where m is
chosen based on occurrence of xyuvmn" in
http://code.jsoftware.com/wiki/System/Interpreter/Requests#Fast_Function_Definition
suggests that we would use m : '...' for the display format of those
function definitions.
That said, (. x u . v y ). would need to be something like
2 :(':',LF,'x u . v y')
Still, we could at least lay out the rules for picking the value of m
and for adding to the definition:
if n (or v) is present in the parsed words of defn, we generate 2 : defn
if not, but if m (or u) is present, we generate 1 : defn
if x is present, we precede defn with ':',LF,
If neither u nor v is present but x or y is, we generate 3 : defn
Note also, though, this is a much bigger problem than it might first
appear to be, since it would require new parsing rules for the syntax
table. And we have not nailed down some of the other specifics:
First (minor problem): this leaves unspecified what to do if none of
the key names are present. Hypothetically, that could be 0 : defn or 3
: defn or 4 : defn or something else. Perhaps an error condition, on
the grounds that the programmer probably did not mean to be doing
that.
Second (bigger issue): we have not said whether (. ). would nest. If
implemented at the parsing level, it could easily nest. But that's a
different syntax than an unnestable implementation, and creates
further problems
Third issue (potential side effect of using the parser to handle
nesting): we would probably have to treat u and v as special
placeholder verbs during that parsing process, then hope that the
resulting linear representation does not create conflicts if we pass
noun arguments.
Fourth (potential breaking issue): if they nest we would need to use a
linear representation of the inner instances in the outer instances.
This would break if the (. ). contained an explicit definition with a
non-evaluatable linear representation (for example an explicit
definition with more than two lines).
As a crude illustration of that fourth issue, imagine:
(. v (2 :(':',LF,'t=. x v . u y',LF,'t')) u ).
That said, depending on the details of how this was implemented, some
of these "issues" might turn out to be non-issues. Forbidding nesting,
for example, would defeat most of these problems (and, probably, a lot
of the motivation for doing this in the first place).
But, anyways... implementing this might be a bit more involved than it
first appears, depending on how these kinds of subtleties are handled.
(And, that has implications for documentation).
Thanks,
--
Raul
On Tue, Sep 26, 2017 at 12:39 PM, Jose Mario Quintana
<[email protected]> wrote:
> The proposal,
>
> http://code.jsoftware.com/wiki/System/Interpreter/Requests#
> Fast_Function_Definition
>
> is also similar to a very old idea,
>
> http://www.jsoftware.com/pipermail/programming/2009-December/017425.html
>
> with the innovation "m is chosen based on occurrence of xyuvmn"
>
> :)
>
>
> On Tue, Sep 26, 2017 at 10:33 AM, Henry Rich <[email protected]> wrote:
>
>> 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/JWithATw
>>>> ist/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
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
