On Thu, May 24, 2007 at 04:56:08PM -0400, Eric S. Raymond wrote:
> I enjoy special-purpose languages and language-like markups. I have a
> great deal of experience at designing, implementing, and evaluating
> such things. Accordingly, there's a a lot of stuff about design
> principles and pragmatics for language-like markups in my last book,
> "The Art of Unix Programming".
>
> So I've been looking at the design of WML with a critical and
> analytical eye. Mostly the news is good; the language seems clean,
> expressive with its domain, and well-suited to its purpose. I find
> this all the more impressive since the record makes it quite clear
> that the language has grown by accretion morte than by conscious
> design-ahead.
>
> However, there is one glaring exception, one thing about WML
> that made me go "Bletch!" first time I saw it -- and my loathing
> for it has only increased since.
>
> That is the fact that zero-argument macro references and file
> inclusions are syntactically indistinguishable -- {foo} can
> mean either "call the macro 'foo'" or "include the file named
> 'data/foo'"; the preprocessor tries both at runtime in an order
> I can't keep straight (which is a symnptom of how confusing this
> design is).
>
> Spurious messages due to macros being interpreted as filenames
> (or vice-versa, it make my head hurt to try to keep track) have
> been impeding our efforts to fix the filesystem port bugs.
>
> Therefore I say let's shoot this misfeature through the head *now*.
> I have support from (at least) alink, allefant, and ivanovic on this.
>
> I propose the following new rules:
>
> 1. We implement "#include", just as in the C preprocessor and
> for consistency with the existing C=like #ifdef/#else/#endif.
>
> 2. Once #include is implemented, {} is reserved for macro calls. It
> will no longer bracket file inclusions under any circumstances.
>
> 3. wmllint will convert any {}-reference to a string beginning with s
> lowercase letter occurring on a line by its own to an #include.
>
> 4. A call to an undefined macro will become a fatal error. An attempt
> to include a file that can't be found will likewise become a fatal error.
>
> 5. To handle the mapdata="{foo.map}" case, we introduce a new tag map=
> that includes map files by name reference, so the above can be
> rewritten as map="foo.map".
> --
The problem i see with #include is it is less powerful that our current system.
With current system we can include any file we want in a middle of a line,
which might not be possible with #include.
mapdata="{foo.map}" is only the most usual case, but there a lot of others (i
remeber i already used it for terrain masks, the random terrain generation
part of a scenario (which was shared with some other scenarios).
I have an alternate suggestion :
- change current file inclusion to {%filename} instead of {filename} (that
will be disallowed) (or use any other character that would not be permitted in
a macro name).
This should allow macro calls an file inclusion to be different and the file
inclusion won't loose in power...
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
