Re: My scripting language - any suggestions?

On Tue, 2 Sep 2008 00:54:12 +0700, Aleksey Demakov wrote:


> On Sun, Aug 31, 2008 at 9:58 PM, Dmitry A. Kazakov
> <mailbox@dmitry-kazakov.de> wrote:


>>> If you use hardware-supported 32-bit representation of floats then
>>> there will be a problem with precision. Some Int values cannot not be
>>> precisely represented as floats.
>>
>> That is up to inherited operations. Basically, if Integer inherits
>> anything from Float it also does the property of Float being an
>> interval of [real] numbers, with the consequences of. If Integer can
>> do this operation better, then it should override. The third
>> alternative is adding ideal values to the class in the form of NaN or
>> else an exception propagation.
>
> Sorry, I still don't get how the inheritance thing alone could
> automagically resolve all the subtle numeric issues.


It cannot. But the question was about shared vs separate representations,
which is not a numerical issue.


> 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.


> I could understand what happens If both args have the same type.
> For instance if ints and floats both use 32-bit representation then
>
> m(1, 2000000000)
>
> will quite obviously result in 2000000001
>
> while
>
> m(1.0, 2000000000,0)
>
> will result in 2000000000.0 - 32-bit floats do not have enough
> precision to keep the '1' in the end.
>
> Now what will happen if one argument is int and another
> is float ?
>
> m(1, 2000000000.0)


That depends on how the question above is answered and of course on the
semantics of m. Note that the language is not to specify the semantics of
m.


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.


> will it be 2000000001, or 2000000000,0, or a runtime error?
>
> In any case the user might prefer one way or another. In
> the last example if the user wants to preserve the precision
> then this could be done by converting float to int. On the
> other hand for m(1, 1.0e15) conversion to int will not work
> so it should not be done.


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.


> So do you reserve the possibility for a user to do the explicit
> conversion?


Certainly yes. An explicit conversion is merely a subprogram. But I would
also allow user-defined ad-hoc subtypes, so that one could tie two
originally independent hierarchies.


> Or never is never and explicit conversion is always
> a design problem?


Close to that. When I analyse the cases where I used conversions, most of
them liked suspicious or else were introduced by language limitations.


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

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