Re: [racket-dev] In Typed Racket, struct declarations do not work in an internal definition context

[Alexis King]

Yes, I’d considered that point, and yes, it makes sense. Anyway, the situation 
in which I was trying to do something like this ended up being unnecessary, so 
I don’t even have a valid use-case anymore. I think it’s probably okay to leave 
it as-is unless someone can come up with a useful reason to care.

> On Jan 24, 2015, at 09:24, Sam Tobin-Hochstadt  wrote:
> 
> On Thu, Jan 22, 2015 at 3:57 PM, Alexis King  wrote:
>> 
>> I can work around this in a variety of ways—I can extract this into an
>> untyped module and use require/typed, I can use vectors to “fake” structs
>> and provide an appropriate interface, etc. Still, I wonder if there are any
>> plans to resolve this type of problem? Since it seems to be an issue with
>> how TR handles types at its core, I’m not even sure how feasible it would
>> be.
> 
> 
> I don't currently have plans to work on this problem. The big issue is
> that Racket structs are what's called "generative", meaning that each
> time you execute a struct declaration, you get a different struct
> type. Thus it's not at all clear what the right type should be for
> your `make-me-a-struct` function, and type systems that do allow this
> sort of thing (such as ML) would reject this particular use.
> 
> Can you say more about the specific issue you're having? There might
> be a different way around it.
> 
> Sam


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] In Typed Racket, struct declarations do not work in an internal definition context

[Sam Tobin-Hochstadt]

On Thu, Jan 22, 2015 at 3:57 PM, Alexis King  wrote:
>
> I can work around this in a variety of ways—I can extract this into an
> untyped module and use require/typed, I can use vectors to “fake” structs
> and provide an appropriate interface, etc. Still, I wonder if there are any
> plans to resolve this type of problem? Since it seems to be an issue with
> how TR handles types at its core, I’m not even sure how feasible it would
> be.


I don't currently have plans to work on this problem. The big issue is
that Racket structs are what's called "generative", meaning that each
time you execute a struct declaration, you get a different struct
type. Thus it's not at all clear what the right type should be for
your `make-me-a-struct` function, and type systems that do allow this
sort of thing (such as ML) would reject this particular use.

Can you say more about the specific issue you're having? There might
be a different way around it.

Sam

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] In Typed Racket, struct declarations do not work in an internal definition context

[Alexis King]

I haven’t dug deep enough into the TR code to know for sure, but I think the 
difference is that structs declare fundamentally new types, whereas inline type 
definitions only declare type aliases. Whether or not this is actually the 
problem is unclear—I don’t know TR well enough to answer that.

> On Jan 23, 2015, at 21:23, Alexander D. Knauth  wrote:
> 
> There’s a bug report about this here:
> http://bugs.racket-lang.org/query/?cmd=view&pr=14524 
> 
> Though I notice it gives a different error message now.
> But why should structure type declarations being a module-wide construct?
> Internal function definitions work, and internal type definitions work, so 
> why shouldn’t internal structure definitions?
> 
> 
> On Jan 22, 2015, at 3:57 PM, Alexis King  > wrote:
> 
>> Simple enough. This works:
>> 
>> #lang racket
>> 
>> (define (make-me-a-struct)
>>   (struct foo ())
>>   (foo))
>> 
>> (make-me-a-struct) ; => #
>> 
>> This does not:
>> 
>> #lang typed/racket
>> 
>> (define (make-me-a-struct)
>>   (struct foo ())
>>   (foo)) ; error: cannot apply a function with unknown arity
>> 
>> (make-me-a-struct)
>> 
>> This problem makes sense. Type declarations seem to be a module-wide 
>> construct, so a type that should be scoped to a single function doesn’t 
>> work. I’m running into this issue when trying to create an executable struct 
>> using define-struct/exec from within a macro, which doesn’t work due to this 
>> particular problem.
>> 
>> I can work around this in a variety of ways—I can extract this into an 
>> untyped module and use require/typed, I can use vectors to “fake” structs 
>> and provide an appropriate interface, etc. Still, I wonder if there are any 
>> plans to resolve this type of problem? Since it seems to be an issue with 
>> how TR handles types at its core, I’m not even sure how feasible it would be.
>> _
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev 
> 

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] In Typed Racket, struct declarations do not work in an internal definition context

[Alexander D. Knauth]

There’s a bug report about this here:
http://bugs.racket-lang.org/query/?cmd=view&pr=14524
Though I notice it gives a different error message now.
But why should structure type declarations being a module-wide construct?
Internal function definitions work, and internal type definitions work, so why 
shouldn’t internal structure definitions?


On Jan 22, 2015, at 3:57 PM, Alexis King  wrote:

> Simple enough. This works:
> 
> #lang racket
> 
> (define (make-me-a-struct)
>   (struct foo ())
>   (foo))
> 
> (make-me-a-struct) ; => #
> 
> This does not:
> 
> #lang typed/racket
> 
> (define (make-me-a-struct)
>   (struct foo ())
>   (foo)) ; error: cannot apply a function with unknown arity
> 
> (make-me-a-struct)
> 
> This problem makes sense. Type declarations seem to be a module-wide 
> construct, so a type that should be scoped to a single function doesn’t work. 
> I’m running into this issue when trying to create an executable struct using 
> define-struct/exec from within a macro, which doesn’t work due to this 
> particular problem.
> 
> I can work around this in a variety of ways—I can extract this into an 
> untyped module and use require/typed, I can use vectors to “fake” structs and 
> provide an appropriate interface, etc. Still, I wonder if there are any plans 
> to resolve this type of problem? Since it seems to be an issue with how TR 
> handles types at its core, I’m not even sure how feasible it would be.
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev

_
  Racket Developers list:
  http://lists.racket-lang.org/dev