Positionally speaking, why is the data structure the first argument to aref yet the second argument to gethash?
To my mind, in either case you are supplying an INDEX to a DATUM and consistency would be easier to remember. Not to mention if you wanted to create a curried version.
Although I suppose macros could handle any issue that I am bringing up.
In article <e1e779d3-b11b-4175-8890-02c6cbf7e...@p69g2000hsa.googlegroups.com>,
"metaperl.com" <metap...@gmail.com> wrote: > Positionally speaking, why is the data structure the first argument to > aref yet the second argument to gethash?
> To my mind, in either case you are supplying an INDEX to a DATUM and > consistency would be easier to remember. Not to mention if you wanted > to create a curried version.
> Although I suppose macros could handle any issue that I am bringing > up.
Because AREF needs to take the indices as an &REST argument, for multidimensional arrays, and &REST has to be last.
Most other functions of this sort take the single index first -- NTH, ASSOC.
-- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
Tim Bradshaw <tfb+goo...@tfeb.org> writes: > On Dec 4, 4:58 pm, "metaperl.com" <metap...@gmail.com> wrote: > > Positionally speaking, why is the data structure the first argument to > > aref yet the second argument to gethash?
> History.
Yep. And keeping code working isn't a bad thing.
I agree it's the conceptually wrong order if the design were done anew, but one can't restart the language every time one gets a new idea. We added abstraction and packaging facilities in the language so one could work around this. e.g.,
metaperl.com wrote: > Positionally speaking, why is the data structure the first argument to > aref yet the second argument to gethash?
> To my mind, in either case you are supplying an INDEX to a DATUM and > consistency would be easier to remember. Not to mention if you wanted > to create a curried version.
> Although I suppose macros could handle any issue that I am bringing > up.
Not a new question at all.
<quote> In designing T, we decided not to constrain ourselves by adhering to Lisp tradition. Instead, we have sought to regularize the language even if incompatibilities are introduced. ...
As Kent noted, Lisp macros and inline functions allow a great deal of flexibility in fixing the syntax for new projects; but no standard has taken root, probably because it is "too easy" to develop workarounds.
>> Positionally speaking, why is the data structure the first argument to >> aref yet the second argument to gethash?
>> To my mind, in either case you are supplying an INDEX to a DATUM and >> consistency would be easier to remember. Not to mention if you wanted >> to create a curried version.
>> Although I suppose macros could handle any issue that I am bringing >> up.
> Not a new question at all.
> <quote> > In designing T, we decided not to constrain ourselves by adhering to > Lisp tradition. Instead, we have sought to regularize the language even > if incompatibilities are introduced. ...
On Dec 4, 8:58 am, "metaperl.com" <metap...@gmail.com> wrote:
> Positionally speaking, why is the data structure the first argument to > aref yet the second argument to gethash?
Consistency with the C language:
int putc(int, FILE *); int fseek(FILE *, long int, int);
But note that aref takes a variable number of arguments for additional dimensions, so it would be awkward not to have the object first regardless of any consistency with unrelated functions.
> To my mind
To my mind, your discussion here won't change a damn thing. You will still have to supply arguments to GETHASH in the required order, or else use wrappers.
> Not to mention if you wanted to create a curried version.
Currying has nothing to do with argument order; it's a semantic idea.
You can take a function F which has m arguments, and produce a function G having k < m arguments which passes its k arguments to F, and supplies fixed values for the remaining m - k. Those remaining F arguments which are fixed by G can be in any positions whatsoever.
To express this general currying, you just need a more general syntax than merely writing a call to F with missing arguments, where the missing ones are understood to give rise to a function.
> Although I suppose macros could handle any issue that I am bringing > up.
> <quote> > In designing T, we decided not to constrain ourselves by adhering to > Lisp tradition. Instead, we have sought to regularize the language even > if incompatibilities are introduced. ...
And at the time, as a T programmer, I was really upset that PUSH was changed in T to (PUSH list item). Decades later, it still feels wrong. Didn't really matter though. I lived to write lots of code in T.
> And at the time, as a T programmer, I was really upset that PUSH was > changed in T to (PUSH list item). Decades later, it still feels > wrong. Didn't really matter though. I lived to write lots of code in T.
Heh. Yeah, looks funny to me, too, at least now, and I may have even been in on the actual choice--I don't recall any more. At minimum I would have been party to the discussions and had the opportunity to object... it was basically only Jonathan and Norman and me at that point (summer of 1982, I think, though it's slightly possible it was '81). We used to do every-Tuesday meetings where we would reconsider some major chunk of sacred wisdom of Lisp and decide if we were going to let it through. This was one of the milder choices. There were days when symbols, arrays, etc. were on the chopping block... a bunch of them got through. :) Plus we were designing the object system, inventing T's locales, etc. So at this point in time, anything as small as PUSH seems like small it's in the noise (which is probably one sub-point you're trying to make ... there's only so much small stuff one can sweat without losing track of the big stuff).
Back to the original point, I think in English, some verbs take postional args (objects) and some have objects that can move around, and some can do either. "Give John the ball" is positional. "Give the ball to John" takes advantage of an optional guide word. There is no positional for "Push x y" in English, only in nerdspeak. You have to say "Push x onto y" (or "into" or some other preposition). And having done so, you can freely move it. "Push onto y x" works, too. I think probably the thought at the time was that you could get just as used to saying "push ONTO list item" as the other, even though that was untested. It was probably a feeble wish.
But the stronger issue in the design, with which I take your message to be offering agreement, is that an idiosyncracy is easier to accommodate if there's a supervening reason--in this case the overall language regularity. Worst of all is to be capriciously incompatible, that is, incompatible but without achieving any alternate/higher goal.
Kent M Pitman <pit...@nhplace.com> wrote: +--------------- | Back to the original point, I think in English, some verbs take | postional args (objects) and some have objects that can move around, | and some can do either. "Give John the ball" is positional. | "Give the ball to John" takes advantage of an optional guide word. | There is no positional for "Push x y" in English, only in nerdspeak. | You have to say "Push x onto y" (or "into" or some other preposition). | And having done so, you can freely move it. "Push onto y x" works, too. | I think probably the thought at the time was that you could get just | as used to saying "push ONTO list item" as the other, even though | that was untested. +---------------
Hardly "untested", since that's the way the PDP-10 opcode of the same name worked! ;-} ;-}
PUSH LIST, ITEM
...where LIST here is the name of some general register (other than 0) to be treated as a stack pointer (usually named "P").
[Note for non-PDP-10 folk: PDP-10 stacks grew *upwards*...]
-Rob
----- Rob Warnock <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
> Kent M Pitman <pit...@nhplace.com> wrote: > +--------------- > | Back to the original point, I think in English, some verbs take > | postional args (objects) and some have objects that can move around, > | and some can do either. "Give John the ball" is positional. > | "Give the ball to John" takes advantage of an optional guide word. > | There is no positional for "Push x y" in English, only in nerdspeak. > | You have to say "Push x onto y" (or "into" or some other preposition). > | And having done so, you can freely move it. "Push onto y x" works, too. > | I think probably the thought at the time was that you could get just > | as used to saying "push ONTO list item" as the other, even though > | that was untested. > +---------------
> Hardly "untested", since that's the way the PDP-10 opcode of the > same name worked! ;-} ;-}
> PUSH LIST, ITEM
> ...where LIST here is the name of some general register (other > than 0) to be treated as a stack pointer (usually named "P").
And 30 years later, Perl has
push @array, $item
However, in this case I think it's for the same reason that AREF takes the indices last: Perl's push is n-ary, i.e. you can write
push @array, $item1, $item2, ...
and varargs generally work best at the end of argument lists.
-- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
> You have to say "Push x onto y" (or "into" or some other preposition).
Nah, it has to be "onto". The notion of pushing something /into/ a stack brings up entirely the wrong picture in my head, at least.
-- * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/> - It is undesirable to believe a proposition when there is no ground whatsoever for supposing it is true. -- Bertrand Russell
On Wed, 05 Dec 2007 23:41:21 -0500, Barry Margolin wrote: > And 30 years later, Perl has
> push @array, $item
> However, in this case I think it's for the same reason that AREF takes > the indices last: Perl's push is n-ary, i.e. you can write
> push @array, $item1, $item2, ...
> and varargs generally work best at the end of argument lists.
That seems to me to be a reasonably persuasive argument (heh), though the reasons you can't always reverse the order for varargs are probably mostly syntactical.
Another reason that this order seems the more logical to me is that I'm used to (or if you prefer, perverted by) the usual (more or less) OO programming languages and their libraries, where the first argument, irregardless of syntax, is almost always the object acted upon/changed by the call, provided you can identify the object "most changed" by the call.
I know that this doesn't have to be a rule written in stone, especially when you've got something as flexible as CLOS, but for calls involving collections and elements it just seems to be the least surprising to me to have the collection as the first argument.
On Dec 4, 8:58 am, "metaperl.com" <metap...@gmail.com> wrote:
> Positionally speaking, why is the data structure the first argument to > aref yet the second argument to gethash?
I'm surprised that nobody has remarked about how myopic this assumption is: that the hash is the Important Data Structure that should be factored out to the left.
In fact, the important structures are the keys and values. The hash specifies which relationship between keys and values is desired.
The key is the object, and the hash is a selector which retrieves a particular attribute of that object. We can add ``slots'' to simple integers:
;; retrieve several properties of employee 42 (gethash 42 *last-name*) (gethash 42 *first-name*) (gethash 42 *salary*)
Obviously, the number 42 is the container here, semantically speaking.
I think Ken was using fancy words to say "sometimes consistency is a bad thing". In this case, even though the argument lists of these functions could be regularized, should they? Taken individually, what is the "correct" list for each command? If the results are inconsistent, is that reason enough to change them?
Consistency aside, I prefer (gethash hash key) -- but that's just me (possibly corrupted by the C++ STL notation hash[key]).
