[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: #\a octothorpe syntax vs SRFI 10
On Sun, 2 Jan 2005 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
>On Sun, 2 Jan 2005, bear wrote:
>> Arrays are damned useful, and being able to write them succintly
>> is damned useful. It's true enough that scheme code is mostly lists,
>> but that doesn't mean that a succinct syntax for arrays wouldn't be
>> very useful, nor does it mean that SRFI-10 syntax is good enough for
>> everything that isn't a list.
>This is a completely undefended assertion. You claim that arrays
>should have a succinct syntax without stating why that is so, and you
>again fall back to the nebulous aesthetics to claim that SRFI 10 'isn't
>good enough' for arrays.
And your claim that it is good enough is based on what? Look, I'm
going to quit responding on this subpoint: there is no reason
whatsoever *EXCEPT* aesthetics to pick any external syntax over
any other. You lost (so badly that you are now forced to disparage
as "nebulous" the only possible argument), so deal with it.
>> Different coders, different code. When I'm storing aggregations of
>> things, I usually use vectors for access speed rather than lists.
>> Doing so is extremely awkward in Scheme. I only use lists in code
>> where they're either "the right thing" for that particular application,
>> or I'm being deliberately lazy and not optimizing.
>Sorry, I meant '...more frequently than arrays in Lisp's syntax.' (It
>was originally part of the first point, but, when splitting it off into
>a separate point, I forgot to include the 'in literal syntax' part.)
My source code in some cases is almost five percent literal vectors.
A recent example:
;; transformation matrix for a camera right turn of 0.1 radians.
(define right-turn-1 #( #((cos 0.1) (sin 0.1) 1.0 1.0)
#((sin 0.1) (cos 0.1) 1.0 1.0)
#(1.0 1.0 1.0 1.0)
#(1.0 1.0 1.0 1.0)))
I don't want a front-loaded syntax because it will push the
indentation level over further than is convenient to work with.
>> I even go so far
>> as to implement "closure" arrays for succinct reference and mutation
>> instead of going through vector-ref and vector-set!. Not being able
>> to write an external form for such gets in my way.
>Perhaps you could elaborate on this: I don't quite understand what you
I define mutable arrays using a constructor that returns a pair of
procedures - one for reference and one for mutation. So I can
do something like this:
(let ((m (closure-array 4 4)))
(define foo (car m))
(define foo! (cdr m)))
(define foo (vector (make-vector 4) (make-vector 4) (make-vector 4) (make-vector 4)))
(foo 2 3)
(vector-ref (vector-ref foo 2) 3)
(foo! 2 3 #\a)
(let ((z (vector-ref foo 2)))
(vector-set! z 3 #\a)
(vector-set! foo 2 z))
But this trick, however useful, is limited because the arrays I
can use with it are actually procedures, and procedures lack a
reliable read-write syntax.
This is just one example of the crap I go through to circumvent
the clumsiness of arrays in scheme, and one example of why I wish
they were as natural (and succinct) as lists.
>> > often do you find yourself wanting to write a literal array, except
>> > as the first argument to SRFI 47's MAKE-ARRAY?
>> Geez, let me count the ways. Data tables for character properties.
>> color palettes. Graphic sprites. Coordinate transformation matrices.
>> cellular automata substructures. Default Window coordinate lists.
>> Map data. Integrated-circuit diagrams. Alias tables for character
>> names. Parallel Records. Tuple aggregates. Multi-Character tokens
>> for protocol drivers. Image data. Compiler transition tables. Tax
>> rate tables. Icons. Lists of countries, states, counties, and
>> municipalities. Bus routes. Airline schedules. Cellular coverage
>> areas. And the list goes on...
>Great. So you've listed a lot of applications for arrays. Now answer
>the question I asked: how often do you find yourself in Scheme code
>wanting to write literal arrays by hand?
Look again at the list. Those are precisely what you asked for:
all are applications of STATIC arrays.
These are places where I want immutable arrays during runtime, and
the only way to get an immutable anything in scheme is to write it
directly. At least up through debugging, I write these directly,
making them immutable.