Yesterday, Neil Toronto wrote:
> Without extra assumptions, it's impossible to tell what's supposed
> to be an element and what's supposed to be a row. For example, this
> is ambiguous:
>
> (array ((list 1 2)))
>
> It could be a one-dimensional array containing just '(1 2), or a 1x3
> array containing 'list, '1 and '2.
>
> My current "extra assumption" is that "[" means "this is a row", and
> anything else means "this is an element". The extra assumption could
> also be that everything is quasiquoted, and then the shape of the
> parens wouldn't matter.
I'm probably missing the problem, which wouldn't be surprising since I
didn't even tried to look up the `array' documentation... But, there
are two things that seem relevant:
1. For just plain vector syntax, you still have quasiquotes do the
usual thing, it only happens that #(...)s are implicitly quoted.
So:
-> #((list 1 2))
'#((list 1 2))
-> #(,(list 1 2))
'#(,(list 1 2))
-> `#(,(list 1 2))
'#((1 2))
2. Alternatively, the last paragraph that you wrote above can also be
easily translated by just replacing "[" with "#(", so the array
macro distinguishes its contents based on that:
-> (define-syntax foo
(syntax-rules ()
[(foo #(x ...)) (list 'array x ...)]
[(foo x) (list 'datum x)]))
-> (foo (+ 1 2))
'(datum 3)
-> (foo #((+ 1 2)))
'(array 3)
It's obviously a trivially simple example, but if you currently
just dispatch on the paren-shape, then using #(...) instead should
work just as well, be more robust, and not introduce the
shape-dependent feature.
Am I missing something?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
