[plt-scheme] macro question

Thanks for replying.

----- Original Message ----- 
From: "Matthias Felleisen" <matthias at ccs.neu.edu>
To: "Jos Koot" <jos.koot at telefonica.net>
Cc: <plt-scheme at list.cs.brown.edu>
Sent: Tuesday, June 10, 2008 8:02 PM
Subject: Re: [plt-scheme] macro question


>
> 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.

Understood.

>
>
>> 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).

Of course it is nice having a type checker pointing to the discrepancy. I 
agree that explicit formulation of the intentions of the programmer can 
improve readability, but only with the condition that the code is not 
overloaded with an abundance of lines that interrupt the story of the 
algorithms. When possible, I try to separate algorithms from data 
representation. I.e. When I do a serious job, I try to write algorithms as 
abstractions over the representation. This is called ADT if I am not 
mistaken :)

>
>> 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

Thanks, I think I now have a beginning of understanding how a type checker 
could handle a parameterically polymorphic function.
(Yes, I did confuse this parameterization with overloading. my fault)
Thanks again, Jos

>
>