what about Arexx in OS4 ?

It has come to my attention that Hyperion is going to replace Arexx by phaseing it out for Python as the scripting language... who owns the rights to Arexx? I know MorphOS  has to do a cleanroom on this one... but what will Hyperion do?... if they cant use Arexx and they need to use Python wont that make most of the apps not work?... now I'm pretty ignorant on this subject... I would like to hear what Rogue and others have to say... I might be totally off base here and apologise if I am...

[Alkemyst]

The 68k version of Arexx will be used for programs that need it new apps should use Python, just like MUI will be included for program that need it, new apps will use the new Reaction.

Well thats the plan i think.

[Targhan]

ImageFX uses ARexx extensively.  Now to have the full speed of PPC as possible, Nova Design will have to rewrite 10 years worth of ARexx in Python?!!?
 

thats the way I understand it although I could be totally off base here...dont jump to any conclusions based on what I've said... I've heard that though... I'd like to hear hyperion tell it there way though...

[alx]

Wasn't SHEEP going to replace Arexx?

[EntilZha]

ARexx will be included, but as 68k binary.

The thing with Python has been an idea for later, nothing more. The idea has changed, in the meantime. What we want to do (after 4.0) is a language-independant scripting host that can interface to different languages, including Rexx and Python.

[Rogue]

Yes, AREXX is going to be replaced - or rather, AREXX will stay in its current form, and a new scripting language will be brought in.

This is not only because of ownership considerations. There are other things, mostly the fact that the AREXX implementation is very sensitive with its internal data structures which are accessed by some function located in linker libraries - meaning that any change in internal structures will break the whole thing.

As such, AREXX will stay for backwards compatibility but people are encouraged to use something new - most likely Python, but we are looking at other alternatives.

[downix]

Including the 68k ARexx?  Do you have a license for that?  

Remember, ARexx was a 3rd party add-on for AmigaOS that was licensed
by Commodore.  As such, it is not legal to include unless you have
negotiated a new license with it's author.

What about Regina?

http://regina-rexx.sourceforge.net/

[EntilZha]

> What about Regina?

There's an inherent problem with replacing ARexx: amiga.lib makes assumptions about the internal  data structures of ARexx. And unfortunately, amiga.lib is statically linked into the binaries.

Bottom line, it's not possible to just take another Rexx implementation. Therefore, we rely on emulation for now and take some more time to review the issue in one of the future versions...

[Warface]

Thanks for the answers and the insight for the Hyperion guys. :-)

[wonea]

AROS will have Arexx soon!

[xeron]

Yeah, its great that the Hyperion guys are here to post about these things  :-D

@Rogue or EntilZha
Purely out of interest, I note that the new library system can present different interfaces to 68k and PPC programs. Would it not have been possible to take a similar approach, and present the original ARexx runtime to emulated applications, and (for example) a regina based runtime to PPC applications? (I'm not saying thats what you should have done; just curious)

Bottom line, it's not possible to just take another Rexx implementation. Therefore, we rely on emulation for now and take some more time to review the issue in one of the future versions...

Thanks for replying, it's much appreciated.

[Rogue]

Would it not have been possible to take a similar approach, and present the original ARexx runtime to emulated applications, and (for example) a regina based runtime to PPC applications? (I'm not saying thats what you should have done; just curious)

The major problem with AREXX is the way that internal data structures are handled. The interpretation of the commands itself isn't a problem. Bringing in Regina only takes care of the pure interpretation of commands. It doesn't solve the way that the interprocess communication works.