[plt-scheme] macro question

Hi


On 10 Jun, 2008, at 18:46, Jos Koot wrote:

> Much of this discussion is above my head. Yet a few short, may be  
> silly, remarks.
Ditto :-)

> 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)
Are you thinking in types "à lá C"? As in, having to type (almost)  
every expression by hand? Or do you feel that even with a type system  
like Haskell's?


> And of course a typed Scheme should not decrease the possibility to  
> write generic procedures (as is easily done in Scheme) Mho.
Indeed, it shouldn't. You should be able to write polymorphic  
functions in it, at least.

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

If you use a system like Haskell's type classes, you don't have  
operator overloading, you have functions which operate on type classes  
(instead of types) and, when your type belongs to that class, you can  
use it in any function for that type class. That's how the numeric  
operators are written, for example. You just have to provide some  
functions for your type and then you "unlock" the whole type class and  
its functions.

So, your parameterized sort would receive an accessor, a comparator  
and a sequence/collection.
With type classes you wouldn't even need the accessor and comparator,  
you would just make the sequence type implement the IndexedSequence  
(for example) type class, and make the element type an instance of Ord.

Trying to derive a type blindly, I would say:
sort :: (IndexedSequence a, Ord b) => a b -> a b

If you wanted, you could really pass it a function, for when you don't  
want to use < (or >), but your own predicate (without disturbing the  
Ord declaration or without having to make one).
sortWith :: (IndexedSequence a) => a b -> (b -> b -> Bool) -> a b

I hope I didn't add too much noise :-)

   - Filipe Cabecinhas