Re: My scripting language - any suggestions?

On Sun, 7 Sep 2008 00:02:32 +0700, Aleksey Demakov wrote:


> On Wed, Sep 3, 2008 at 12:22 AM, Dmitry A. Kazakov
> <mailbox@dmitry-kazakov.de> wrote:
>> On Tue, 2 Sep 2008 00:54:12 +0700, Aleksey Demakov wrote:
>>> Suppose we have a method that simply returns the sum of two args:
>>>
>>> m(a, b) { return a + b; }
>>
>> First of all, this is not a specification of the method. The types of the
>> arguments and of the result are unspecified, as well as the covariance of.
>> So one cannot tell which combinations of arguments and result types are
>> involved.
>
> We were talking in the context of a scripting language. If you notice
> the variables in this language are declared as "var a = 5;". No type
> tag whatsoever.


The language is typed, thus a must have a type. Whether that type is
manifested in the declaration or else inferred from the type of the
initializing expression is no matter.


> I don't see a reason why for such a language
> parameters are to be declared with the type tag. But if you wish I
> could write the method definition like this:
>
> Float m(Float a, Float b) { return a + b; }


You should also define covariance. When Integer is derived from Float which
parameters (arguments and the result) become Integer and which are not. In
other words in which parameters m is a method of Float. Method = covariant.


>> As for multimethods, yes there are six combinations of 3 (2 arguments + 1
>> result) x 2 types. The semantics of m shall unambiguously define all six.
>> But again it is not the language business, except for the predefined
>> operations of course. The language shall merely allow an implementation of
>> the desired semantics for all combinations in question.
>
> What do multimethods have to do with this? You say that a language
> "with an elaborated types system" should make integer a subtype
> of float. My understanding of subtyping is that a subtype might go
> anywhere the supertype could go.


Right, but this does not mean that you can pass Integer where Float is
expected. That is a type error. Substitutability is achieved:


1. by introducing new instances of polymorphic m. For example, when m is a
method in the argument a, that means that m is defined on the class Float
and for each type from the class there exists an instance of m with a of
this type:


... m (Float a, ...);
... m (Integer a, ...);


When Integer inherits m without overriding, then


... m (Integer a, ...);


is defined as a composition of Float m and a conversion from Integer to
Float.


2. by using operations defined on the whole class.


> I conclude that there is no need for
> any 6 combinations. The method defined for float arguments should
> somehow handle int arguments too.


They cannot, it were untyped. It must be either 1 or 2. You have to choose
what case m represents in which parameter.


>> The result is involved, provided that m is covariant, or else when Float is
>> the ancestor of Integer and the result is contravariant. As for the
>> semantics (numerical value of the result), see above.
>
> I don't get what "covariant" or "contravariant" mean.


See above. Covariant = method, which is inherited and can be overridden.


> I asked a simple
> question. Please tell me what a language "with an elaborated types
> system" will do for m(1, 2000000000,0) .


I will allow the user to define the semantics of above in accordance with
the meaning of m. I don't know what m is supposed to do. Does it model
addition? In R? N? C?


Again, the point is that if m is a method in all arguments and the result
then overriding it gives you an opportunity to implement any semantics you
want:


Integer m (Integer a, Float b) { ... } // When integer expected
Float m (Integer a, Float b) { ... } // When float expected


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

Return to the comp.compilers page.
Search the comp.compilers archives again.