Splitting this out because this is actually a different issue. This is
about us generating slow contracts.
There are two things in play here.
One is that TR doesn't use the new lazy parts of struct/dc. This would
require changing struct contracts from flat contracts to
chaperone-contracts. Given
On Mon, Jun 9, 2014 at 2:44 PM, Matthias Felleisen wrote:
>
> On Jun 9, 2014, at 9:38 AM, Sam Tobin-Hochstadt wrote:
>
>> On Mon, Jun 9, 2014 at 3:19 AM, Eric Dobson wrote:
>>>
>>> It would be nice if the contract on the input to g could be elided. It
>>> seems like this could be done by using s
On Mon, Jun 9, 2014 at 8:35 AM, Sam Tobin-Hochstadt
wrote:
> On Mon, Jun 9, 2014 at 5:48 AM, Robby Findler
> wrote:
>> Am I right that the contract on 'f' is actually (-> symbol? any)? And
>> if so, where is the information coming from that lets you elide the
>> check?
>
> No, the `(boxof symbol?
On Mon, Jun 9, 2014 at 8:38 AM, Sam Tobin-Hochstadt
wrote:
> On Mon, Jun 9, 2014 at 3:19 AM, Eric Dobson wrote:
>>
>> It would be nice if the contract on the input to g could be elided. It
>> seems like this could be done by using something like prop:contracted
>> but that allowed accessing the p
On Mon, Jun 9, 2014 at 8:35 AM, Sam Tobin-Hochstadt
wrote:
> On Mon, Jun 9, 2014 at 5:48 AM, Robby Findler
> wrote:
>> Am I right that the contract on 'f' is actually (-> symbol? any)? And
>> if so, where is the information coming from that lets you elide the
>> check?
>
> No, the `(boxof symbol?
On Jun 9, 2014, at 9:38 AM, Sam Tobin-Hochstadt wrote:
> On Mon, Jun 9, 2014 at 3:19 AM, Eric Dobson wrote:
>>
>> It would be nice if the contract on the input to g could be elided. It
>> seems like this could be done by using something like prop:contracted
>> but that allowed accessing the pa
On 2014-06-09 00:19:40 -0700, Eric Dobson wrote:
> One issue I see is that we need an unforgeable property that the value
> actually came from the typed world so we know that eliding the new
> contract is safe.
>
> Does this seem like a reasonable thing to support/do people see issues with
> it?
On 06/09/2014 10:25 AM, Neil Toronto wrote:
On 06/09/2014 01:19 AM, Eric Dobson wrote:
Does this seem like a reasonable thing to support/do people see issues
with it?
I can only speak on reasonableness, and my answer is emphatically YES.
Typed Racket is a great language in which to define an
On 06/09/2014 01:19 AM, Eric Dobson wrote:
Does this seem like a reasonable thing to support/do people see issues with it?
I can only speak on reasonableness, and my answer is emphatically YES.
Typed Racket is a great language in which to define and use data
structures: access is very fast,
On Mon, Jun 9, 2014 at 3:19 AM, Eric Dobson wrote:
>
> It would be nice if the contract on the input to g could be elided. It
> seems like this could be done by using something like prop:contracted
> but that allowed accessing the parties that agreed to the contract.
>
> I'm imagining something li
On Mon, Jun 9, 2014 at 5:48 AM, Robby Findler
wrote:
> Am I right that the contract on 'f' is actually (-> symbol? any)? And
> if so, where is the information coming from that lets you elide the
> check?
No, the `(boxof symbol?)` contract has to be kept around because of mutability.
> One idea f
Am I right that the contract on 'f' is actually (-> symbol? any)? And
if so, where is the information coming from that lets you elide the
check?
One idea for this particular case: make 'g' be a macro that inspects
its argument and if it see "obvious" things like this, then it can
expand into a cal
One of the slowest parts when using TR is the contract boundary
between untyped and typed code. Even with recent changes it still
causes a large overhead.
Example:
#lang racket/load
(module lib typed/racket
(provide f g)
(: f (Symbol -> (Boxof Symbol)))
(define (f x) (box x))
(: g ((Boxof
13 matches
Mail list logo
