Here's an example of three arguments in an unboxed argument list: - 2 3 4
The thing that boxing gets you is the ability to have different kinds of argument mixed together. -each 2;(i.3);i.4 5 You can also do things that don't really make sense, like this: -each 'a';'bcd';'fg' if you want to generate errors, for example. But I guess what we are really saying is that we can use good examples of the things we are talking about. And that goes for other things, like the whole "syntax / name" dichotomy. You talked about terse syntax and I immediately thought of the symbols (or names) that get used with the syntax. 1 + 2 3 op 4 From your comments, you were thinking about something else, but since you included no examples I obviously did not understand what you were thinking. I hope this helps, -- Raul On Thu, Aug 11, 2016 at 10:07 AM, Erling Hellenäs <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
