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
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,
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
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))
On Sat, Nov 24, 2012 at 6:41 PM, Eli Barzilay e...@barzilay.org 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
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
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 #(...)
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
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 neil.toro...@gmail.com wrote:
On 11/23/2012 01:47 PM, Neil Toronto wrote:
On 11/22/2012 11:33 AM, Eli Barzilay 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
Okay, I can't resist: why not use parens?
On Fri, Nov 23, 2012 at 4:31 PM, Neil Toronto neil.toro...@gmail.com 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
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
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
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
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
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
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
(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
18 matches
Mail list logo
