[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
>mean here.

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)))

instead of
(define foo (vector (make-vector 4) (make-vector 4) (make-vector 4) (make-vector 4)))

and thereafter:

(foo 2 3)
instead of
(vector-ref (vector-ref foo 2) 3)

and

(foo! 2 3 #\a)
instead of
(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.

>>  How
>> >    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.

				Bear