lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



I'd be extremely cautious on these waters.  One warning example I've faced (sorry if this hurts someone, but it's true...) is the Real Player's codebase (and Rhapsody build tool, made in Python) which simply allows _everything_ to be configured, leading to:
- everything _must_ be configured
- only certain configurations really work (you pick your own, most likely it won't compile...)

What I'd rather want is Lua authors to allow for a bit more #if-else's within the code, allowing for features to be activated/disabled by premade defines. But also there, it boils down to testability: each option is going to double the amount of testing required.

The Linux kernel is another, better example, where configuration mismatches are actually documented in the configuration tool. But: do we really, really need to go that way?  Doesn't the nowadays patching culture suffice?

-asko


Joseph Stewart kirjoitti 2.3.2006 kello 17.00:

Hello all,

There have been several threads here lately that have "tickled my brain" to think about a possibly better way to build Lua.

Chris' recent thread about "inline Lua" along with my experiments to add a datatype and another lexical element to Lua have me thinking that we might benefit from embedding the source code of Lua into one or more Lua-script(s) which generate C-code and Makefiles.

Is this complete heresy? Maybe I've been reading too many Lisp papers lately, but I have a sneaking feeling that we could better "parameter-ize" Lua this way than the typical #ifdef method (while kudos certainly go to the authors for keeping a MUCH cleaner code-base that most OSS projects).

I'm not sure I'd take the same approach, but here's a link to a paper that demonstates a "syntax-driven C preprocessor" http://swtch.com/gosling89ace.pdf.

This paper shows a preprocessor that "understands C" and implements "ace" which is a rule-based system that "operates on syntax trees".

My approach would be to embed chunks of "C" in Lua strings that are selectively concatenated into one or more real C files and a simple Makefile.

If there's any interest at all, I'll take a first-cut at morphing the Lua 5.1 code-base into this model. My first prototype would include asimple syntax modification to support Erlang-style arbitrary base constants ( i.e. 2#1000 means "the base two constant 1000" or 8) as an add-on to demonstrate the process of including a syntax change.

I humbly ask this community to let me know if I'm philosophically way off to even start down this path.

-joe