Re: S-expression I/O in Ada

[_FrnchFrgg_ <frnchfrgg@free.fr>]

Le 10/08/2010 13:19, Dmitry A. Kazakov a �crit :
> On Tue, 10 Aug 2010 13:06:58 +0200, _FrnchFrgg_ wrote:

>> Unification and pattern matching is independent of type inference.
>
> Did you mean the standard meaning of pattern matching instead of Standard
> ML's Volap�k?

I meant pattern matching as a ML construct, which is in fact structural 
unification. It can be done even without type inference, and only needs 
some kind of polymorphism; essentially you have an object and an 
expression made of (possibly nested) constructors, with leaves being 
either constants or variables, and the unification engine answers

a) if the object could be obtained by the sequence of constructors, or not
b) if yes, the content the variables would have had so that the sequence 
of constructors would produce the object.

For convenience, you often have a list of expressions, and the engine 
executes the code of the first which fits the object.

Of course, if you don't want a type orgy (aka dynamic types), you'd 
probably want all the constructor expressions create subtypes of a base 
one, and the object also be a subtype of this base one. When the 
language also does type inference, then this "greatest common 
denominator" is calculated at compile-time (and the language typically 
is able to tell you have forgotten to cover all possible constructor 
sequences for the type).

But nothing prevents a language to require explicit types and enforce 
them just by checking with no inference at all. And in fact, IIRC I was 
shown a language having unification without type inference (not PROLOG, 
because its unification is for predicates and doesn't count). I do not 
recall the name of the language (it was probably not much used). Anyway 
OCaml could arguably be considered as an exemple(1).

Note that "pattern matching" as described here is well tailored to 
immutable objects; I think there are ways to accomodate mutability, but 
I do not remember clearly. Since OCaml has mutability in objects if 
wanted, and pattern matching on objects (not only on algebraic types), I 
suppose they solved the problem in some way.

(1) Even if you don't like type inference (and I agree that a human 
reading the code shouldn't be required to "infer" the types, and as such 
that types should be annotated), every language I know with type 
inference accepts explicit type annotations so you can always type 
explicitly every variable and you exactly get a strongly, explicitely 
typed language.