[racket] Math library ready for testing

This version is also easier to generalize to higher-dimension arrays (compared with dimension-specific keywords or separators). Every time I try to come up with a nicer way to describe an array, I keep coming back to this same shape/contents notation. 

---
Justin Slepak
PhD student, Computer Science dept.

----- Original Message -----
From: Neil Toronto <neil.toronto at gmail.com>
To: Danny Yoo <dyoo at hashcollision.org>
Cc: users at racket-lang.org
Sent: Fri, 7 Dec 2012 22:50:57 -0500 (EST)
Subject: Re: [racket] Math library ready for testing

On 12/07/2012 07:57 PM, Danny Yoo wrote:
>
>     Or maybe using a : or something to separate rows for 2D arrays?
>     (array 1 2 : 3 4)
>
>     (array 1 0 0 0 0 0
>           : 0 1 0 0 0 0
>           : 0 0 1 0 0 0
>           : 0 0 0 1 0 0
>           : 0 0 0 0 1 0
>           : 0 0 0 0 0 1)
>
>
> What about something like:
>
>      (array #:cols 6
>        1 0 0 0 0 0
>        0 1 0 0 0 0
>        0 0 1 0 0 0
>        0 0 0 1 0 0
>        0 0 0 0 1 0
>        0 0 0 0 0 1)
>
> where an extra #:cols argument lets the system know now many columns
> there are per row?

This works right now, and is pretty close:

   (make-mutable-array
    #(6 6)
    #(1 0 0 0 0 0
      0 1 0 0 0 0
      0 0 1 0 0 0
      0 0 0 1 0 0
      0 0 0 0 1 0
      0 0 0 0 0 1))

It gets a little uglier when you want to override TR's generalization 
for polymorphic, mutable types. For example, you'd have to apply (inst 
make-mutable-array Byte) to get a (Mutable-Array Byte) instead of a 
(Mutable-Array Integer). No problem in untyped Racket, of course.

There's no shape check on the data, though, so it'd be really easy to 
make an array with values in the wrong places.

As far as using (array [[...]]) - no hashes - it used to work like that. 
The `array' macro would check the shape of the parens to determine 
whether (e ...) was meant to be a row like [list 1 2 3] or an element 
like (list 1 2 3). The problem is, that's a syntax property, which 
macros rarely preserve, and Scribble couldn't render them properly. In 
general, it would be too easy for array literals computed or transformed 
at syntax time to lose their shape and meaning.

Using commas, dots and semicolons is out of the question. Colons would 
clash with TR's use in types. Other punctuation is sinfully ugly. I'm 
afraid the only real option for something with a little less visual 
clutter is a reader extension or a custom language. I considered it, but 
in the end I rejected #lang math. I just didn't have the hubris for it. :D

Neil ⊥

____________________
  Racket Users list:
  http://lists.racket-lang.org/users