[plt-scheme] macro question

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Tue Jun 10 14:02:05 EDT 2008

On Jun 10, 2008, at 1:46 PM, Jos Koot wrote:

> I am inclined to think that in a typed Scheme (or any typed  
> language) much type checking can be done during compilation, thus  
> providing the possibility to omit a possibly large number of type  
> checks at run time. Compiles a little bit slower, but runs faster.  
> This may be important for programs that are compiled once in order  
> to run often.

In principle, types allow space and time savings, but TS is  
parametrically polymorphic, meaning space savings are elusive. For  
now, we're focusing on designing a sound type system that (1)  
interacts with untyped PLT Scheme in a safe manner and (2)  
accommodates idiomatic PLT Scheme programming.

> My personal opinion is that types do not significantly improve  
> readability of programs. A good similarity between data structure  
> and the structure of the procedures acting on these data is far  
> more important, I think (this I did experience, but not invent by  
> myself, of course)

If your comments on data defs and your program organization disagree,  
which one is right? Who is going to point out the discrepancy? If you  
had types, the type checker would. That's how types contribute to  
readability (among other things).

> And of course a typed Scheme should not decrease the possibility to  
> write generic procedures (as is easily done in Scheme) Mho.
> And how is this related to writing very general procedures that are  
> independent of the data representation? For example, when  
> parameterized for the correct accessor and comparator, a binary  
> search in a sorted string can be exactly the same as one in a  
> sorted vector. Please don't convert Scheme into C++, which requires  
> explicit overloading of operators. I never felt comfortable with  
> the overloading tools of C++. How would a typed Scheme handle  
> procedure *sort*? It should, if possible at compile time, check  
> that the object to be sorted and the comparator are compatible with  
> each other.

The sort function is parametrically polymorphic not overloaded:

  (forall (t) (sort ((listof t) (t t -> boolean) -> (listof t)))

Overloading is an entirely different game. -- Matthias

Posted on the users mailing list.