Re: 64-bit extensions

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

Hallo!

> > Maybe I'm reading more into this than is actually there, but I'm
> > interpreting this to mean that, with OOC as it is now, implementing a
> > Java byte-code backend would be very difficult.  I can understand
> > that.  
> 
> I can't.  Why is everyone saying that?

You will have exactly the problems when someone tells you: Make ooc
support the use of C++ classes including multiple inhertance and
templates. Since you already try to create a method for accessing the C++
interface of the BeBox you should already know a uncountable number of the
even more uncountable number of problems that arise. You can't divide the
java bytecode and the java language with its API. See my other mail.

> > At this point, I'd actually be more interested in a backend that
> > produced Juice slim binaries.  Has anyone looked into what the
> > barriers to such a thing would be?
> 
> This would be next to impossible with OOC.  The Juice slim binaries
> are actually little more than compressed compiler syntax trees.  OOC
> discards all this information long before the back-end ever gets
> called.

Hmm, that would be verry sad. Can I have a statement from our
ooc-specialists about that?

> I think they're saying that their product complements the Java
> stuff.  It doesn't sound like they are trying to compete.  OTOH
> they do show comparisons of their product with Java -- which, with
> the current JIT compilers end up looking worse and worse all the
> time.  So, it seems they are a bit confused about what they want
> to do with slim binaries.

I think its dead if view as alternative form of applets. With their
minimal interface to the GUI they can do nothing to astonish anybody.
Drawing some lines isn't enough. They need some GUI. Of cause they could
use VisualOberon for it, after looking at it it maybe possible when the
would enhance their API a little bit (Windosing stuff, events...) <smile>.
And its seems to be dead as concerned Juice been a firm, a commercial
product and publicity thing since there is no progress on they webpage since
more than a year. Of cause there is now support for slim binaries for Mac
and Windows but it is tied to System-3 which is nice but wouldn't make
anybody use it.

> I want Oberon-3.  Sort of like Component Pascal except with the
> extensions that I like.  :-)

We want that all I think. Its likely that everybody on this list has some
wishes and ideas. But we must realize that the oberon community is *very*
small (or they constist of a huge number of people that do not communicate
with the rest of the world). Designing somekind of Oberon-3 maybe split
that community even more. Only chance would be to get ETH or Linz to
powerfully support Oberon-3 or have a huge number of nice tools and
libraries in the back which make jump everybody on the train... But in
both cases Oberon-2 compability is a must.

> Well mainstream when compared to the other Oberon Systems which
> are free and therefore have no sales at all.  Is there a reason
> you stopped using it?

Yes, give us your opinion...

-- 
Gru...
       Tim.