On Monday 07 November 2005 18:14, Javier Martinez wrote:
> Hi Marco,
>
> > Yes, but if someone doesn't need it, he can just ignore it.
> >
> > One possible solution could be to selective enable the preprocessor
> > support when running the "configure" script, if called with an
> > "--enable-cpp" switch. What do you think about this?
>
> Yes, but what about sharing code? These macro functions will make JAL
> "other" language (JAL-cpp vs JAL), that is you'll not able to share code
> with other "not-cpp" jallians. Should be nice to find a solution
> affordable for all, rather than for a few ones.
>
> And yes, the best way to enable it is in configure script.

You are right, it would impede code sharing. I think of this feature as a
"sharp knife", to be used exclusively when unavoidable, but I understand that
once users have access to a tool they tend to use it :-)

> > > The second one, just a thought: looks like C too much, is there a
> > > way to "JALify" it? I'm thinking in something like a procedure/function
> > > syntax: "macro ( ) is ... end macro".
> >
> > This of course would be the best solution, but I suspect it would require
> > non-trivial changes to the parser. If jal could parse from a string
> > (starting from an arbitrary point in the original file, and resuming to
> > the same itpoint afterwards), it would be quite easy to do, but I doubt
> > it has this functionality.
> > I'll try to think if I can envision a solution, but someone with a deeper
> > understanding than mine of the jal parser could give better indications.
> >
> > Ciao,
> > Marco
>
> Let's go with my first question, and then if all it's ok will find
> a solution here.

I'd go for the JAL-style solution, but I'd need some help here.

Later,
Marco

--
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org