Re: #\a octothorpe syntax vs SRFI 10

[Taylor Campbell <campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I'd like to point out here that bear left out a lot of the content of
my previous message.  Instead of claiming that my argument is _soooo_
obviously stupid it would embarrass me to respond to it, perhaps bear
could demonstrate why it is so obviously stupid; as it is, it looks
like he is completely ignoring my responses to what he considered so
'painfully obvious.'  Much of what he snipped, in fact, countered much
of what he wrote in his last message, which leads me to believe that
either he is desperate to insert his own points, regardless of their
validity, or he hasn't even read the entirety of my arguments.

On Sun, 2 Jan 2005, bear wrote:

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

What a truly persuasive argument.  You repeatedly _ignore_ all I of the
arguments I have made in favour of a SRFI-10-based syntax, insult my
counter to your only argument (aesthetics), and then claim I lost.  Do
you see how incredibly convicing this is?  (If you're having trouble
finding all of the arguments I made, try looking at the parts of my
messages you so cleverly snipped in your responses.)

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

There is a really easy solution to this -- ignoring the fact that what
you wrote there is illegal Scheme, and won't do what you want to do
even in those Scheme systems that would allow it --: insert a newline.
Here, let me demonstrate:

  (define right-turn-1 #,(array 2 real-32
                           ((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)))

Amazingly, it requires _no_more_columns_ than your version!  In fact,
it could be narrowed _even_more_ by just adding another newline after
the RIGHT-TURN-1 token.

> >>                                                     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:
> 
> [snip irrelevant code examples]
>
> 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.

I'm sorry, but I don't see the relevance of this.  Where does the
brevity of a SRFI-10-based literal array have to do with the matter
you're discussing there?

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

Try reading the text that followed what you quoted there.  Then respond
again.  Here, I'll even give you the text:

                                           Furthermore, what you have
listed here tends to involve very large data sets, which completely
dwarf the difference between '#nA:xxx(...)' and '#,(ARRAY n xxx ...)'.
It is ludicrous that you find such a minute difference to be so
significant.

>                                  Programs need to be able to dump
> this information to file in S-expressions and read it back.

Sure.  What does this have to do with how convenient it is to write
literal arrays in Scheme code?  If the programs call READ & WRITE, you
would never have to even write the #,(ARRAY ...) part!