A few minutes ago, Carl Eastlund wrote:
> On Fri, May 4, 2012 at 4:37 PM, Eli Barzilay wrote:
>
> In case it wasn't clear enough, I said that I don't mind having
> it (and I'm willing to add it) -- I only added that I don't see
> any *practical* case where you'd use it.
>
> Okay, the
On Fri, May 4, 2012 at 4:37 PM, Eli Barzilay wrote:
> 20 minutes ago, Carl Eastlund wrote:
> >
> In case it wasn't clear enough, I said that I don't mind having it
> (and I'm willing to add it) -- I only added that I don't see any
> *practical* case where you'd use it.
>
Okay, then I think we're
20 minutes ago, Danny Yoo wrote:
> ... for example, why not set up files that set some parameter and then
> run the program. You said that you want a `++load my-module.rkt' --
> why not change "my-module.rkt" -> "my-module.scrbl", and just render
> it?
>
> I like this. But I don'
... for example, why not set up files that set some parameter and then
> run the program. You said that you want a `++load my-module.rkt' --
> why not change "my-module.rkt" -> "my-module.scrbl", and just render
> it?
>
I like this. But I don't want the "configuration" scribble file to itself
ge
[Shuffled]
Yesterday, Matthias Felleisen wrote:
>
> I don't think Eli is proposing an elimination of the old names but
> supplementing the code base with new ones.
Yes, I'm suggesting something along the lines of a simple addition to
`racket/base':
(provide (rename-out [current-output-port st
20 minutes ago, Carl Eastlund wrote:
>
> Currently, there *are* already two problems: (1) people who want to
> define an identifier matcher but can't;
>
> That's a missing feature, and one in high demand, but personally I'd
> rather go without a feature than break an often-relied-upon fea
The docs for make-argb read:
Constructs a new argb value. The vector has four entries for each pixel, an
alpha, red, green, and blue value. The int specifies the width of the image;
the height is the size of the vector, divided by 4, divided by the width.
This documentation doesn't specify whet
On Fri, May 4, 2012 at 3:11 PM, Eli Barzilay wrote:
> Just now, Carl Eastlund wrote:
> >
> > It's not a question of how many there are, or who knows about them.
> > Providing your own "if" does not prevent others from shadowing "if"
> > with let or any other binding form. In a large enough proje
I don't think that's what Marijn was suggesting.
I understood it as:
(define-syntax-rule (define-complex real-name imag-name rhs)
(define real-name (real-part rhs))
(define imag-name (imag-part rhs)))
(define-complex r i 1+2i)
=>
(begin
(define r (real-part 1+2i))
Just now, Carl Eastlund wrote:
>
> It's not a question of how many there are, or who knows about them.
> Providing your own "if" does not prevent others from shadowing "if"
> with let or any other binding form. In a large enough project, lots
> of names can get imported from lots of sources. Th
On Fri, May 4, 2012 at 2:52 PM, Eli Barzilay wrote:
> 20 minutes ago, J. Ian Johnson wrote:
> > That behavior would be really spooky to me. I would expect binding
> > positions to not depend on any environmental information.
>
> (It's still the same, only the definition of what is a binding
> pos
20 minutes ago, J. Ian Johnson wrote:
> That behavior would be really spooky to me. I would expect binding
> positions to not depend on any environmental information.
(It's still the same, only the definition of what is a binding
position is a bit different.)
> Perhaps have an (id _) form that w
If we add some kind of id expanders for match patterns, we need to add a
way for pattern variables to shadow these names if the author really wants
to. Otherwise, every id expander defined eats up more namespace that match
variables cannot bind.
We already have this issue with _ and ..., but at l
That behavior would be really spooky to me. I would expect binding positions to
not depend on any environmental information. Perhaps have an (id _) form that
would allow putting your special identifiers there.
-Ian
- Original Message -
From: "Eli Barzilay"
To: "Sam Tobin-Hochstadt" , "
This is an *ancient* patch suggestion that I dug up in my quest for
smaller inbox... (It's really old, so won't work as is.)
It makes it possible to define identifier syntaxes as match expanders,
and that would probably make it possible to also address the
relatively common complaint about not ha
Here is a quick test on the collects dir (program attached if you want to
improve it).
A number of files are not parsed because of various glitches (#reader lines
in particular).
Below is the dict of the first 500 identifiers with the number of
occurrences, sorted by this number times the string-l
I know I know. I can't script in anything but Racket.
And I have written such scripts and better still I teach such directory
traversals to freshmen :-)
On May 4, 2012, at 11:11 AM, Laurent wrote:
>
>
> On Fri, May 4, 2012 at 5:04 PM, Neil Van Dyke wrote:
> Matthias Felleisen wrote at
On Fri, May 4, 2012 at 5:04 PM, Neil Van Dyke wrote:
> Matthias Felleisen wrote at 05/04/2012 10:41 AM:
>
>> On May 4, 2012, at 10:34 AM, Laurent wrote
>>
>>> An interesting idea would be to count the number of times each
>>> identifier is used in the sources, and see how many characters would be
Matthias Felleisen wrote at 05/04/2012 10:41 AM:
On May 4, 2012, at 10:34 AM, Laurent wrote
An interesting idea would be to count the number of times each identifier is
used in the sources, and see how many characters would be saved by using
different conventions.
That sounds like a fan
On Fri, May 4, 2012 at 4:41 PM, Matthias Felleisen wrote:
>
> On May 4, 2012, at 10:34 AM, Laurent wrote:
>
> > As sad as I am to say this, "arr[x] = 3" is read quicker by the eye than
> "(vector-set! my-integer-array the-current-iterator the-number-three)"
>
> I started saying this in 1988, when
On May 4, 2012, at 10:34 AM, Laurent wrote:
> As sad as I am to say this, "arr[x] = 3" is read quicker by the eye than
> "(vector-set! my-integer-array the-current-iterator the-number-three)"
I started saying this in 1988, when I requested from a Scheme implementor that
arrays should be treat
On Fri, May 4, 2012 at 4:04 PM, Matthias Felleisen wrote:
>
> On May 3, 2012, at 11:03 PM, Neil Van Dyke wrote:
>
> > Matthias Felleisen wrote at 05/03/2012 10:57 PM:
> >> I don't think Eli is proposing an elimination of the old names but
> supplementing the code base with new ones.
> >>
> >> I am
On May 3, 2012, at 11:03 PM, Neil Van Dyke wrote:
> Matthias Felleisen wrote at 05/03/2012 10:57 PM:
>> I don't think Eli is proposing an elimination of the old names but
>> supplementing the code base with new ones.
>>
>> I am in favor -- Matthias
>
> Would be good to have a shorter naming co
23 matches
Mail list logo
