Re: [F-Script-talk] Porting FScript to other O.S.: some questions

[Philippe M. <pm...@ac...>]

Le 25 ao=FBt 06 =E0 09:38, Giovanni Giorgi a =E9crit :

> FSCompiler.m is used to generate byte code?
> So FScript has also byte-code interpretation?!

FSCompiler does not generates byte-code per se, but a tree-based =20
structure that represent the parsed F-Script code. It's our =20
intermediate, optimized, code representation. We then feed the =20
interpreter with this structure.

> How can be difficult to make FScript multi-platform?
> For instance,  If we can have a stripped down version of FScript =20
> written in Java or C++, we can spread it also on Linux and Windows.
> It needn't to offer the same feature. Even the simple interpreter =20
> with a Plugin Architecture to extend it would be a strong starting =20
> point.
> What do you think?

I would be happy to see F-Script for Java or F-Script for .NET, for =20
example.

However, as other have said, you can't take F-Script as-is and =20
somewhat modify it to make it multi-platform, because one of its main =20=

point is to use a preexisting object model (this contributes to its =20
small footprint: it reuse a lot of the existing infrastructure). The =20
current implementation, for instance, does not have a layer of =20
abstraction that reduce adherence to the underlying object model. On =20
the contrary, it tries to integrate as deeply and closely as possible =20=

with it. So you would have to re-design and re-code it specifically =20
around another object model.

For scripting the Mac OS X object model, F-Script is the obvious =20
choice because Objective-C is itself based on Smalltalk in many ways. =20=

For Java, we would give-up some important synergies (for instance =20
Java methods are not keyword-based) but it still might be cool. Java =20
is relatively weak at supporting dynamic languages but this is going =20
to change with the introduction of the invokedynamic bytecode in the =20
next JVM and the potential introduction of hotswapping (the ability =20
to modify classes at run-time) in Java 7.
Anyway, to get back at your question, having a version of F-Script =20
for Java or any other object model would be a lot of work.

Currently the scripting languages for java that seem to be the most =20
promising are JavaScript (a complete implementation, bridged with =20
java and using the standard embedding API specified by the JSR 223 is =20=

going to be included in Java 6), Groovy, and BeanShell. I know that =20
people in charge of Java at SUN see JavaScript as having a big =20
potential to become a major general purpose scripting language for =20
the Java platform. On the other hand, Groovy has the huge advantage =20
to be based on the native Java object model, like F-Script is based =20
on the native Objective-C object model. But I would not be surprised =20
to see SUN aiming at somewhat creating a JavaScript implementation =20
based on the future Java object model (with hotswapping and al.). On =20
the Smalltalk-for-Java front, there are some interesting project like =20=

Bistro and SmalltalkJVM.

Best,

Philippe