f-script-talk

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

[Giovanni G. <dai...@gm...>]

Hi!
I have found FScript very nice for a bunch of reasons:

   - It is quite compact, in respect also to tiny Smalltalks  like GNU
   Smalltalk and PocketSmalltalk. It is uncommon to find such compact things in
   SmallTalk land.
   - It has interesting feature like sending message to arrays in one
   instruction
   - Very easy to extend via the Cocoa Framework.
   - Open Source

I have searched a "smaller" SmallTalk in the last few years but without so
much success.

I have counted between 43000 and 60000 lines of code.
The Core Objective C part is 43000 lines

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

How can be difficult to make FScript multi-platform?
For instance,  If we can have a stripped down version of FScript 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 with a
Plugin Architecture to extend it would be a strong starting point.
What do you think?




-- 
Software Architect
http://www.objectsroot.com/
Software is nothing

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

[Nathan S. <nat...@jp...>]

On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
>
> How can be difficult to make FScript multi-platform?
> For instance,  If we can have a stripped down version of FScript  
> 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  
> with a Plugin Architecture to extend it would be a strong starting  
> point.
> What do you think?
>

Wouldn't GNUStep make more sense?

-N

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

[Giovanni G. <jj...@ob...>]

On 25/ago/06, at 17:47, Nathan Strange wrote:

>
> On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
>>
>> How can be difficult to make FScript multi-platform?
>> For instance,  If we can have a stripped down version of FScript
>> 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
>> with a Plugin Architecture to extend it would be a strong starting
>> point.
>> What do you think?
>>
>
> Wouldn't GNUStep make more sense?
GNUStep is a objective C port of NextStep?
Mmmh I don't know it at all and I fear cannot be ported easily to  
Windows.
Java  seems more easy to use as target language.

-- 
    [   [  [ JJ ]  ]   ]  | http://www.squeak.org
                          |
http://www.siforge.org   |

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

[Nathan S. <nat...@jp...>]

On Aug 25, 2006, at 12:01 PM, Giovanni Giorgi wrote:

>
> On 25/ago/06, at 17:47, Nathan Strange wrote:
>
>>
>> On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
>>>
>>> How can be difficult to make FScript multi-platform?
>>> For instance,  If we can have a stripped down version of FScript
>>> 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
>>> with a Plugin Architecture to extend it would be a strong starting
>>> point.
>>> What do you think?
>>>
>>
>> Wouldn't GNUStep make more sense?
> GNUStep is a objective C port of NextStep?
> Mmmh I don't know it at all and I fear cannot be ported easily to
> Windows.
> Java  seems more easy to use as target language.

There is GNUStep for windows... don't know how complete it is though.

But F-script is written in Objective-C and it seems like a lot of  
work to re-write it in Java...  especially since Java may not support  
all of the Objective-C features used by F-script.

-Nathan

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

[Todd B. <tbl...@ma...>]

On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
> How can be difficult to make FScript multi-platform?

About as hard has making GNUStep multiplatform.

> For instance,  If we can have a stripped down version of FScript  
> 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  
> with a Plugin Architecture to extend it would be a strong starting  
> point.
> What do you think?

FScript relies VERY heavily on the ObjectiveC runtime.  Without that,  
I don't think porting is a reasonable option.

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

[Giovanni G. <dai...@gm...>]

I think can be userful a re-implementation of FScript too.
There are plenty of language implemented in Java (jython, beanshell,
ecmascript, jruby, groovy and more recently some experiments of
Ingalls with Smalltalk).
Having a minimal implementation of FScript in Java would be a good
starting point.

We can use reflection to get seamless integration (like BeansShell
does) at least at Java Level.

A better starting point could be GNU Smalltalk o Squeak, but they
relay heavily on big startup images and this is not good for a
scripting language as I intend them.

Even Python is a good candidate in my humble opinion, because of its
huge support.

Ruby had a very small standard library and it is not suitable,
altrought it is very dinamically oriented and has unique feature.

I have seen the GNUStep site, but Windows support is lacking a lot,
and seems strong focused on Linux (even MacOSX support is
sub-optimal).

Who can be interested in such a port in your own opinion?
There are some users asking for a Fscript-like-version on Linux or Windooze?
Ciao ciao ;)


On 8/25/06, Todd Blanchard <tbl...@ma...> wrote:
>
> On Aug 25, 2006, at 12:38 AM, Giovanni Giorgi wrote:
> > How can be difficult to make FScript multi-platform?
>
> About as hard has making GNUStep multiplatform.
>
[...]
>
> FScript relies VERY heavily on the ObjectiveC runtime.  Without that,
> I don't think porting is a reasonable option.
>
[...]

-- 
Software Architect
http://www.objectsroot.com/
Software is nothing

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

[stephen w. <st...@ad...>]

On 29/08/2006, at 4:58 PM, Giovanni Giorgi wrote:
> We can use reflection to get seamless integration (like BeansShell
> does) at least at Java Level.

It sounds like you're looking for a language, not F-Script in  
particular.

F-Script is defined by Cocoa first and foremost, then the Array  
aspects, and finally as a Smalltalk dialect. So to truly port F- 
Script, you would need to port Cocoa as well.

The cleanest way to achieve this is to improve the support for  
GNUstep on Windows (which isn't very good - aka, an opportunity for  
you to help!), then port to that environment with Objective C.

Java's really not in the picture at all, unless you want to clone F- 
Script rather than port it.

--
   st...@ad...

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