On Mar 9, 2015, at 12:13 PM, Vincent St-Amour <[email protected]> wrote:
> I'd say: go for it! :)
>
> I recommend you design the type system aspects first, then work on the
> implementation. It's easier to iterate on the design that way, and
> conceptual bugs should be apparent earlier in the process.
>
> I won't lie, this is probably not going to be easy work, but it would
> definitely be a good addition to TR, not to mention a major learning
> experience for you. :)
>
> If you need pointers/advice, feel free to ask Sam/Asumu/Eric/Andrew/myself.
> From that group, Sam and Asumu are probably the ones most familiar with
> the relevant type systems literature, and can probably point you to
> papers with potential starting points.
Alexis, I am usually all in favor of encouraging contributions. The
more, the merrier. But this time around, I'd like to spell out what
such a project implies realistically before you go on an incredibly
difficult expedition.
1. I consider this project research, not just advanced development.
2. I tell all my PhD students
Research is when it can fail.
A failure might be a serious investment here.
3. Typed Racket has a design plan and philosophy. I think you're
basically familiar with the ideas -- your email touches on many
of these.
Here is how we proceeded with adding types to classes, and I think
our experience shows that this is a good routine:
-- collect examples of uses [hard, because as Vincent says,
generics are new]
-- explore literature [the very original papers on Haskell's
generics might be a good fit here; I am having Ben G.
read up on this because many are interested in this]
-- pick a few examples from step 1 as 'formative tests'
-- design syntax of types, meaning
-- design type system and make sure your examples go through
[a Redex model worked really well, easy prototyping
and can run existing Racket examples usually]
-- repeat these steps until stable
-- argue that the type system is sound (all of its predictions
are true)
-- design type to contract compiler
-- argue the combination is sound
-- repeat these steps until stable
== You may have to backtrack all the way up to syntax/meaning
to fix problems here
-- evaluate expressiveness
-- evaluate performance
== You may have to backtrack again all the way up to syntax/meaning
to fix problems here
Some of these steps call for novel ways of doing things.
Some just call for doing old things right. I am sure you
can call on help for some of the implementation and/or
work-intensive parts. But if people didn't follow along
with your development, they need ways to find out what
your design decisions are.
You will need to keep writing little essays on these steps
so that people can join you.
We have been through this twice now for significant projects (classes,
units). We have done it smaller things. If I considered generics small,
I wouldn't write this message.
Adding type isn't just an implementation project. If you're still
up for it, make a plan, Add it to your project pages. Develop a
work routine. Develop a writing routine. Ask for help. A lot. Be
prepared to spend a serious amount of time.
-- Matthias
--
You received this message because you are subscribed to the Google Groups
"Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/E9CCBFA2-4457-4FE6-8535-6F0413D88D3B%40ccs.neu.edu.
For more options, visit https://groups.google.com/d/optout.
