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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
