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)) (
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 exam
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 u
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, t
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
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 libra
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)) (la
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 co
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 starti
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" "0
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 "extr
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
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 w
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 ag
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 prope
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 #(...) ins
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 ot
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 ha
(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:al
(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-ev
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
give
21 matches
Mail list logo
