Re: Scripting in Gnome

[Sean Middleditch <elanthis awesomeplay com>]

On Tue, 2004-02-03 at 14:28, jamie wrote:

> Bear in mind I am cross compiling into python code not machine code - i
> realise the task of creating an interpreter from scratch is hard work
> and it would take me years to do it that way. Cross compiling is
> relatively easy using a recursive decent parser and is simply a
> translation operation rather than low level code generation.

a) coverting to python is no easier; probably harder, when you realize
you have to try to map language semantics to something that isn't even
remotely compatible
b) low-level code generation isn't hard at all.  it took me a day to
write the code generator for Scriptix.  the hard part is putting in all
the extra features a real language needs, which Python at least does
solve for you.
c) all you're doing is solving the syntax problem.  i.e., converting "if
(x == 3) { blah(x); }" to "if x == 3: blah(x)"  Unfortunately, every
language (including VB) has a hell of a lot more to it than the syntax -
how do you plan on mapping the various system/function calls?  exception
names?  modules/packages?  the different features inherent in varied
types between the two languages?  etc.  a VB interpreter that only
handles the syntax but not the rest of the language peculiarities isn't
going to be very useful.
d) have you looked at gnome-basic to see if you can reuse their code? 
they also, iirc, have a write-up on why they abandoned conversion to
Python and started work on a native interpreter.

> 
> The only problem with using Python is the dependancy issue and that
> might prevent my script engine from being adopted by core gnome apps but
> thats a compromise I'm going to have to accept.

Python is common in almost all user systems.  So are the vast majority
of other popular scripting/programming languages.  You're obsessing over
this theoretical "dependency" problem.  ;-)

> 
> 
> > So, explaining how you will make translation work by saying "I'll use
> > XML" seems like a bit of a non sequitur, and makes it seem like you
> > might be underestimating the difficulty of this problem.
> 
> Its not that difficult as such. I have used coco/r before (using the
> delphi version) and it creates recursive descent parsers with ease.
> Coco/r has a nice file layout and my xml file will try and utilise as
> much of that layout as possible. Admittedly coco/r is not available on
> python though there is something called TGP which I am looking into. If
> thats not usable then I can write my own
> 
> The real difficulties that I forsee are dealing with quirky language
> features like VBA's error handling or GOTO statements and how to
> translate them into equivalent python as specified by an xml file.

Yes, those will be difficult all right.  Again, when you get down to it,
you are trying to map a language with certain features to an engine
which flat-out doesn't support some of those features.  Some thing can
be worked around (i.e., you could map exceptions around and such), but
others will be very very difficult if not impossible entirely (like GOTO
statement).

You might also take a look at Parrot, and see if generating Parrot
bytecodes would allow you to make a more complete and usable VB engine
than using a core specialized to a particular language/dialect.

In any event, I think this is getting a bit off topic; we're talking
about language development and not the desktop anymore.  ~,^

> 
> jamie
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.