[plt-scheme] macro question

----- Original Message ----- 
From: "Filipe Cabecinhas" <filcab at gmail.com>
To: "Jos Koot" <jos.koot at telefonica.net>
Cc: <plt-scheme at list.cs.brown.edu>
Sent: Tuesday, June 10, 2008 10:35 PM
Subject: Re: [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?

           I did not think of a particular type system.
           I have not much knwoledge of them.
           But as you may have guessed I was worried that
           a type system would put me in an inflexible cuirass (as in C)
           I have been convinced by this thread that my fear
           is not needed.
           Thanks, Jos


> 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