Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Yesterday, Neil Toronto wrote: > > I wouldn't want to write that, either. Right now, you'd write > >(array > #[#[(list (1- i) (1- j)) (list i (1- j)) (list (1+ i) (1- j))] > #[(list (1- i) j ) (list i j ) (list (1+ i) j )] > #[(list (1- i) (1+ j)) (list i (1+ j)) (list (1+ i) (1+ j))]]) > > The vector syntax just delimits rows; it never quotes. OK, so it's like the `array*' I suggested later, right? If that's the more useful use case, then it probably makes sense to have `array' do it. (It should be clear in the docs, of course.) BTW, I didn't realize that this is a syntax that construct something completely different. What happens when I want to have a plain vector as a value? Forcing me to use `vector' for that seem a bit odd. > Square parens aren't required, but make rows easier to distinguish. (I don't care much -- I just stuck to #()s to stress the fact that they shouldn't matter.) > Arrays' custom printers print square parens, which gives feedback > when a user is confused about whether #(...) means a row or a > vector-valued element. Related to the above BTW -- if I can't write vector literals in code, then it's probably a bad idea to show them in your printed representation. > Quotes and quasiquotes stop the `array' macro's recursion into rows, > so quotes always mean "this is an element". For example, this is a > zero-dimensional array that contains a vector: > >(array '#(0 1 2 3)) Ah. Sneaky. Especially since (IIUC) in `#(... ,(blah) ...) the blah part isn't done either. More concretely, the 2 in #[1 `,2 3], which might be a result of some macro. -- ((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
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
I've pretty much made up my mind on this, so please don't feel like you have to take time to respond point-by-point. Unless you've seen a gaping hole in my reasoning, anyway, then by all means, have at it. On 11/26/2012 05:41 PM, Eli Barzilay wrote: Two hours ago, Neil Toronto wrote: For example, it's common to have arrays of Indexes, or (Vectorof Index), which would have to print like this with implicit quoting: (array `#[,'#(0 0) ,'#(0 1)]) Just working out the algorithm to print such a thing made me want to curl up and whimper. Three sidenotes: 1. You probably mean (array `#[,`#(0 0) ,`#(0 1)]), right? The inner quasiquotes can be quotes because #(0 0) and #(0 1) are vectors, not array rows. If they were array rows, they still shouldn't need to be quasiquoted. Well, depending on design... Array rows don't exist as separate objects (an array is just a function), so I have a hard time intuiting what it means to quote the inner ones. But here are some (just some) design options: 1. Allow a quote just on the outer "#[...]" and have it apply to all nested "#[...]". 2. Allow a quote on the outer "#[...]" and have it apply to all nested "#[...]", but allow them to override with their own quotes. 3. Allow quotes at any level, unpropagated. 4. Avoid difficulty altogether by having array syntax not quote its elements. #1 might be easy. #2 might be cool, but complicated. #3 is kind of weird, and I think it means the only quotes that matter are the innermost. For all of these, there are additional design options. For example, for #3, should quasiquoting outer rows be necessary if you want to quasiquote inner ones? For #2, how would one spell "override" in a way that distinguishes it from "element"? #4 avoids all these choices, and that's what is currently implemented. 3. And besides, doing such algorithms is usually easier than it sounds. (And IME, they're a perfect example where developement with test cases makes things way easier...) I'm okay with inventing apparently complicated recursive algorithms that eventually come down to a few well-chosen rules. (That's language semantics in a nutshell.) My problem has been *coming up with the test cases* for the various options I listed above. Now, I know where your brain just went, so let me head it off. You were about to reply with a bunch of starter test cases or a load of helpful hints. (Because that's who you are... and I appreciate it!) Let me make a case for not developing another set of array parsing/printing algorithms first, starting with your example: For example, I'll need to write something like (define (±1 i) (array `#(,(sub1 i) ,i ,(add1 i make it return a 3x3 array, and you get some less convenient thing like (define 1- sub1) (define 1+ add1) (define (±1 i j) (array `#(#(,(list (1- i) (1- j)) ,(list i (1- j)) ,(list (1+ i) (1- j))) #(,(list (1- i) j ) ,(list i j ) ,(list (1+ i) j )) #(,(list (1- i) (1+ j)) ,(list i (1+ j)) ,(list (1+ i) (1+ j)) I wouldn't want to write that, either. Right now, you'd write (array #[#[(list (1- i) (1- j)) (list i (1- j)) (list (1+ i) (1- j))] #[(list (1- i) j ) (list i j ) (list (1+ i) j )] #[(list (1- i) (1+ j)) (list i (1+ j)) (list (1+ i) (1+ j))]]) The vector syntax just delimits rows; it never quotes. Square parens aren't required, but make rows easier to distinguish. Arrays' custom printers print square parens, which gives feedback when a user is confused about whether #(...) means a row or a vector-valued element. Quotes and quasiquotes stop the `array' macro's recursion into rows, so quotes always mean "this is an element". For example, this is a zero-dimensional array that contains a vector: (array '#(0 1 2 3)) Here are my reasons for leaving it as it is: * Most array elements will be self-quoting anyway (numbers, strings, other primitive types). * It's easy enough to remember the exception "quote literal vectors". Also, Racket's printer writes an explicit quote before literal vectors, so arrays of array indexes parse and print the same. * I'm having a hard time with test cases for implicitly quoted array rows, which means math/array users would probably have a hard time reasoning about it as well. * There are enough possible design choices that give rise to similar- but-subtly different behavior that it would be easy for users to get confused about the actual rules. At any rate, I'm all for simple. Thanks for hashing this out with me. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Two hours ago, Neil Toronto wrote:
> On 11/24/2012 05:36 PM, Eli Barzilay wrote:
> > I'm probably missing the problem, which wouldn't be surprising
> > since I didn't even tried to look up the `array' documentation...
>
> Well, it didn't exist until I pushed it on Saturday night, so
> looking it up wouldn't have done you any good. :D
(ThereYouGo™.)
> > 2. Alternatively, the last paragraph that you wrote above can also be
> >easily translated by just replacing "[" with "#(", so the array
> >[...]
> >
> > Am I missing something?
>
> Nope. This works really well, so thanks for the fantastical idea.
> I'm keeping it.
(OK, I'll assume that I'm on track then...)
> I considered having array data implicitly quoted, like in vector
> syntax. With nested data, though, the number of design options
> grows quickly, the rules get complicated, and printing becomes a
> nightmare.
>
> For example, it's common to have arrays of Indexes, or (Vectorof
> Index), which would have to print like this with implicit quoting:
>
>(array `#[,'#(0 0) ,'#(0 1)])
>
> Just working out the algorithm to print such a thing made me want to
> curl up and whimper.
Three sidenotes:
1. You probably mean (array `#[,`#(0 0) ,`#(0 1)]), right?
2. There's no real need for producing that yourself -- the racket
printer will do the necessary work, and in this case since
it's all just self-quoting values, then it will show it in a simple
way: (array '#[#(0 0) #(0 1)]). To see what I mean by "do the
necessary work for you", just add
(struct foo () #:transparent)
and then use a few (foo)s in the vector syntax to see what I mean.
3. And besides, doing such algorithms is usually easier than it
sounds. (And IME, they're a perfect example where developement
with test cases makes things way easier...)
So it sounds like there are two related issues: the syntax for code
that produces these things, and the printed syntax -- and they're
related because you want them to be the same. If you choose to go
with the idiomatic thing where vectors (not your arrays) are
implicitly quoted, then things are relatively simple for you, but they
can be hard for users who want to write lots of expressions in them.
For example, I'll need to write something like
(define (±1 i)
(array `#(,(sub1 i) ,i ,(add1 i
make it return a 3x3 array, and you get some less convenient thing
like
(define 1- sub1)
(define 1+ add1)
(define (±1 i j)
(array `#(#(,(list (1- i) (1- j)) ,(list i (1- j)) ,(list (1+ i) (1- j)))
#(,(list (1- i) j ) ,(list i j ) ,(list (1+ i) j ))
#(,(list (1- i) (1+ j)) ,(list i (1+ j)) ,(list (1+ i) (1+ j))
Your other choice is to make `array' a macro that implicitly
quasi-quotes all #(...) expressions and unquotes all other expressions
so you never need to unquote things but you do need to quote lists.
Maybe you can keep the simple thing simple, and for such cases where
there are lots of expressions that you need, have another variant as
this kind of macro? Something like this:
(define-syntax implicitly-unquoted
(syntax-rules ()
[(_ #(x ...)) `#(,(implicitly-unquoted x) ...)]
[(_ x)x]))
(define-syntax-rule (array* xs) (array (implicitly-unquoted xs)))
(define (±1 i j)
(array* #(#((list (1- i) (1- j)) (list i (1- j)) (list (1+ i) (1- j)))
#((list (1- i) j ) (list i j ) (list (1+ i) j ))
#((list (1- i) (1+ j)) (list i (1+ j)) (list (1+ i) (1+ j))
?
--
((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
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
On 11/24/2012 05:36 PM, Eli Barzilay wrote:
I'm probably missing the problem, which wouldn't be surprising since I
didn't even tried to look up the `array' documentation...
Well, it didn't exist until I pushed it on Saturday night, so looking it
up wouldn't have done you any good. :D
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.
[...]
I... did not know that. Thanks!
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?
Nope. This works really well, so thanks for the fantastical idea. I'm
keeping it.
I considered having array data implicitly quoted, like in vector syntax.
With nested data, though, the number of design options grows quickly,
the rules get complicated, and printing becomes a nightmare.
For example, it's common to have arrays of Indexes, or (Vectorof Index),
which would have to print like this with implicit quoting:
(array `#[,'#(0 0) ,'#(0 1)])
Just working out the algorithm to print such a thing made me want to
curl up and whimper.
Neil ⊥
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Just now, Robby Findler wrote:
>
> But my emacs nowadays works fine with unicode (and I long ago gave
> up on trying to maintain an .emacs file so I just get the defaults).
Heh -- yes, it handles unicode fine, but the real problem is typing
it. There are input modes that allow you to type greek or sgml or
whatever, but they're inconvenient since you need to switch the input,
type the letter you want, then switch back. (And each switch is some
obscure three-part chord, IIRC.) I started with an attempt to mimic
drracket's M-\ feature, and ended up with a neat solution: I have a
key that switches to my input mode which works "temporarily" only for
one character, and then you're back to the input you've used. So, for
example, to type a λ in drr you'd use "\LAMBDA", and the
equivalent with my thing is "LAMBDA". The nice thing about it
is that I can define multiple names for each thing, for example, in
addition to "rarr" I also have the much-easier-to-remember "->" (or a
more extreme case: "vdash" vs "|-"). It's easy enough that I just
have "\" produce a lambda so I don't even need a specific shortcut key
for that ("\" is almost as quick).
I'd love to see something like that in drr, but I think that it might
be too confusing since it already uses "\". Besides, in drr it makes
sense to just have something less sophisticated and rely on the OS/GUI
to make such things easier system-wide, whereas in Emacs the result of
all of this is that I can use my thing even in places like file names,
or isearch.
(Now all that's missing is a drracket-jr resurrection...)
--
((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
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
On Sat, Nov 24, 2012 at 6:41 PM, Eli Barzilay wrote: > Yesterday, Neil Toronto wrote: >> Rho! Cute! > > (As much as I like using non-ascii in code now, having a useful Emacs > hack to do that (ρ ρ ρ your ⊥), I think that there are a significant > number of people who would just avoid using a library that requires > them...) Yeah, it would have to be an alternate notation. But my emacs nowadays works fine with unicode (and I long ago gave up on trying to maintain an .emacs file so I just get the defaults). Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Yesterday, Neil Toronto wrote: > Rho! Cute! (As much as I like using non-ascii in code now, having a useful Emacs hack to do that (ρ ρ ρ your ⊥), I think that there are a significant number of people who would just avoid using a library that requires them...) -- ((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
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
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
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Rho! Cute!
I just realized that implicit quasiquoting won't work, for exactly the
same reason not quasiquoting doesn't work: (array ((1 2))) is still
ambiguous. If "(" always meant "row" then "," could be an escape, but
(array (,'(1 2))) is also hideous, and so is (array ,'(1 2)).
I'm starting to think #() for rows with expressions allowed inside is my
least bad option. An array of literal vectors can be constructed by
quoting its elements. I'm'a go check it out.
Neil ⊥
On 11/23/2012 03:55 PM, Robby Findler wrote:
Oh, I see. I guess the best thing is to use the vector notation, but
insist that things are not quoted and the #() notation is used only to
say where the rows are (with expressions inside). You could also use a
one-letter identifier at the start of each parenthesized row:
(array [ρ [ρ [ρ "00" "01" "02"]]
[ρ [ρ "10" "11" "12"]]
[ρ [ρ "20" "21" "22"]]
[ρ [ρ "30" "31" "32"]]])
Robby
On Fri, Nov 23, 2012 at 4:46 PM, 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.
Neil ⊥
On 11/23/2012 03:35 PM, Robby Findler wrote:
Okay, I can't resist: why not use parens?
On Fri, Nov 23, 2012 at 4:31 PM, Neil Toronto
wrote:
On 11/23/2012 03:03 PM, Robby Findler wrote:
That [implicitly quasiquoting array data] sounds crazy, man. How about
#:keywords instead?
Like this?
(array #:keywords (list) ((list 1 2)))
Deciding how to print elements would be a problem.
If not, then I
think you're better off just going with identifiers.
I'm trying to avoid them because I find this hard to read:
(array (array-row
(array-row (array-row "00" "01" "02"))
(array-row (array-row "10" "11" "12"))
(array-row (array-row "20" "21" "22"))
(array-row (array-row "30" "31" "32"
The keywords get in the way. This isn't an issue with any constructor of
flat data like `list', `vector' and #hash(). With those, your brain can
forget about the names that delimit the data because they're at the
beginning, but `array-row' is interspersed. (It's worse when the data are
different sizes.) Compare with this:
(array [[["00" "01" "02"]]
[["10" "11" "12"]]
[["20" "21" "22"]]
[["30" "31" "32"]]])
I read "this is an array," then a bunch of structured data.
(Alternatively, think of how annoying #hash() would be if you had to type
and read (cons x y) instead of (x . y).)
I didn't mind #() because "#" isn't too intrusive. I don't mind implicit
quasiquoting because most array data are going to be constants, so the
ugliness happens infrequently.
I don't want to be stodgy about this, but I also don't want people
thinking,
"Oh, that's hideous" the first time they see an array printed. I'm also
aware that this is dangerously close to bikeshedding... :/
Neil ⊥
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Oh, I see. I guess the best thing is to use the vector notation, but insist that things are not quoted and the #() notation is used only to say where the rows are (with expressions inside). You could also use a one-letter identifier at the start of each parenthesized row: (array [ρ [ρ [ρ "00" "01" "02"]] [ρ [ρ "10" "11" "12"]] [ρ [ρ "20" "21" "22"]] [ρ [ρ "30" "31" "32"]]]) Robby On Fri, Nov 23, 2012 at 4:46 PM, 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. > > Neil ⊥ > > > On 11/23/2012 03:35 PM, Robby Findler wrote: >> >> Okay, I can't resist: why not use parens? >> >> On Fri, Nov 23, 2012 at 4:31 PM, Neil Toronto >> wrote: >>> >>> On 11/23/2012 03:03 PM, Robby Findler wrote: That [implicitly quasiquoting array data] sounds crazy, man. How about #:keywords instead? >>> >>> >>> >>> Like this? >>> >>>(array #:keywords (list) ((list 1 2))) >>> >>> Deciding how to print elements would be a problem. >>> >>> If not, then I think you're better off just going with identifiers. >>> >>> >>> >>> I'm trying to avoid them because I find this hard to read: >>> >>>(array (array-row >>>(array-row (array-row "00" "01" "02")) >>>(array-row (array-row "10" "11" "12")) >>>(array-row (array-row "20" "21" "22")) >>>(array-row (array-row "30" "31" "32" >>> >>> The keywords get in the way. This isn't an issue with any constructor of >>> flat data like `list', `vector' and #hash(). With those, your brain can >>> forget about the names that delimit the data because they're at the >>> beginning, but `array-row' is interspersed. (It's worse when the data are >>> different sizes.) Compare with this: >>> >>>(array [[["00" "01" "02"]] >>>[["10" "11" "12"]] >>>[["20" "21" "22"]] >>>[["30" "31" "32"]]]) >>> >>> I read "this is an array," then a bunch of structured data. >>> >>> (Alternatively, think of how annoying #hash() would be if you had to type >>> and read (cons x y) instead of (x . y).) >>> >>> I didn't mind #() because "#" isn't too intrusive. I don't mind implicit >>> quasiquoting because most array data are going to be constants, so the >>> ugliness happens infrequently. >>> >>> I don't want to be stodgy about this, but I also don't want people >>> thinking, >>> "Oh, that's hideous" the first time they see an array printed. I'm also >>> aware that this is dangerously close to bikeshedding... :/ >>> >>> Neil ⊥ >>> > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
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. Neil ⊥ On 11/23/2012 03:35 PM, Robby Findler wrote: Okay, I can't resist: why not use parens? On Fri, Nov 23, 2012 at 4:31 PM, Neil Toronto wrote: On 11/23/2012 03:03 PM, Robby Findler wrote: That [implicitly quasiquoting array data] sounds crazy, man. How about #:keywords instead? Like this? (array #:keywords (list) ((list 1 2))) Deciding how to print elements would be a problem. If not, then I think you're better off just going with identifiers. I'm trying to avoid them because I find this hard to read: (array (array-row (array-row (array-row "00" "01" "02")) (array-row (array-row "10" "11" "12")) (array-row (array-row "20" "21" "22")) (array-row (array-row "30" "31" "32" The keywords get in the way. This isn't an issue with any constructor of flat data like `list', `vector' and #hash(). With those, your brain can forget about the names that delimit the data because they're at the beginning, but `array-row' is interspersed. (It's worse when the data are different sizes.) Compare with this: (array [[["00" "01" "02"]] [["10" "11" "12"]] [["20" "21" "22"]] [["30" "31" "32"]]]) I read "this is an array," then a bunch of structured data. (Alternatively, think of how annoying #hash() would be if you had to type and read (cons x y) instead of (x . y).) I didn't mind #() because "#" isn't too intrusive. I don't mind implicit quasiquoting because most array data are going to be constants, so the ugliness happens infrequently. I don't want to be stodgy about this, but I also don't want people thinking, "Oh, that's hideous" the first time they see an array printed. I'm also aware that this is dangerously close to bikeshedding... :/ Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Okay, I can't resist: why not use parens? On Fri, Nov 23, 2012 at 4:31 PM, Neil Toronto wrote: > On 11/23/2012 03:03 PM, Robby Findler wrote: >> >> That [implicitly quasiquoting array data] sounds crazy, man. How about >> #:keywords instead? > > > Like this? > > (array #:keywords (list) ((list 1 2))) > > Deciding how to print elements would be a problem. > > >> If not, then I >> think you're better off just going with identifiers. > > > I'm trying to avoid them because I find this hard to read: > > (array (array-row > (array-row (array-row "00" "01" "02")) > (array-row (array-row "10" "11" "12")) > (array-row (array-row "20" "21" "22")) > (array-row (array-row "30" "31" "32" > > The keywords get in the way. This isn't an issue with any constructor of > flat data like `list', `vector' and #hash(). With those, your brain can > forget about the names that delimit the data because they're at the > beginning, but `array-row' is interspersed. (It's worse when the data are > different sizes.) Compare with this: > > (array [[["00" "01" "02"]] > [["10" "11" "12"]] > [["20" "21" "22"]] > [["30" "31" "32"]]]) > > I read "this is an array," then a bunch of structured data. > > (Alternatively, think of how annoying #hash() would be if you had to type > and read (cons x y) instead of (x . y).) > > I didn't mind #() because "#" isn't too intrusive. I don't mind implicit > quasiquoting because most array data are going to be constants, so the > ugliness happens infrequently. > > I don't want to be stodgy about this, but I also don't want people thinking, > "Oh, that's hideous" the first time they see an array printed. I'm also > aware that this is dangerously close to bikeshedding... :/ > > Neil ⊥ > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
On 11/23/2012 03:03 PM, Robby Findler wrote: That [implicitly quasiquoting array data] sounds crazy, man. How about #:keywords instead? Like this? (array #:keywords (list) ((list 1 2))) Deciding how to print elements would be a problem. If not, then I think you're better off just going with identifiers. I'm trying to avoid them because I find this hard to read: (array (array-row (array-row (array-row "00" "01" "02")) (array-row (array-row "10" "11" "12")) (array-row (array-row "20" "21" "22")) (array-row (array-row "30" "31" "32" The keywords get in the way. This isn't an issue with any constructor of flat data like `list', `vector' and #hash(). With those, your brain can forget about the names that delimit the data because they're at the beginning, but `array-row' is interspersed. (It's worse when the data are different sizes.) Compare with this: (array [[["00" "01" "02"]] [["10" "11" "12"]] [["20" "21" "22"]] [["30" "31" "32"]]]) I read "this is an array," then a bunch of structured data. (Alternatively, think of how annoying #hash() would be if you had to type and read (cons x y) instead of (x . y).) I didn't mind #() because "#" isn't too intrusive. I don't mind implicit quasiquoting because most array data are going to be constants, so the ugliness happens infrequently. I don't want to be stodgy about this, but I also don't want people thinking, "Oh, that's hideous" the first time they see an array printed. I'm also aware that this is dangerously close to bikeshedding... :/ Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
That sounds crazy, man. How about #:keywords instead? If not, then I think you're better off just going with identifiers. Robby On Fri, Nov 23, 2012 at 3:39 PM, Neil Toronto wrote: > On 11/23/2012 01:47 PM, Neil Toronto wrote: >> >> On 11/22/2012 11:33 AM, Eli Barzilay wrote: >>> >>> Two days ago, Neil Toronto wrote: Anyway, it occurred to me that I need to provide a more robust way to generate code for literal arrays anyway. Keywords are more easily preserved by macros than syntax properties: >>> >>> >>> Why not use vector syntax #(...) instead of [...]? >> >> >> That is a fantastic idea. Thanks! >> >> (The problem I was having with head identifiers like `array-row' was >> that they got in the way when I was reading the array. Vector syntax >> solves that neatly.) > > > I've thought about it more and come up with a weird case: > > (array #((list 1 2))) > > Should this array contain '(1 2) or '(list 1 2)? > > I'm not keen on the idea of the `array' macro only being useful for quoted > datums, especially since it's not a reader macro. But if the above array > contained '(1 2), that would be inconsistent with #((list 1 2)), which > contains '(list 1 2): > > > (vector-ref #((list 1 2)) 0) > '(list 1 2) > > I've considered having `array' implicitly quote its contents, so > > (array ((list 1 2))) > > contains '(list 1 2), but > > (array (,(list 1 2))) > > contains '(1 2). > > That might actually work the way I want it to. Do you see any problems with > it? > > > Neil ⊥ > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
On 11/23/2012 01:47 PM, Neil Toronto wrote: On 11/22/2012 11:33 AM, Eli Barzilay wrote: Two days ago, Neil Toronto wrote: Anyway, it occurred to me that I need to provide a more robust way to generate code for literal arrays anyway. Keywords are more easily preserved by macros than syntax properties: Why not use vector syntax #(...) instead of [...]? That is a fantastic idea. Thanks! (The problem I was having with head identifiers like `array-row' was that they got in the way when I was reading the array. Vector syntax solves that neatly.) I've thought about it more and come up with a weird case: (array #((list 1 2))) Should this array contain '(1 2) or '(list 1 2)? I'm not keen on the idea of the `array' macro only being useful for quoted datums, especially since it's not a reader macro. But if the above array contained '(1 2), that would be inconsistent with #((list 1 2)), which contains '(list 1 2): > (vector-ref #((list 1 2)) 0) '(list 1 2) I've considered having `array' implicitly quote its contents, so (array ((list 1 2))) contains '(list 1 2), but (array (,(list 1 2))) contains '(1 2). That might actually work the way I want it to. Do you see any problems with it? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
On 11/22/2012 11:33 AM, Eli Barzilay wrote: Two days ago, Neil Toronto wrote: Anyway, it occurred to me that I need to provide a more robust way to generate code for literal arrays anyway. Keywords are more easily preserved by macros than syntax properties: Why not use vector syntax #(...) instead of [...]? That is a fantastic idea. Thanks! (The problem I was having with head identifiers like `array-row' was that they got in the way when I was reading the array. Vector syntax solves that neatly.) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Two days ago, Neil Toronto wrote: > (Probably. Why are we whispering?) +1 to not using a macro that depends on paren shapes. I'm not saying that the brokenness is fine -- just that on one hand you're likely to run into a bunch of problems with code that doesn't propagate the shapes, and on the other hand there is so far no part of the core language that depends on the paren shapes. (The first is an inherent problem since you need other people's code to deal correctly with a feature that you're using, and I think that honu (especially the way it shapes up) is a much better solution here.) > Anyway, it occurred to me that I need to provide a more robust way > to generate code for literal arrays anyway. Keywords are more easily > preserved by macros than syntax properties: Why not use vector syntax #(...) instead of [...]? > I think that'll let me use Eli's sneaky eval:alts to display (array > [0 1 2 3]) but evaluate (array (array-row 0 1 2 3)). (That's not mine...) -- ((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
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
The day after I wrote this message I wrote such a macro myself -- because it was natural to dispatch on the shape of parentheses. But I will never have to scribble about this one; it just generates HTML for my course. But I agree that keywords are much better for this purpose. They wouldn't have worked in my case. My syntax comes from a string and I use it both ways. -- Matthias On Nov 20, 2012, at 9:05 PM, Neil Toronto wrote: > (Probably. Why are we whispering?) > > Anyway, it occurred to me that I need to provide a more robust way to > generate code for literal arrays anyway. Keywords are more easily preserved > by macros than syntax properties: > > (array (array-row 0 1 2 3)) > > I think that'll let me use Eli's sneaky eval:alts to display (array [0 1 2 > 3]) but evaluate (array (array-row 0 1 2 3)). > > Neil ⊥ > > On 11/18/2012 08:12 PM, Matthias Felleisen wrote: >> >> (Perhaps this suggests a problem with making a macro depend on the shape of >> parens around a sub-expression.) >> >> >> >> >> On Nov 18, 2012, at 10:01 PM, Neil Toronto wrote: >> >>> I'm writing the documentation for math/array, and the examples all fail. >>> Here's a simple one: >>> >>> @examples[#:eval untyped-eval >>> (array [0 1 2 3])] >>> >>> The evaluator raises this error: >>> >>> application: not a procedure; >>> expected a procedure that can be applied to arguments >>>given: 0 >>>arguments...: >>> 1 >>> 2 >>> 3 >>> >>> The problem here is that the `array' macro is sensitive to square brackets, >>> but Scribble doesn't preserve the 'paren-shape syntax property. (Either >>> that, or `examples' only sends lists to the evaluator, not syntax.) So >>> (array [0 1 2 3]) gets evaluated as (array (0 1 2 3)), which looks like a >>> zero-dimensional array containing (0 1 2 3), which is an application of the >>> value `0'. Bad. >>> >>> I know this can work just fine; for example, this does the expected thing >>> in the REPL: >>> >>> > (eval #'(require math)) >>> > (eval #'(array [0 1 2 3])) >>> (array [0 1 2 3]) >>> >>> Is there a way to get Scribble to behave like I expect? >>> >>> Neil ⊥ >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >> > smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
(Probably. Why are we whispering?) Anyway, it occurred to me that I need to provide a more robust way to generate code for literal arrays anyway. Keywords are more easily preserved by macros than syntax properties: (array (array-row 0 1 2 3)) I think that'll let me use Eli's sneaky eval:alts to display (array [0 1 2 3]) but evaluate (array (array-row 0 1 2 3)). Neil ⊥ On 11/18/2012 08:12 PM, Matthias Felleisen wrote: (Perhaps this suggests a problem with making a macro depend on the shape of parens around a sub-expression.) On Nov 18, 2012, at 10:01 PM, Neil Toronto wrote: I'm writing the documentation for math/array, and the examples all fail. Here's a simple one: @examples[#:eval untyped-eval (array [0 1 2 3])] The evaluator raises this error: application: not a procedure; expected a procedure that can be applied to arguments given: 0 arguments...: 1 2 3 The problem here is that the `array' macro is sensitive to square brackets, but Scribble doesn't preserve the 'paren-shape syntax property. (Either that, or `examples' only sends lists to the evaluator, not syntax.) So (array [0 1 2 3]) gets evaluated as (array (0 1 2 3)), which looks like a zero-dimensional array containing (0 1 2 3), which is an application of the value `0'. Bad. I know this can work just fine; for example, this does the expected thing in the REPL: > (eval #'(require math)) > (eval #'(array [0 1 2 3])) (array [0 1 2 3]) Is there a way to get Scribble to behave like I expect? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
(Perhaps this suggests a problem with making a macro depend on the shape of parens around a sub-expression.) On Nov 18, 2012, at 10:01 PM, Neil Toronto wrote: > I'm writing the documentation for math/array, and the examples all fail. > Here's a simple one: > > @examples[#:eval untyped-eval > (array [0 1 2 3])] > > The evaluator raises this error: > > application: not a procedure; > expected a procedure that can be applied to arguments >given: 0 >arguments...: > 1 > 2 > 3 > > The problem here is that the `array' macro is sensitive to square brackets, > but Scribble doesn't preserve the 'paren-shape syntax property. (Either that, > or `examples' only sends lists to the evaluator, not syntax.) So (array [0 1 > 2 3]) gets evaluated as (array (0 1 2 3)), which looks like a > zero-dimensional array containing (0 1 2 3), which is an application of the > value `0'. Bad. > > I know this can work just fine; for example, this does the expected thing in > the REPL: > > > (eval #'(require math)) > > (eval #'(array [0 1 2 3])) > (array [0 1 2 3]) > > Is there a way to get Scribble to behave like I expect? > > Neil ⊥ > _ > Racket Developers list: > http://lists.racket-lang.org/dev smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
I'm writing the documentation for math/array, and the examples all fail. Here's a simple one: @examples[#:eval untyped-eval (array [0 1 2 3])] The evaluator raises this error: application: not a procedure; expected a procedure that can be applied to arguments given: 0 arguments...: 1 2 3 The problem here is that the `array' macro is sensitive to square brackets, but Scribble doesn't preserve the 'paren-shape syntax property. (Either that, or `examples' only sends lists to the evaluator, not syntax.) So (array [0 1 2 3]) gets evaluated as (array (0 1 2 3)), which looks like a zero-dimensional array containing (0 1 2 3), which is an application of the value `0'. Bad. I know this can work just fine; for example, this does the expected thing in the REPL: > (eval #'(require math)) > (eval #'(array [0 1 2 3])) (array [0 1 2 3]) Is there a way to get Scribble to behave like I expect? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
