Re: Small embeddable scripting language ?

[John Palmieri <johnp martianrock com>]

On Fri, 2002-11-29 at 00:13, Biswapesh Chattopadhyay wrote:
> On Fri, 2002-11-29 at 11:23, John Palmieri wrote:
> > 
> > 
> > 
> > > 3) As an embedded template language for code snippets and file and
> > > project wizards. For example, you might want to add a code snippet for a
> > > standard C header file:
> > > -----------------
> > > /*
> > > ** File name <%=echo $file_name%>
> > > ** Copyright <%=echo $current_year%> <%=echo $author_name%>
> > > */
> > >
> > > #ifndef <%=echo upper(canonical($file_name))%>
> > > #define <%=echo upper(canonical(file_name))%>
> > > ....
> > >
> > > #endif /* <%=echo upper(canonical($file_name))%> */
> > > -------------------
> > 
> > I just wanted to give you some thought on this part of your plan.  I am
> > working on GObject Factory a GObject code generator that I eventualy
> > plan to integrate into Anjuta 2.  I have recently moved to a template
> > engine instead of generating everthing in C.  I found that XSLT provided
> > by libxslt works well for this type of thing and is easy to setup and
> > debug the templates with command line tools.
> > 
> > The drawbacks with XSLT is that it can get verbose and it doesn't have
> > very good tools for doing things like changing strings from uppercase to
> > lowercase (at least none that I have found in the documentation).  I got
> > around this by doing the case changes in the C code.
> 
> That will be problematic - I want the wizard system to be scriptable
> without compilation headaches. Besides, plain text with embedded code
> bits is much simpler to lean IMO.

It could be done in Python (or any scripting language that has GTK
bindings) instead of C.  In theory template languages are better used on
the template and scripting languages used outside the template.  The
truth is I don't think having a generic wizard library, where all the
programmer would have to do is add a glade file and a template, would be
useful.  I found out that recursive things like gathering parameters
whould be hard to do without using C or Python to guide the wizard.  The
better way to do this is have a standard way of implementing Wizards in
Anjuta, document this and provide a simple example people could build on
(have a wizard for developing Anjuta wizards :-).
> 
> > 
> > The benefit of XSLT is that it is easy to use, is a defined standard by
> > the XML working group and would save you the trouble of coming up with
> > another template system.  It literally took me 1/2 hour to learn and it
> > is already part of the GNOME libraries.
> 
> Seems promising. But can it call code snippets inside ? A full fledged
> wizard will need stuff like looping, conditions, powerful text
> manipulation functions, etc. inside the template which I felt can only
> be achieved with a normal language. For example, an XSLT call a python
> code snippet when it encounters a certain tag with the value of the tag
> ?
Not quite code snipets.  You can create named templates that can be
called from within other templates.  They have a notion of variables and
parameters and recursion can be done.  There are also some simple
functions that can be used to do various things but they are not that
powerful. Looping is easy and in fact everything works on lists.  For
example my wizard output looks something like this:

<GObjectFactory>
	<general>
		<name>
			<obj>TestObj</obj>
			<func>test_obj</func>
			<macro>TEST_OBJ</func>
		<name>
	</general>
	<methods>
		<method>
			<name>hello</name>
			<type>gchar *</type>
		</method>
		<method>
			<name>world</name>
			<type>gchar *</name>
		</method>
	</methods>
</GObjectFactory>

I could have a template like this to display all methods like this:

<xsl:template name="print_method_prototypes">
	<xsl:for-each select="/GObjectFactory/methods/method">
		<xsl:copy-of select="/GObjectFactory/name/func" />_<xsl:copy-of
select="type" /> <xsl:copy-of select="name" /> (void);
	</xsl:for-each>
</xsl:template>

<xsl:template select="/GObjectFactory">
	<xsl:call-template name="print_method_prototypes" />
</xsl:template>

There are condition elements much like the for-each element.  Also
common libraries of named templates can be made available for template
makers.  XSL is extensible also if you would need more functionality but
this is the way I see a template working:

Glade + python/perl/c code -> gets user input -> generates XML from
users input which can be saved for futher processing in other tools
(creating dia documents come to mind) -> xml is sent to XSLT processor
-> one large file is returned with unique delimiters to seperate actual
files; these delimiters can contain instructions on how to add file to
the current project or to create a new one -> files are split up and
saved in the propper locations.

When I get to the point that I want to integrate GObjectFactory into
Anjuta 2 you will have a nice example of what I am trying to explain.

--
J5

> > 
> > I don't want to give you more languages to learn ;-) but it is just a
> > thought.
> 
> That's fine - a new language a day keeps boredom away ;-)
> 
> Rgds,
> Biswa.
> 
> > 
> > --
> > J5
> > 
> > 
>