On Jan 5, 2016, at 9:51 PM, Emmanuel Oga <emmanuel...@gmail.com> wrote:
> On Tuesday, January 5, 2016 at 11:12:44 AM UTC-8, Matthias Felleisen wrote: >> TR is intended for people who wish to add types retroactively. > > Not sure I understand this stance: > > * Does this mean if I want to use types proactively, TR is not a recommended > PL? > > * Or maybe it means adding types proactively is just not a recommended way to > go in general, and types should only be added when the code base reaches > certain trigger conditions? > >> The actual purpose is to record with sound, checked types what the designer >> had in his head retroactively so that developers can benefit from this type >> information and so that the creation of *new code* can benefit from the >> (shallow but large) advantages of types and type checking. > > BTW I did read this "actual purpose" paragraph. I'm just not sure how this > answers my comments above :-). I will say this as the first Racketeer and Typed Racketeer: if you just want to program in an explicitly-statically typed language (possibly with inference), you might wish to broaden your scope of search. There are other expressively typed languages that come with good libraries. Most of these languages are much more mature than TR and probably more reliable and stable (in this sense). I am not sending you away. I am a scientist-designer who wants user-developers to be highly informed. -- In this spirit, TR is explicitly designed to help developers move from untyped code to [explicitly-statically and sound] typed cpde in an incremental, module-by-module manner [*]. This is spelled out in the DSL 2006 vision paper. As such, TR's type system *must* accommodate many of the programming idioms that developed in Racket/Scheme/Lisp over the past six decades. This makes the type system unusual and a bit quirky. For example, we do not support abstract types to the point where one new member of the team said "but TR doesn't have types" (thinking of Reynolds's slogan). -- At the same time, our experiments with 10s of thousands of lines suggest that it is possible to port lots of code without changing much about the structure of the code. That increases the likelihood that the code remains functioning as developers convert. Naturally we expect a test suite to confirm the validity of these intermediate conversion points. -- Having said that, you also need to know that I advertise the use of explicit types even when your chosen language does not have a static type system. See "how to design programs" for the underlying philosophy. The basic reason is that types exist whether your language allows you to write them down or not. If it doesn't, use comments to develop them before you code because doing so will help you very much develop well-organized most-likely-pretty-much-working code. You won't have the advantages of type systems, which (mostly) check shallow properties and violations of those. But you do have the deeper advantage of organizing your thoughts. I have followed this philosophy since 1986 and co-authored (rewrote) my first book on this idea back them. It works :-) [*] Let's ignore why we are doing this for now. The 'actual purpose' paragraph sketched this out in a hyper-concise manner. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
