See comments.
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.
You can have many arguments in an unboxed argument?
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.)
I can't follow the last paragraph. Maybe Amend in the JWithATwist manual
is the explanation.
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.
In most common programing languages today names of functions and
variables are long. The program and the environment is often complex.
Long names are needed to describe complex operations in a complex
environment. We choose to make the code self-documenting because we know
we will have problems keeping any documentation up to date. We copy and
paste, we can rename functions and variables in the whole program or the
whole workspace, there is autocomplete. With these tools long names does
not slow us down. Short names would also cause problems with rename and
refactoring.
I don't mean we should remove the symbols for our operations. When you
have some short complex operation you often can't describe it in words,
there are no reasonable names for the variables, the notation is then
the description you need. For these reasons you can also sometimes
choose to have short function and variable names. These short snippets
most often require comments and some up-to-date written documentation,
as I see it.
(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
