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.
On Dec 4, 4:58 pm, "metaperl.com" <········@gmail.com> wrote:
> Positionally speaking, why is the data structure the first argument to
> aref yet the second argument to gethash?
>
History.
From: Kent M Pitman
Subject: Re: (aref ary i) versus (gethash k hash) --- inconsistent?
Date:
Message-ID: <ueje22gf3.fsf@nhplace.com>
Tim Bradshaw <··········@tfeb.org> writes:
> On Dec 4, 4:58 pm, "metaperl.com" <········@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.,
(proclaim '(inline hashget))
(defun hashget (table key &optional default)
(gethash key table default))
(defun (setf hashget) (value table key &optional default)
(setf (gethash key table default) value))
In article
<····································@p69g2000hsa.googlegroups.com>,
"metaperl.com" <········@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, ······@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 ***
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. ...
Another way we have sought regularity is in argument passing
conventions. Accessors take aggregate arguments first, and selector
arguments following (like array referencing, and is unlike Maclisp's
NTH). Assignment routines take the value to be stowed as their last
argument. Optional arguments go last.
</quote>
From "T: A Dialect of Lisp", by Jonathan Rees and Norman Adams IV
� 1982 ACM 0-89791-082-6/82/008/0114
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.
- Daniel
From: Ken Tilton
Subject: Re: (aref ary i) versus (gethash k hash) --- inconsistent?
Date:
Message-ID: <NIr5j.8967$Id1.196@newsfe10.lga>
D Herring wrote:
> 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. ...
Not to mention peloria.
kzo
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
···@telent.net wrote:
> Ken Tilton wrote:
>
>> Not to mention peloria.
>
> And how does lemur skin reflect the sea?
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]).
- Daniel
D Herring wrote:
>
> 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. ...
>
> Another way we have sought regularity is in argument passing
> conventions. Accessors take aggregate arguments first, and selector
> arguments following (like array referencing, and is unlike Maclisp's
> NTH). Assignment routines take the value to be stowed as their last
> argument. Optional arguments go last.
> </quote>
> From "T: A Dialect of Lisp", by Jonathan Rees and Norman Adams IV
> � 1982 ACM 0-89791-082-6/82/008/0114
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.
From: Kent M Pitman
Subject: Re: (aref ary i) versus (gethash k hash) --- inconsistent?
Date:
Message-ID: <uhciwrabf.fsf@nhplace.com>
Chris Riesbeck <··············@gmail.com> writes:
> D Herring wrote:
> > 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. ...
> > Another way we have sought regularity is in argument passing
> > conventions. Accessors take aggregate arguments first, and selector
> > arguments following (like array referencing, and is unlike Maclisp's
> > NTH). Assignment routines take the value to be stowed as their last
> > argument. Optional arguments go last.
> > </quote>
> > From "T: A Dialect of Lisp", by Jonathan Rees and Norman Adams IV
> > � 1982 ACM 0-89791-082-6/82/008/0114
>
> 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 <······@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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Kent M Pitman <······@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, ······@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 ***
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.
Joost.
+ Kent M Pitman <······@nhplace.com>:
> 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 Dec 4, 8:58 am, "metaperl.com" <········@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.
You're bringing up an issue? Where?
On Dec 4, 8:58 am, "metaperl.com" <········@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.