Neil Toronto: > Wouldn't that depend on what the reader spit out? What if > b[1:5] > becomes > (bracketaccess b (slice 1 5)) > > and > d[0:3,x,5:7,9:] > becomes > (bracketaccess d '((slice 0 3) x (slice 5 7) (slice 9)))
Obviously the reader _could_ do that, or anything else. But to what end? I think history suggests that kind of specialized syntax, to support only one particular semantic, is NOT a good idea for a Lisp: http://www.dwheeler.com/readable/readable-s-expressions.html Specifically, if commas are treated specially inside [...], you now have the problem of expressing comma-lifting. Yes, you could REQUIRE commas, which then means that the comma-lifting is another comma, but now the comma-lifting is really hard to visually detect... and it's an easy error too. Those kinds of unnecessary syntax markers tend to make it harder, not easier, to treat contents in a regular way. Lisp was originally defined with M-expressions; they failed precisely because they were TOO tied to a specific semantic, and as soon as you created a metalanguage with different semantics, its goose was cooked. What makes Lisp still interesting today is precisely its ability to treat program-as-data, and data-as-program. I think it'd be better to find the smallest set of extensions that are EXTREMELY general, and support abilities likely to be seen repeatedly. Obviously, SOME kind of infix meets that criteria. So let's see if we can avoid adding anything else (and if we can't, what's the minimum yet general addition): Instead of: > b[1:5] What's wrong with b[1 5]? > d[0:3,x,5:7,9:] That's obviously trickier. Without additional mechanisms you could use this: d[(0 3) x (5 7) (9)] or d[{0 : 3} x {5 : 7} {9 :}] I'm not sure that it's a good idea to support multiple subslices like this. > ? In Python, what gets passed to getitem/setitem is any object, > including integers and slices (strings for namespace dicts, etc.), or a > tuple of the same. Heck, you could stipulate that a list is always > passed, even if it's singular, and obtain a nice analogy between list > construction using [] and indexing using []. Can you clarify what you mean here? I know Python, but I'm not sure what you mean by this comment. --- David A. Wheeler ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
