[racket-dev] What is the policy on what is included in the core libraries?

I was just thinking today that I would, for example, find it useful to have a (zip ...) function in racket/list that would be equivalent to (map list ...). Users coming from a Haskell background might even find it useful to have a zip-with function that is simply an alias for map. Admittedly, th

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

Okay, now I see what you’re saying. That’s a reasonable point, and it’s worth considering. Thanks for bearing with me. > On Jan 30, 2015, at 13:24, Alexander D. Knauth wrote: > > > On Jan 30, 2015, at 3:59 PM, Alexis King <mailto:lexi.lam...@gmail.com>> wrote: > >

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

needs to insert the relevant contracts at the relevant locations. > On Jan 30, 2015, at 07:27, Alexander D. Knauth wrote: > > > > > On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote: >> It isn’t wrapped in an opaque structure. That wasn’t a part of my proposal, >

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

ote: > > > On Jan 29, 2015, at 11:34 PM, Alexis King <mailto:lexi.lam...@gmail.com>> wrote: > >>> But the problem is that if it’s an opaque type then it can’t unwrap it once >>> the value is returned from make-posn. >> >> Yes, that’s precisely

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

w that I think about it. But then you couldn’t do > any operations on it except those that you use import with require/typed, > right? Or not? And what happens if you use cast on one of these things? > > > On Jan 29, 2015, at 9:25 PM, Alexis King <mailto:lexi.lam...@gmail

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

truct with members > of (define-type (Option A) (U 'None (Some A))), where "Some" is a struct with > one field? > > I totally agree that "something needs fixing", but I'm not sure what. > > > > On Thu, Jan 29, 2015 at 10:13 PM, Alexis

Re: [racket-dev] A proposal for parametric opaque types in Typed Racket

t;a" 'b) > Should be fine because Foo could be instantiated at the type (U String > Symbol). > > On Jan 29, 2015, at 9:25 PM, Alexis King <mailto:lexi.lam...@gmail.com>> wrote: > >> I recently ran into a problem in which opaque types (types imported fro

[racket-dev] A proposal for parametric opaque types in Typed Racket

I recently ran into a problem in which opaque types (types imported from untyped code) cannot by parameterized by Typed Racket. I initially encountered this problem in my attempt to port 2htdp/image to TR . After some further considera

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

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

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

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 <mailto:lexi.lam.

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

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

Re: [racket-dev] [racket] Implementing contracts for async channels

so if you wanted to you could try asking > for someone specifically knowledgeable to look there). > > If you don't, I can push the commit to the appropriate repo. Let me know. > > Robby > > > > On Mon, Jan 19, 2015 at 5:44 PM, Alexis King wrote: >> Yes, th

Re: [racket-dev] [racket] Implementing contracts for async channels

? (I just followed the link upthread -- sorry if I need > to look somewhere else too.) > > Robby > > > On Mon, Jan 19, 2015 at 3:15 PM, Alexis King wrote: >> Any update on this? If there’s anything that still needs to be changed, let >> me know—otherwise, I’ll

Re: [racket-dev] [racket] Implementing contracts for async channels

Any update on this? If there’s anything that still needs to be changed, let me know—otherwise, I’ll patiently wait for the process to run its course. Just checking in. > On Jan 16, 2015, at 10:15, Alexis King wrote: > > Ah, that makes sense, fixed. > >> On Jan 16, 201

Re: [racket-dev] [racket] Implementing contracts for async channels

Ah, that makes sense, fixed. > On Jan 16, 2015, at 05:37, Robby Findler wrote: > > One comment. The contract combinators are curried so that you can do > work on the partial applications. So don't write this: > > (define ho-val-first-projection > impersonate/chaperone-async-channel) ctc) bl

Re: [racket-dev] Implementing contracts for async channels

there is some reason to modify the internals of racket/contract > to support them? > > Robby > > On Thu, Jan 15, 2015 at 4:50 PM, Alexis King wrote: >> Sorry, I wasn’t clear. The chaperone/impersonate-async-channel functions are >> exported from racket/async-channe

Re: [racket-dev] Implementing contracts for async channels

tion from racket/contract and > not an async-channel library? > > Robby > > > On Thu, Jan 15, 2015 at 3:33 PM, Alexis King wrote: >> As an update, I’ve made a bit more progress on this. I’ve implemented an >> impersonate-async-channel function, and I’ve actually incl

Re: [racket-dev] Implementing contracts for async channels

new questions: There is no impersonate-evt function, so I’m not sure that my implementation will work. What should I do about this? I’d assume this needs to be documented/tested as well. Where should those things be located? > On Jan 14, 2015, at 23:44, Alexis King wrote: > > Current

[racket-dev] Implementing contracts for async channels

Currently, async channels do not have contracts to check their contents. This is a problem for Typed Racket, and it prevents typed code from interacting with code that produces async channels. I started looking into how to add contracts to the language, and it seems to use the chaperones/impers

Re: [racket-dev] Typed Racket does not play nice with submodules

changing local-require back to require that would break anything else? Or can you possibly implement that change in TR with no issues? > On Jan 12, 2015, at 08:06, Asumu Takikawa <mailto:as...@ccs.neu.edu>> wrote: > > On 2015-01-11 23:29:28 -0800, Alexis King wrote: >&

Re: [racket-dev] Typed Racket does not play nice with submodules

changing local-require back to require that would break anything else? Or can you possibly implement that change in TR with no issues? > On Jan 12, 2015, at 08:06, Asumu Takikawa wrote: > > On 2015-01-11 23:29:28 -0800, Alexis King wrote: >> This is a real problem, since Typed R

[racket-dev] syntax-local-lift-require is useless wrt submodules

I posted this to users@ first, but I think this might be more relevant here. The core problem is that syntax-local-lift-require lifts the #%require form to