Re: 64-bit extensions

[Tim Teulings <tim@edge.ping.de>]

Hallo!

> Of course, the argument might be made that this will break the type
> safeness of Oberon-2.  But it's already broken.  My response would be to 
> close this loophole and not allow the concept of any type being compatible 
> with an ARRAY OF BYTE.  I don't know of any functions which couldn't be 
> performed in a type-safe way without this loophole.

I don't have problems with ARRAY OF SYSTEM.BYTE. It is nice, easy and it
explicitely states that it may result in problems because of "SYSTEM" in
it.

> Not every string needs this.  Just the lowest level interfaces to the
> OS.

Yes, but ooc interface to the OS is bases (and will be mostly based in the
future, too) and things like POSIX. There isn't much Unicode in POSIX, so
no reason to make it a central part of strings handling in ooc. In fact
using something like UNICHAR with the fitting modules for conversion etc..
is exactly the thing most OS offer, too. And not that more.

> There haven't been many new OSes.  The BeOS is the only recent one I
> know of and it supports UTF for GUI text drawing while maintaining
> Posix compatibility at a lower level with ASCII strings.  For characters
> < 7FX, the two are equivalent so the conversion overhead is minimal.

So it does handle Unicode like a special UNICHAr type. In spite of being
"new" is bases itself on posix (a standard without which there were no GNU
utils etc, supporting posix maybe one reason that bebox still exists
;-)) and does not bases everything on Unicode.

> > Yes, if you can't kill your enemy, join him ;-) However I see support
> > for the java engine at the horizon :-| And there is not only the bytecode
> 
> Do you know about something interesting which is ongoing?

No. Sorry, I missed a "not".

> > interpreter, but the whole jave engine, and I doubt we can totaly map
> > everything to that (GUI, IO etc...), so this can't be really done...?

> Well, I think we could simulate the Java libs in OOC and then put native
> calls to those libs in place when targetting Java output.

The whole class system is different. It maybe differnet to C++ but in my
opinion the same problems will arise. And note, that a Java is not simply
the byte code is more. Without access to the native classes you can do
nothing since you don't have access to the underlying OS because of the
design of java. So you have to build a oberon class for every java class.
You can then put all oo2c classes in the garbage then and have to adapt
every tool to the oberon mapping classes. I don't thing thats a workable
solution. And if it would work I doubt anybody would spend that much work.
Also it seems that the java classes are in permanent fluctuation and it
might be that you have to redo your work in a half year. There isn't the
workpower to build a fontend for juice which wouldn't be that complex as it
would for Java. 

-- 
Gru...
       Tim.