Re: Thoughts on an alternative Lua build environment.

["Joseph Stewart" <joseph.stewart@...>]

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

Thanks for the thoughts. Your comments brought back memories of when I
used emacs for the first time... I despised the control/meta/shift
finger gymnastics I had to do so proceeded to make my own keymap using
all the function keys, page-up/dn, etc... only to realize that I'd
have to re-create the setup on every machine. I certainly wouldn't
want to fragment the codebase or allow people to make vastly
incompatible versions of lua (from a lua-source standpoint at least).

My thoughts about this came up during my last lua mod. I had to change
several things in several places and worried about keeping the pieces
in sync with one-another. I'd remembered reading Knuth's comments
about literate programming where he said something like "the order in
which we describe code to the compiler isn't always the way we would
describe the code to another person".

Perhaps a wiki note on how to add types or modify the lexer would be
more useful (perhaps it already exists)?

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

Having spent more time than anyone should elbow-deep in kernel code, I
certainly wouldn't want to create a mess like that (no offense to
fellow-linux-lovers... no flames please).

> -asko

Let me think about this more before proceeding. I would want to
simplify the codebase rather than complicating it. And to be honest,
writing a Lua script that generates the C source code for Lua just
sounds cool (has anyone written Lua in Lua before?)... but perhaps not
practical or useful ;-).

-joe

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