Re: [ooc-compiler] wrapper to SYSTEM.VAL

[Norayr C. <ch...@gm...>]

MODULE test;
IMPORT SYSTEM;
PROCEDURE ToInt16*(int: LONGINT) : INTEGER;
BEGIN
    RETURN SYSTEM.VAL(INTEGER, int)
END ToInt16;


END test.

test.Mod:5:32: Size mismatch between type and expression

Is it normal behavour to not permit LONGINT->INTEGER cast?
I am still translating Types.Mod from Ulm library.
Types.Mod contains type conversions. It is supposed that people will use
Types exported functions like ToInt16, ToInt32 instead of importing SYSTEM
and use VAL in their higher level modules.

This is why I have this question.
In Ulm's compiler, according to the docs:
*VAL* allows a large number of system-dependent type conversions. It permits
any numerical type to be converted to any other numerical type. Other type
conversions are supported only if both, type and the type of value, occupy
the same number of bytes.
However, Wirth report states:

Name	 |  Argument types	  |  Result type|  Function
_________|________________________|_____________|____________________________

VAL(T, x)|  T, x: any type	  |  T		|  x interpreted as of type T

ooc's reference manual for SYSTEM module is incomplete.

Sincerely,
Norayr

On Mon, Oct 4, 2010 at 6:53 AM, Stewart Greenhill
<sgr...@us...>wrote:

> Hi Norayr,
>
> On 2/10/10 5:42 AM, Norayr Chilingaryan wrote:
> [...]
>
>  So, is it possible in principle to create a VAL wrapper, by taking in
>> consideration that it is implemented on the compiler level actually.
>> Usually, modules in Ulm's library import SYSTEM by using SYS alias, like
>> this:
>> IMPORT SYS:=SYSTEM
>> which I replace by SYS := ULMSYSTEM
>> It is of course possible to change every occurence of SYS.VAL by the
>> SYSTEM.VAL, but I consider it as a dirty option.
>> It is also possible to wrap VAL by using C implementation, what I also
>> would like to avoid for now.
>>
>
> You can't wrap the SYSTEM.VAL function because it is implemented in the
> compiler. There's no way to pass type parameters to Oberon-2 procedures;
> although OOC supports generics, this only works for Object types. I think
> the solution you suggested is probably the best option, though as you say it
> is not ideal.
>
> Cheers,
>  Stewart
>