>
> > >
> > >
> > >
> > > > On May 12, 2017, at 11:38 AM, Robby Findler
> > > > wrote:
> > > >
> > > > Yeah, that's a real one. :)
> > > >
> > > > Robby
> > > >
> > > > On Fr
> from one thread to another, not *data*. You need to convince me that data
> > flows and then we need to figure out how to protect/monitor this data. And
> > at that point, you can possibly see lambdas flow too.
> >
> >
> >
> > > On May 12, 2017,
gt; from one thread to another, not *data*. You need to convince me that data
> flows and then we need to figure out how to protect/monitor this data. And at
> that point, you can possibly see lambdas flow too.
>
>
>
> > On May 12, 2017, at 11:02 AM, Scott Moore wrote:
>
I think the interesting distinction is that threads, regexps, ports, etc, are
communication channels, but not for higher-order values.
On May 12, 2017, 10:58 AM -0400, Scott Moore , wrote:
> (define (component-1 value)
> (define t
> (thread (lambda ()
> (thre
>
> > > > > > >
> > > > > > > On Thu, May 11, 2017 at 5:39 PM, Robby Findler
> > > > > > > wrote:
> > > > > > > > What if #:authentic (or whatever) were only allowed on immutable
> > > > > > > > objects and we
> I agree that generally don't want performance declarations that
> interfere with reasonable interposition. The good uses of `#:authentic`
> would be in places where the struct representation of a value is not
> exposed or where the values themselves are not exposed (so any
> interposition means
Out of curiosity, where does the additional overhead come from? Without looking
at the struct predicate code, I would have expected this to be a
relatively-well predicted branch on the Scheme_Type of the object. I haven’t
been following the Chez port though—are impersonators being implemented at
we can do with Asumu’s type system (because we could compile
gradual types to such contracts).
In any case, you guys should spin this off as a separate idea, perhaps
for ICFP or DSL You are a PhD student and Christos is a post-doc. Go
for it.
— Matthias
> On Jan 28, 201
Thanks for taking a look, and for your help getting it set up to build using
the package system!
On January 28, 2016 at 12:38:00 AM, Asumu Takikawa
(as...@ccs.neu.edu(mailto:as...@ccs.neu.edu)) wrote:
> Hi Scott,
>
> This is cool!
>
> On 2016-01-27 14:05:10 -0500, Sc
While we were developing shill we devised a useful form of contract
that we called a "bounded parametric polymorphic contract." A bounded
parametric polymorphic contract emulates bounded parametric
polymorphism similar to how existing Racket parametric contracts
emulate parametric polymorphism. Our
Hi all,
The racket program below exhibits behavior that I think is a bug. When using
define/contract (and I believe with-contract), contracts seem to get applied to
values later than expected. In particular, in the following example I expect
all uses of the variable “test” to see the wrapper ad
It occurs to me that this might be a better question for racket-dev, so I'm
forwarding it here.
Thanks,
Scott
-- Forwarded message --
From: Scott Moore
Date: Fri, Mar 6, 2015 at 8:04 PM
Subject: Unexpected results with impersonators and make-keyword-procedure
To: Racket
12 matches
Mail list logo
