Re: Scripting in Gnome

[jamie <jamiemcc blueyonder co uk>]

On Tue, 2004-02-03 at 19:48, Sean Middleditch wrote:

> 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.

Thats one of the reasons we have an xml file so extra mappings can be
added on as needed. EG VBA has say the Left$ string function that can be
specified in the xml file against a chunk of python code to do the
equivalent. There are no exception names in vba. Modules/packages
generally are not used in vba but again this extensibility is provided
for. External calls could be made to com objects or even the windows api
(which is very rare) so there will be some limits anyhow. Generally we
are dealing with a macro language vba not the enitre infrastructure of
VB (the latest version of vba admittedly has approached full vb
functionality). The reason I chose to do this is because we are dealing
with simple macro languages. I intend to support the core functionality
and the most commonly used routines - others can add on extra support by
modifying the xml as needed. 

>   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.
> 

That was designed for the full vb language - I'm just implementing a
subset for vba.

> > 
> > 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
Until the core gnome distribution has python as a dependancy then I have
to disagree with you. I do hope your right of course. The reason I want
to use python is because it is so common. - hoepfully in time you will
be proved right.


> > 
> > 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).

I thought of creating a function around goto code to solve that bit so a
goto labelname would simply call a function instead.
> 
> 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.

I will if the python route fails.

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

apologises for that though it is a desktop wide scripting engine

> .
> > 
> > jamie
> > 
> > _______________________________________________
> > desktop-devel-list mailing list
> > desktop-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list