I think what I write about Amend is comprehensible to most of the
audience so I avoid that discussion. You can see the JWithATwist
solution in the manual.
https://github.com/andrimne/JWithATwist.DocBook/blob/master/target/en/JWithATwistReferenceManual.pdf
I don't understand your paragraph numbering and not to what you agree or
disagree.
These changes would create other problems like the one with rank and I
don't know the solution to all these problems.
You are all welcome to comment on my blog.
J is the work of lots of scientists and very clever people over many
years and these are my personal opinions. Ideas I play with in
JWithATwist. Ideas which might show up as good or bad, clever or stupid
when discussed, examined and tried.
Cheers,
Erling
On 2016-08-11 00:16, Raul Miller wrote:
Here is a rough sketch of my thinking on reading this presentation. I
do not know if you will find this helpful or not. But, you might, and
you spent some time and effort writing that, so... here goes:
Paragraph 1: J allows an arbitrary number of arguments (0 or more) for
the right argument of a verb and an arbitrary number of optional
arguments for the left argument of a verb.
Paragraph 2: I agree. And this holds true, also, for unboxed arguments.
Paragraph 3: Hmm... I am not sure I agree with the objective parts of
this, but let's roll with it for now.
Paragraph 4: Er... so, for example:
_1 _2 (1 2;3 4)} i.5 5
0 1 2 3 4
5 6 _1 8 9
10 11 12 13 14
15 16 17 18 _2
20 21 22 23 24
Here, I used boxed arguments to amend. So, there's that. But I am
guessing what you really meant is that you instead want something that
achieves the same result, but with arguments structured like this:
amend _1 _2;(1 2;3 4);i.5 5
(But of course this would create a new problem in the context of the
rank operator - you would need a new variation of the rank operator
which worked for arguments which are structured in this fashion.)
(Also, that is not what you said, what you said flatly contradicts
what I know, and I think I showed an example of this... but that
probably means that I was just missing your actual point for other
paragraphs as well.)
There actually are reasons to use short names - they are faster to
type, they fit in tweets, and they are more manageable in a "let's try
another variation of this again" than the longer names. That said, you
can look at things like OpenGL as a counter example - here, we have
long names and lots of them. But here also we have problems with
people declaring frequently used chunks of it "deprecated" despite how
many frequently used things would break if people actually stopped
supporting the older stuff.
(Personally, I think obsolescence should become obsolete. And, in a
sense, it has been, but there's a lot of junk that falls by the
wayside over time, and that does become a problem...)
...
Last paragraph: My above (x m} y) example is explicitly documented.
Specifically, the indexing behavior of } is defined in terms of { at
http://www.jsoftware.com/help/dictionary/d530n.htm and boxed indices
are mentioned at http://www.jsoftware.com/help/dictionary/d520.htm#.
So the implication that I understand (that amend supporting boxed
indices should be thought of as hidden information) probably is not
what you are referring to, here. But ... that leaves me not knowing
what you were thinking about here.
Once again, I do not know if this will help you in any way, but I
think you were inviting comment, and this is as far as I got. (Plus,
you know, your page will stay up indefinitely, and my comments would
be invisible to most readers of your page, so there's that, also.)
Thanks,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
