redefine u"v ?
This page is the place to discuss the proposal to redefine u"v .
discussion
Does the idea have merit? Do you have more examples of the desire to calculate a rank? Do you use the current definition of u"v extensively? Would this change create a hardship for you? Are there problems I have not mentioned or foreseen?
I've started a u"v thread on the programming forum to generate interest in the idea; but I would prefer discussion and ideas be collected here, on the wiki.
-- DanBron 2006-11-28 17:19:35
I can see two uses for the existing definition: quick, ad-hoc determination of function rank. For example, +"+. Also, this could be useful where v is a user defined name, particularly if some one else has defined it, and it's subject to change (for example, in an explicit adverb or conjunction). Both of these uses would need to use b.0 instead. (The good news here is that b.0 exists). -- Raul Miller 2006-11-28 16:55:10
I guess I don't understand what you mean by "determination of function rank". How does +"+ "determine" the function's rank? The construct doesn't tell you what the rank of + is, it only assigns to the derived verb the rank of + (which is the purpose of the current definition of u"v). Could you clarify a bit?
- By "ad-hoc", do you imply that such constructs probably are used in immediate-execution mode and would not persist in scripts?
I agree with you about the user-defined verbs. After all, any primitive verb's rank can be looked up in the Vocabulary. That's why I suggested the "fixer script" replace u"v with u " (v b. 0)
In the interests of full disclosure, I do have one use of the current definition; namely <"> . It's hard to describe why I use this, probably because it is just a knee-jerk reaction to avoid having constants in my code. The alternative I'm avoiding is <"0, which I find distasteful (and less pretty than the symmetric <">). -- DanBron 2006-11-28 17:19:35
- If you type +"+ in immediate execution mode, it will display a derived function which has the same rank as + but the rank itself is visible, numerically. I don't see any reason why this should be persisted in a script.
An example where <"> is nicer than <"0 would be the expression <">0. Of course, if your proposal is adopted, this could be approximated with <"0: -- Raul Miller 2006-11-28 17:42:12
That said, I can imagine Roger's reaction: What problem does this solve? Why not simply use an explicit definition for those cases? (In essence, your proposal would drag some of the complexity of explicit definitions into the fundamental representation of non-explicit verbs.)-- Raul Miller 2006-11-28 17:42:12
Tacit code is an end in itself. It is terse, clear, manipuable (subject to contracts, optimizible, invertible), and elegant. My counterargument to your point would be along the lines of "for the same reason we have u^:m (or m}) for gerund m. Why not force those to be in explicit context?" or, more simply, "Why not?".
Having said that, yes, any change to the interpreter (particularly a breaking change) is not free, probably not trivial, and potentially dangerous. Which is why I didn't make this an "official" request.
So, I need to dig up more examples of where calculating a rank would be useful. I've run across the case a few times in my career, but I didn't keep a record. Do you (Raul) have any examples?- It may be hard to find examples simply because the existing definition didn't reward J programmers for thinking of them; so they didn't.
- How is the current definition superior?
-- DanBron 2006-11-28 18:13:26
- I can't think of any good examples where I'd want variable rank and where "_1 would not serve where box/unbox would not better deal with the case.
- After thinking about it, I take back what I said about fundamental function representation. For example, the " operator could use explicit definition, behind the scenes, to support this syntax.
- I think the current definition is superior because it is simpler.
- Here's a bad example of the use of dynamic rank:
{{{example=:3 :0
- +/"(3 e.y)y
)
- example 0 1 2
0 1 2
- example 0 1 2 3
6}}}
-- Raul Miller 2006-11-28 18:35:48
re: your example code: yes, it is more likely that v in u"v will only care about the $ of its arguments than their contents. More specifically, it will probably only care about the #@:$ of its arguments.
- This is a rarer case than I thought. Perhaps the change isn't warranted. However, I have found some examples in the J forum:
I will summarize these in a bit. Go ahead and read them though. (Search for "().
Reading the archives supports the notion that it is more common to want to operate on the ranks of the verb u rather than the nouns x y (though that is non unknown, c.f. the links above).
Given that, shall we consider that v in u"v might actually be more interested in u b. 0 than x and y? And that the proposal might be modified accordingly (if not withdrawn)?
Yes, u"v is simple. It is so simple it is (nearly) useless.
-- MartinNeitzel 2006-12-14 19:07:56:
I'd favour to keep the current meaning. I have no substantial arguments but only my gut feelings on this:
I believe that u"v got used so little because comparatively few people write code at the abstract level of adverbs, adnouns, and conjunctions in general. If more people would dare to create new combinators at the simple level of &, we would see more uses of u"v.
I used u"v only two or three times in all the time (>10 years). In these cases it provided what I needed, though. All in all, I think that u"v provides an important tailoring for adverb/conjunction definitions and this exactly at the needed (non-)complexity level. We better keep this simple, I'd say.
The proposal reminds me of the verb} and gerund} Amend cases where I sometimes have to write extra code to defeat all the possible x/y dependencies I don't need.
- I am suspicious about adverbs/conjunctions which take not just u,v,m,n into account but which are also "strategically" influenced by the values of x,y. I am scared that this too easily violates some boundaries of abstraction layers one better tries to stick to.