Re: Embeddable and Extensible Languages

"PlayDough" <petela@gocougs.wsu.edu>
15 Jan 2005 20:56:35 -0500

          From comp.compilers

Related articles
Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-12)
Re: Embeddable and Extensible Languages jm@bourguet.org (Jean-Marc Bourguet) (2005-01-14)
Re: Embeddable and Extensible Languages petasis@iit.demokritos.gr (Georgios Petasis) (2005-01-14)
Re: Embeddable and Extensible Languages lhf@csgpwr1.uwaterloo.ca (2005-01-14)
Re: Embeddable and Extensible Languages Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2005-01-14)
Re: Embeddable and Extensible Languages thant@acm.org (Thant Tessman) (2005-01-14)
Re: Embeddable and Extensible Languages hombre@gmail.com (Tom Verbeure) (2005-01-15)
Re: Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-15)
Re: Embeddable and Extensible Languages kenrose@tfb.com (Ken Rose) (2005-01-15)
Re: Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-15)
Re: Embeddable and Extensible Languages thant@acm.org (Thant Tessman) (2005-01-22)
Re: Embeddable and Extensible Languages jc.lelann@wanadoo.fr (Jean-Christophe Le Lann) (2005-01-22)
Re: Embeddable and Extensible Languages gneuner2@comcast.net (George Neuner) (2005-01-24)
Re: Embeddable and Extensible Languages petela@gocougs.wsu.edu (PlayDough) (2005-01-25)
[3 later articles]
| List of all articles for this month |

From: "PlayDough" <petela@gocougs.wsu.edu>
Newsgroups: comp.compilers
Date: 15 Jan 2005 20:56:35 -0500
Organization: http://groups.google.com
References: 05-01-04005-01-044
Keywords: interpreter

[ several related messages combined here -John]


Georgios Petasis wrote:
> It seems odd that you haven't look Tcl (http://www.tcl.tk). For me
> its by far the most advanced language when it comes to portability &
> maturity of code (stable, easy to understand & extend).


I did look at Tcl, as well as several others, but it's more of a syntax
issue there. Even as much work as I've done in the EDA land and their
love of Tcl, I'm still forced to frequent a Tcl manual to figure out
syntax. Also, our internal customers have been using GUI based
simulation and hand-writing force files, then verifying functionality
visually. Automated testbenches are not common, and my attempt is to
make it automated. As such, Tcl is quite likely to be unfamiliar as
well.


Thanks for the suggestion.


[ next message ]


Jean-Marc Bourguet wrote:


> Another language you didn't name but which seems to have a
> signigicant user base is Ruby.


I don't know why I didn't look at Ruby. I've used it in the past, but
I completely forgot about it here. I'll be sure to look into it more.
Thanks for the suggestion!


[ next message ]


Luiz Henrique de Figueiredo wrote:
> PlayDough <petela@gocougs.wsu.edu> wrote:
> >So far, I've narrowed it down to Lua and Python. [...]
> >Both have the problem of not being capable of running
> >multiple contexts (outside of the interpreter).


> I'm not sure what you mean by the last sentence, but Lua can run
> multiple independent states and multiple related states, with
> support for coroutines.


I just perused the manual, and you are correct. I misstated the issue
with Lua that I was having.


The system I'm creating uses SystemC. (I over-generalized earlier by
saying FLI/PLI, thinking it wasn't important. Turns out it is quite
relavent to the problem.) The SystemC implementation I am using
requires that I put the Lua state as a member of the class. When
extending Lua, I need to get a pointer to the state. However,
callbacks from the Lua interpreter must be implemented as static
member functions, so "this" doesn't exist and I can't get a pointer to
the state (required to gather passed parameters and to return values).
I can use userdata, but the amount of userdata is limited, and I want
the system to be as expandable as possible.


Further discussion of this issue belongs on a Lua (or related)
newsgroup, and I will post there to try and resolve this issue.


Thanks for the information,
Pete





Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.