On Sat, Jan 5, 2013 at 9:58 AM, Matthew Flatt wrote:
>
> Maybe the default for a build `configure'd without `--prefix' (or, more
> generally, for a non-Unix-style build) should be installation-wide
> package installs, while the default for our pre-built distributions
> should be user- and version-
On Sat, Jan 5, 2013 at 6:55 PM, Neil Toronto wrote:
>
> What if RAList could be exported as a polymorphic, opaque type?
>
> It seems the contract system could then exploit the fact that an RAList is
> always well-typed. What would it take? Tagging structs? A special chaperone?
> User-definable con
Yesterday, Matthew Flatt wrote:
> I have been thinking about how developers who build their own Racket
> are more likely to want installation-wide packages instead of user-
> and version-specific packages. This is particularly true for those
> of us who work from the git respository.
(Another situ
Yesterday, Ray Racine wrote:
> On installation issues:
>
> 1) Yes on defaulting to an installation-wide install as default.
Matthew didn't suggest this as a default for all cases -- but just to
be clear: an installation-wide as default is not something that is
always better. In fact, it is in ma
I repent. While a reversible (install/uninstall) system-wide build /
install from source has some value in cases, I now doubt there is adequate
ROEMOF, return on effort and maintenance of feature.
Overall, for me, a trimmer "core" Racket installation is for more valuable.
On Sun, Jan 6, 2013 a
Is this really the best we can do for a contracted first-order procedure that
accidentally returns two values instead of one:
Language: racket.
. . procedure-result chaperone: arity mismatch;
wrapper does not accept the number of values produced by
the original procedure
wrapper: #
number
At Sun, 6 Jan 2013 11:42:52 -0500, Eli Barzilay wrote:
> Yesterday, Matthew Flatt wrote:
> > I have been thinking about how developers who build their own Racket
> > are more likely to want installation-wide packages instead of user-
> > and version-specific packages. This is particularly true for
(Sorry, I'm on my phone and can't something more precise...)
Actually, this suggests a good easy to do the guessing thing: see if the
'repo-time-stamp' exists (in the installation directory). This will play
nicely with 3rd party packagers who are not supposed to include it.
On Jan 6, 2013 1:27 PM
Does anyone have expertise or interest to help us figure out how to do a
better job with the mac os x packaging for Racket?
It sure would be great if we had an alias to /Applications and a nice "drag
this there" image on the background of the .dmg like all the other mac
installers do
The one
I think maybe you've just found a bug. Do you have a program to share?
[robby@yanpu] ~/Downloads$ racket
Welcome to Racket v5.3.1.12.
> ((contract (-> integer? integer?) (lambda (x) (values 1 2)) 'pos 'neg) 1)
stdin::2: broke its contract
expected 1 value, returned 2 values
in: the range of
What if you added an extra field to immutable values (ie all TR structs
would have this hidden field) such that, when they passed across a
boundary, the field got mutated to say what type it passed at. Then, when
the value passed back into TR, TR could check to see if has this secret
field and what
On Sun, Jan 6, 2013 at 2:55 PM, Robby Findler
wrote:
> What if you added an extra field to immutable values (ie all TR structs
> would have this hidden field) such that, when they passed across a boundary,
> the field got mutated to say what type it passed at. Then, when the value
> passed back in
I wouldn't say you'd do it for cons cells (they are special in the
runtime). This is for structs that are declared in TR. You would add the
field everywhere (or places where the programmer asks only).
The boundaries have the information; that's how the contracts got inserted
in the first place.
R
On Sun, Jan 6, 2013 at 3:13 PM, Robby Findler
wrote:
> I wouldn't say you'd do it for cons cells (they are special in the runtime).
> This is for structs that are declared in TR. You would add the field
> everywhere (or places where the programmer asks only).
Right, I know how the real Racket `co
On Sun, Jan 6, 2013 at 2:18 PM, Sam Tobin-Hochstadt wrote:
> > The boundaries have the information; that's how the contracts got
> inserted
> > in the first place.
>
> No, the contracts are parametric contracts using `parametric->/c`, and
> thus don't have any information about the types used at a
On Sun, Jan 6, 2013 at 3:23 PM, Robby Findler
wrote:
> On Sun, Jan 6, 2013 at 2:18 PM, Sam Tobin-Hochstadt
> wrote:
>>
>> > The boundaries have the information; that's how the contracts got
>> > inserted
>> > in the first place.
>>
>> No, the contracts are parametric contracts using `parametric->
Okay, I distilled it to something small and sent in a bug report.
On Jan 6, 2013, at 2:51 PM, Robby Findler wrote:
> I think maybe you've just found a bug. Do you have a program to share?
>
> [robby@yanpu] ~/Downloads$ racket
> Welcome to Racket v5.3.1.12.
> > ((contract (-> integer? integer?)
This has a non-chaperone contract being used in a struct/c, I think?
(FST (LST 1 2 3)) => struct/dc: expected chaperone contracts, but field a
has #
Robby
On Sun, Jan 6, 2013 at 2:40 PM, Sam Tobin-Hochstadt wrote:
> On Sun, Jan 6, 2013 at 3:23 PM, Robby Findler
> wrote:
> > On Sun, Jan 6, 201
I'm not sure what TR is really doing here yet, but my intention was to
suggest that the kons struct can have an extra (mutable) field. When LST/C
encounters (in a positive position) a kons, then it bangs some
representation of A into the extra field. When it sees a kons struct in a
negative positio
Sorry, that was very silly of me. That isn't what's happening at all,
because type soundness means we don't need to enforce the
parametricity at all.
The actual relevant program is:
(module m racket
(struct kons (a d))
(struct mt ())
(define MT (mt))
(define (FST v)
(when (eq? MT v)
Oh-- I think you're right that the type parameter can matter (it could go
over to R as an Integer list and come back as a Boolean list or something).
Robby
On Sun, Jan 6, 2013 at 4:08 PM, Sam Tobin-Hochstadt wrote:
> Sorry, that was very silly of me. That isn't what's happening at all,
> becau
Right -- if we (the typed code) are picking the instantiation, then we
have to check structurally, to make sure that it's really got integers
everywhere.
But if it's a plain type parameter, then the untyped side gets to pick
it, and WLOG they could pick `Any`, meaning that there's no wrong
values
Oh, I see. Yes, even better.
Robby
On Sun, Jan 6, 2013 at 4:36 PM, Sam Tobin-Hochstadt wrote:
> Right -- if we (the typed code) are picking the instantiation, then we
> have to check structurally, to make sure that it's really got integers
> everywhere.
>
> But if it's a plain type parameter,
As you (hopefully) noticed, I've spent a bunch of time this release cycle
trying to improve drracket's interactivity and I'm at the point now where I
could use a little help testing. So, if you have any time to play with the
latest from git (or a nightly build after tonight) and notice that certain
24 matches
Mail list logo
