Re: Typed Guile?

[Ian Price]

Panicz Maciej Godek <address@hidden> writes:

> I've heard a lot about the type system of Haskell, but I don't know
> any details. Neither do I know much about racket's, but I know for
> sure that it doesn't suit my taste.
How can you accurately judge something you don't know much about?

> GOOPS' type system is lacking two features, the first one being the
> return value of a procedure, and the second, types for collections.
>
> So I think, that type annotation for the return value of a method
> could be a coherent extension to the existing system. For example, one
> could write:
> (define-method (name (arg1 <type1>) ... (argN <typeN>)) : <return-type>
>   body ...)
> slightly extending the define-method as it is used today.
Adding syntax for this is easy, but it would completely change the
nature of Scheme. How does a procedure know which type to return?

It can either infer it, which requires more than a simple extension of
goops, or you can return some sort of "value", than you then tell which
type you expect it to have. Which may mess with the order of
evaluation (I'd more time to think about this), and wouldn't play well
with non-goops procedures.

At least, these are my immediate reactions, I will be happy to be proved
wrong. (I'm going to CC Typed Racket's SamTH, I expect a clos-like
solution has been suggested to him many times, and he might have some
better idea of the pros/cons of this)

> The second postulate is more difficult to agree upon with. I think the
> nicest way would be to use the omnipresent pattern language, so for
> instance the procedure taking the list of numbers could be written as:
> (define-method (mean (S (<number> ...))) : <number>
>   (/ (apply + S) (length S)))
>
> (define-method (mean (v #(<real> ...))) : <number>
>   (mean (vector->list v)))
>
> It could be similarly used to define methods with variable number of
> arguments of the same type, e.g.
> (define-method (mean (n <number>) . (rest (<number> ...))) : <number>
>   (mean (cons n rest)))

This will not work with arbitrary user defined collections?

> Unfortunately, the pattern language alone would be insufficient, at
> least not in its present shape. That's because we would also like to
> be able to specify the types of hashes and procedures, like below
> (it's actually inspired by the code that I'm writing at the moment):
> (define-method
>   (handle-clients
>     (connection (<number> . <number>))
>     (clients (hash (<number> . <number>) (hash <symbol> <procedure>)))
>     (handle-new-connection ((procedure <number>) : (hash <symbol>
> <procedure>))))
>   [body])
>
> I don't know to what extent is this readable. My intention is that the
> syntax (hash <key-type> <value-type>) would express a hash table such
> that all its keys are of type <key-type>, and values of <value-type>,
> respectively.
> Similarly, ((procedure <arg1-type> ... <argN-type>) : <return-type>)
> stands for the procedure of a certain type.
> This notation is just a proposition for what I'm willing to express.
> There is a question regarding the implementation, however (especially,
> defining new types). I think it would be a problem for the
> pattern-matcher to distinguish between (hash <key-type> <value-type>)
> [a hash] and (<hash> <key-type> <value-type>) [a list], so maybe
> another notation would be required (like (% hash ...), (% procedure
> ...), or #%hash(<k> <v>) ..., or something similar).
>
> I think that parsimony is one of the advantages of such a type system.
> One could say that having any type system is better than having none,
> but I don't think that this refers to the realm of Scheme :)
> Secondly, building it atop of GOOPS would be valuable in this respect,
> that it could be later adapted by the chicken's scheme COOPS object
> system, which also derived from CLOS and seems compatible with GOOPS
> (vide http://wiki.call-cc.org/eggref/4/coops).
>
> I don't know what the rest of the community has to say about this, but
> if you managed to implement this, I can promise that you'd have at
> least one user :)

Unless you give me more details about how this is to work, I think an
implementation is out of the question.

> (Among the things that I dislike in the typed Racket is that firstly
> it posits plurality without necessity, introducing labels like Listof,
> that a programmer needs to memoize or look up in the documentation,
> and secondly, it introduces not-much-telling identifier :, which,
> although looks joyfully when used ("(:"), is quite far from the spirit
> of SICP)
>
> BTW Does anyone here know what does the #& ("box") quasi-pattern in
> the Shinn-Wright pattern matcher stand for?
A box is, more or less, a one element vector. Guile does not have a box
type, nor reader syntax for it, arguably it should...

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"