>>>>>"Ben" == Ben Wing <ben(a)666.com&gt; writes: >>>>> >>>>> Ben> i originally decided that it was a bad idea to allow Ben> aset/aref to operate over char-tables and range-tables, like Ben> FSF does. but now i'm not so sure. I have no opinion, except that the analogy to Python is weak precisely because we don't have slicing. I don't necessarily thing that's a serious fault.

Ben Wing <ben(a)666.com&gt; writes: >i originally decided that it was a bad idea to allow aset/aref to >operate over char-tables and range-tables, like FSF does. but now >i'm not so sure. for one, i recently added a change to use >char-tables in place of 256-element vectors for the return value of >`make-display-table', and code in w3 and x-symbol (and probably >elsewhere) broke. > > I think aset/aref make for array-like objects, that is, random-access data structures indexed by integers. If char-tables and range-tables use special character properties, other than its code, to "find" the value, they are IMHO not good candidates for aset/aref. make-display-table is a question of backward and possibly of cross-Emacs compatibility. There might be good ways to handle that, but they seem orthogonal to your primary question. >but more to the point, i'm influenced by python, which uses [] for >accessing arrays and hash tables ("dictionaries"), including ranges >in arrays (the slice notation); and both char-tables and >range-tables are basically just sparse arrays, with some >optimizations. > > Python's [] is much more than array access: it's a syntactic shorthand for __getitem__/__setitem__, and it's these generic concepts that we lack. If we do introduce them, they should work on all kinds of objects (e.g. hash tables and lists), and in that case we should choose names better than aref/aset, because those concepts are quite detached from traditional meanings of "array".

Ben Wing <ben(a)xemacs.org&gt; writes: >>Python's [] is much more than array access: it's a syntactic shorthand >>for __getitem__/__setitem__, and it's these generic concepts that we >>lack. If we do introduce them, they should work on all kinds of >>objects (e.g. hash tables and lists), and in that case we should >>choose names better than aref/aset, because those concepts are quite >>detached from traditional meanings of "array". >> >> >> >is there any reason that aset/aref couldn't be extended semantically >to be the equivalent of python's [] (which, after all, was also >originally an "array reference" syntax)? > >

I suppose they could, but their implication of "array" would sound weird to me. That's the naming issue I referred to by "choose names better than aref/aset". While it's true that in other languages [] means array access, in Python I believe [] was used for dictionary accesses, string accesses, and also for slices, from the start. Using the names aref and aset sort of implies that all these things are arrays, which they are not (except in the loose sense of "associative array", but that term seems to be losing popularity, even in Perl). My point is that if we introduce a new concept, we should introduce a new name to match it. Then we can add slices, setf-ability, and perhaps other features, from the start.

>char tables are indexed by character and nothing else, but can take >a charset or something similar as a shorthand for setting a value >for all chars in the charset. range tables are very similar but you >can set ranges of integers instead of charsets. > > Then I wouldn't really say that they are good candidates for aset/aref, in an "API design" sort of way. But if you feel they're good for compatibility, go ahead and put them in; I won't complain.

Hrvoje Niksic wrote: > Ben Wing <ben(a)xemacs.org&gt; writes: > > > >>> Python's [] is much more than array access: it's a syntactic shorthand >>> for __getitem__/__setitem__, and it's these generic concepts that we >>> lack. If we do introduce them, they should work on all kinds of >>> objects (e.g. hash tables and lists), and in that case we should >>> choose names better than aref/aset, because those concepts are quite >>> detached from traditional meanings of "array". >>> >>> >> >> is there any reason that aset/aref couldn't be extended semantically >> to be the equivalent of python's [] (which, after all, was also >> originally an "array reference" syntax)? >> > > > > btw Hrvoje could you *PLEASE* *PLEASE* not remove my name from the Cc: list? afaik it is now considered very bad netiquette to do that; removing duplicate mails on your end is trivial using procmail. you should not be kludging around a bug and messing up people like me in the process.

Ben Wing <ben(a)666.com&gt; writes: >but please realize that it is not considered proper netiquette to >pre-remove duplicates, > > That is simply not true. If it were true, we wouldn't have so many people enforcing it by placing bogus Reply-To headers on their mailing list and, in fact, requesting such headers. I have no problems respecting your wishes in this, but please don't justify them with "netiquette".

Ben Wing <ben(a)xemacs.org&gt; writes: >well, but how do you think the extension from [] = array to [] = hash >tables, etc. came about? by the exact process of semantic extension. >whether is what "there at the beginning of python" is irrelevant since >python extended this notation from other languages, > > That it was there at the beginning is exactly relevant to my point, which is that Python *introduced* that notation from the start, it didn't extend it from array access. I agree that it is extended in the sense that the operator was borrowed from other languages where it denoted array access. However, a syntactic shorthand is useful for that kind of thing because it denotes a function without naming it "array". (Python does use names for its methods, and then it's called get/set-item.) I believe that "aref" stands for "array reference" and that the name is a bad one outside the array context. I don't have a really good alternative name handy; maybe I would call it "item". In that case it should be setfable and support CL-style keyword arguments such as :start and :end for slices. >>>char tables are indexed by character and nothing else, but can take >>>a charset or something similar as a shorthand for setting a value >>>for all chars in the charset. range tables are very similar but you >>>can set ranges of integers instead of charsets. >>> >>> >>Then I wouldn't really say that they are good candidates for >>aset/aref, in an "API design" sort of way. But if you feel they're >>good for compatibility, go ahead and put them in; I won't complain. >> >> >> >> >what makes them not good? the fact that they can take objects other >than integers as set arguments? > > The fact that they don't look up values using an integer index, the way an array does.

>btw i semantically extended `get' from symbol properties to general >properties, and you seemed to like it. > > In that case the name `get' at least didn't imply a symbol argument. On the other hand, `symbol-plist' does, which is why I assume `object-plist' was introduced.