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

[Stewart G. <sgr...@us...>]

Hi Norayr,

Normally, you would to a LONGINT->INTEGER conversion like this:
   RETURN SHORT(int);

Personally I'm not a fan of SHORT. It requires you to know the size of 
the original types in order to figure out how many SHORTs are required 
to do the conversion. So a LONGINT -> SHORTINT conversion goes:
   RETURN SHORT(SHORT(int));
...but you can't for example convert an arbitrary integer type to a 
SHORTINT.

It looks like OOC's interpretation of SYSTEM.VAL requires it to be a 
pure type-cast. Normally you would use it like this for casting pointer 
types. You would need to explicitly SHORTen the argument if casting to a 
smaller size. Since conversion between numeric types is supported in the 
language anyway its probably not a big problem.

Cheers,
   Stewart

On 5/10/10 3:19 AM, Norayr Chilingaryan wrote:
> 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 typeT
>
> ooc's reference manual for SYSTEM module is incomplete.
>
> Sincerely,
> Norayr
>
> On Mon, Oct 4, 2010 at 6:53 AM, Stewart Greenhill
> <sgr...@us... <mailto: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
>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
>
>
>
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler