Thanks, Matthew! I really like this. (And I know it was a lot of work
to wrangle the HTML and CSS in this case.)
It looks good to me as it is, although Robby's suggestion of lowercase
sounds good too.
Neil V.
_
Racket Developers list:
http://lists.racket-lang.org/
It looks to me like the "free-var-list" is optional in uses of with-contract
and define/contract. The documentation, though, suggests that this is not the
case. Specifically, free-var-list is defined as:
free-var-list = #:freevars ([id co
You're correct about it being optional, so go ahead and add it.
Thanks,
Stevie
On Jun 19, 2012, at 2:48 PM, John Clements wrote:
> It looks to me like the "free-var-list" is optional in uses of with-contract
> and define/contract. The documentation, though, suggests that this is not the
> case
About a month ago, Matthew Flatt wrote:
> I've pushed a first cut at overhauling error messages from
> `racket/base'.
Two very independent things really bug me, so I'll make two posts.
The new messages look more organized but there was something that
bugged me which took a while to realize. I kn
On 06/19/2012 01:52 PM, Eli Barzilay wrote:
About a month ago, Matthew Flatt wrote:
I've pushed a first cut at overhauling error messages from
`racket/base'.
Two very independent things really bug me, so I'll make two posts.
The new messages look more organized but there was something that
bu
1. Because of the length of the bitwise operators:
bitwise-and
bitwise-ior
bitwise-xor
bitwise-not
it might be useful for readability in even slightly complicated bit
manipulations to have something like the usual mathematical symbols
as aliases for these operations.
2. Why the names arithmetic-s
I tend to put a lot of comments not just at the beginning of
procedures but also in the body of the procedures, usually above lines
of code instead of to the right because the comments can be fairly
long and multi-line. This makes it easier to understand the procedure
on the one hand but because i
Machine semantics for real machines (like the JVM or Racket's VM) or
non-standard semantics for an abstract interpretation (like what I end up
getting into) can get up to monstrous numbers of components for each state that
usually don't matter. I and I'm sure many others would appreciate a reduc
Two hours ago, Ryan Culpepper wrote:
>
> I interpret ": " as meaning " complains that ",
> whereas IIUC you want it to mean "there is a such that "
> or "look at ; " or something like that.
>
> For procedures, it make sense whether the was "application" or the
> procedure's name, but I underst
The second problem I have with the error texts is their lack of
structure. Since the error messages are much more verbose, there is
now a need to have some short form that follows conventions for
various tools. For example:
* There's a whole range of tools that work with the usual
"file:li
On 06/19/2012 06:11 PM, Eli Barzilay wrote:
* There are two contexts where error messages are unwieldy: TR and
contract errors. In both of these the error text is huge to the
point of making a useless text that you need to manually grep
through. In TR it got bad enough that Vi
I don't know if it is intended, but these messages come across as just
disliking the idea of putting more (and structured) information into
the error messages. I'm guessing Eli does not intend that, but since I
got that feeling, I wanted to say that I strongly support the current
trend towards more
I have thought about adding something that would solve this problem to
Redex off and on for a few years and am circling something I think is
reasonable. (The main thing I think you've not considered below is how
to typeset things, but that said I have in mind something similar in
spirit to what you
The documentation for impersonate-struct and chaperone-struct differ
in the fact that chaperone-struct explicitly says that only
impersonator properties are not allowed. But the implementation
doesn't allow it for either of them. Either the documentation or the
implementation is wrong.
What is the
14 matches
Mail list logo
