On Friday, Matthew Flatt wrote:
At Fri, 24 May 2013 12:44:35 -0400, Eli Barzilay wrote:
* The script should also take care to deal with files that got
removed in the past.
Ditto.
I don't believe that it's *not* doing this, so I did the
double-check in the form of a test.
I'm not sure if this should be considered a bug or a feature request (or
something else, but hopefully one of those two!) so I thought I'd ask here
before sending in a PR. This program:
#lang typed/racket
(require typed/rackunit)
(struct: s ([a : Integer]))
(check-equal? (s 1) (s 2))
That is indeed the correct fix. I'm not entirely sure how to improve
the error message, since the problem in your original code is real.
There's no way the generated contract can tell at runtime that the
values passed to `check-equal?` aren't higher-order, so it has to
conservatively reject the
Now for the problems that are likely worth paying attention to, and
suggestions for improving things...
The quick summary of what I'm going to say is that I think that
there's a significant improvement that can be done with some more
work, one that requires some minimal manual intervention.
Well, given that replacing check-equal? with equal? (on the typed side)
works, then it seems to me that one solution would be to move more of
rackunit into TR, or to refactor rackunit to be more friendly to TR. (And
if someone is going to work on this, then it would also be great if the
error
Hi, all!
Using `for/fold' with more than one accumulator is inconvenient, when
there is a need for auxiliary operations with accumulators before return.
For example:
(define (partition pred lst)
(define-values (a1 a2)
(for/fold ([acc1 null]
[acc2 null])
([v (in-list
The for[/*] macros are fairly low in the language tower for Racket, so making
these kinds of changes robust in the original implementation is cumbersome and
error-prone. I've written a shim to use on top of for/fold and for*/fold to
alleviate some pain in multiple value accumulation,
If TR lived up exactly to the R level of semantics, to wit:
Welcome to DrRacket, version 5.3.4.10--2013-05-29(05524114/d) [3m].
Language: racket.
(struct s ())
(require rackunit)
(check-equal? (s) (s))
FAILURE
actual: #s
expected: #s
name:
Yes: my message is about strange error messages that cause newbies to just
conclude that testing TR programs doesn't work. While I can certainly fault
someone for coming to this conclusion (and I did) I think only half of the
problem is on their side.
If they had gotten this message, they might
I use this workaround in the math library, whose arrays are higher-order
values that *can* be checked for equality:
(require (except-in typed/rackunit check-equal?))
;; This gets around the fact that typed/rackunit can no longer test
;; higher-order values for equality, since TR has firmed up
On 05/28/2013 03:44 PM, Sam Tobin-Hochstadt wrote:
On Tue, May 28, 2013 at 5:14 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I don't know whether the -lib/-docs split is worthwhile, but it's
part of erring on the side of breaking things apart. Maybe it makes
more sense to keep things together
Yesterday, Matthew Flatt wrote:
Here's a first experiment at moving collections around into packages:
https://github.com/mflatt/racket/tree/pkg
[...]
Comments in no particular order, mostly about the actual file
selections. Many are kind of small todo-style laundry items, some are
At Wed, 29 May 2013 11:11:18 -0600, Neil Toronto wrote:
On 05/28/2013 03:44 PM, Sam Tobin-Hochstadt wrote:
On Tue, May 28, 2013 at 5:14 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I don't know whether the -lib/-docs split is worthwhile, but it's
part of erring on the side of breaking
Yesterday, Sam Tobin-Hochstadt wrote:
One question -- a bunch of unstable seems to be in the
typed-racket-lib package. Why is that?
Since these things are used in TR only, I think that they should move
back. Ie, you get a trimmed TR repo with unstable/stuff which you
move to a better place
Yesterday, Robby Findler wrote:
This looks great to me!
I don't have a good sense of what level of granularity is the right
one, but I naturally would have gone even finer grained with
drracket: the macro-debugger, pkg/gui, and maybe even the
gui-debugger I would have separated out.
An hour ago, Neil Toronto wrote:
I expect `plot' to depend on `math' in the near-ish future. Right
now, `math' already depends on `plot' to build its docs. IOW, I
expect the sources to be interdependent, but as binaries, `plot'
will depend on `math' but `math' won't depend on `plot'. Can the
20 minutes ago, Matthew Flatt wrote:
Yes. Package dependencies can be cyclic (unlike module
dependencies), and packages can have cyclic build dependencies
without cyclic run dependencies.
(*sigh*) So the idea of acyclic package graph as module containers is
dead?
But to explain my sigh --
At Wed, 29 May 2013 14:14:11 -0400, Eli Barzilay wrote:
* Does this split actually work wrt having no circular dependencies?
It's mostly non-circular, but there are some exceptions.
I think there are no circularities among the -lib packages, but I'm
not 100% certain.
The existing -docs
Just to be clear, I agree that we want to minimize cycles.
I don't think that actually prohibiting cycles is going to be workable,
though, especially at the level of documentation.
Cycles at the level of -lib suggest to me that the organization
should be improved.
Cycles at the level of -doc
[shuffled]
20 minutes ago, Matthew Flatt wrote:
Just to be clear, I agree that we want to minimize cycles.
I don't think that actually prohibiting cycles is going to be workable,
though, especially at the level of documentation.
Cycles at the level of -lib suggest to me that the
20 matches
Mail list logo
