Re: Formal and informal type systems?

From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 09/29/04 

Date: Wed, 29 Sep 2004 09:49:03 +0200

On 28 Sep 2004 20:54:02 +0200, Mark Lorenzen wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
>
>> Marius Amado Alves <amado.alves@netcabo.pt> wrote:
>>: Mark Lorenzen wrote:
>>:> Some things I miss in Ada that are available in ML: Higher order
>>:> functions, pattern matching and tuples.
>>
>> [GNAT.SPITBOL]
>>
>> Maybe the phrase "argument pattern matching" should be substituted
>> for "pattern matching" outside "functional communities", to avoid
>> misunderstandings. From a user's perspective, argument pattern
>> matching has little to to with grammar based pattern matching of
>> strings. Rather, it is distant relative of 'class and case.
>
> Right. I meant argument pattern matching.
>
> Consider the following data type and it's two value constructors:
>
> type Optional_Integer (Defined : Boolean) is
> record
> case Defined is
> when True => Value : Integer;
> when False => null;
> end case;
> end record;
>
> I think it would be quite nice to have the possibility to define the
> following subprograms:
>
> procedure Do_Something (I : Optional_Integer(Defined => False)) is
> begin
> null;
> end Do_Something;
>
> procedure Do_Something (I : Optional_Integer(Defined => True, Value)) is
> begin
> Do_Something_More(Value);
> end Do_Something;

But this is already possible. Consider the following:

   type Optional_Integer (Defined : Boolean) is tagged record
     case Defined is
        when True => Value : Integer;
        when False => null;
     end case;
   end record;

   type Defined_Integer is
      new Optional_Integer (True) with null record;

   type Undefined_Integer is
      new Optional_Integer (False) with null record;

   procedure Do_Something (I : Defined_Integer) is
   begin
      Put_Line ("Defined:" & Integer'Image (I.Value));
   end;

   procedure Do_Something (I : Undefined_Integer) is
   begin
      Put_Line ("Undefined");
   end;

The point is that there is no need to invent extra parameter matching
mechanism. One should use and possibly extend the existing one based on
inheritance.

> The pattern matching could also be extended to case statements such as:
>
> procedure Do_Something (I : Optional_Integer) is
> begin
> case I is
> when Optional_Integer'(Defined => False) => null;
> when Optional_Integer'(Defined => True, Value) =>
> Do_Something_More(Value);
> end case;
> end Do_Something;
>
> (Credit goes to one of my colleagues for the idea of using the type
> name as constructor in the patterns.)

I don't understand this example. Looks just like a class-wide of
Optional_Integer. Am I right?

>>: In Ada you have, respectively: access-to-subprograms types,
>>
>> but functions cannot carry their environments with them, to the same
>> extent?
>
> With higher-order functions I also meant that functions should be
> first-class citizens in the language. In order to use this effectively
> we also need currying, and lambda expressions. All in all this is
> probably too much of a change to Ada.

To start with, we could introduce function types. I cannot understand why
we have access-to-function types and still have to types for the target.

>> Mark, did you mean tuple matching when you said that tuples (records
>> and arrays interchangeably) are missing in Ada?
>
> Yes, tuple matching using the same ideas as above, but also as
> parameter types and function return types. Simply a short way of
> defining an anonymous record type.
>
> function F ((A, B) : (Positive * Natural)) return (String * Natural);
>
> (S, N) : (String * Integer) := F (C, D);
>
> This avoids the tedious definition of record types for simple pairs.

That requires structured type matching, which is a bad idea, in general. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Relevant Pages