Re: [Wesnoth-dev] Changing the WML include file syntax.
On Thu, May 24, 2007 at 04:56:08PM -0400, esr wrote: That is the fact that zero-argument macro references and file inclusions are syntactically indistinguishable Definitely a headache as it is now, and a net win to change it. -- [EMAIL PROTECTED] ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing the WML include file syntax.
On Thu, May 24, 2007 at 11:20:17PM +0200, Benoit wrote:
The problem i see with #include is it is less powerful that our current
system.
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).
Sounds good to me.
-- [EMAIL PROTECTED]
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing the WML include file syntax.
On Thu, May 24, 2007 at 16:56:08 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: 1. We implement #include, just as in the C preprocessor and for consistency with the existing C=like #ifdef/#else/#endif. Are you going to fix up including directories some way at the same time? This would probably be an opportune time to make changes in that regard, since all of the includes will be being changed. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing the WML include file syntax.
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
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing the WML include file syntax.
Bruno Wolff III [EMAIL PROTECTED]: Are you going to fix up including directories some way at the same time? This would probably be an opportune time to make changes in that regard, since all of the includes will be being changed. Only if it's a change that can be made nechanically by wmllint. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing the WML include file syntax.
[EMAIL PROTECTED] [EMAIL PROTECTED]:
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).
Can you point me at some of these non-map use cases?
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...
It's possible. But it's also possible that file inclusions in mid-line
are something we shouldn't be doing, or can be more cleanly handled in
a different way. I'm supicious of this 'feature'; like C macros,
it invites all kinds of hard-to-debug abuses -- for example, when
an included file isn't a balanced syntactic unit.
--
a href=http://www.catb.org/~esr/;Eric S. Raymond/a
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing the WML include file syntax.
On Thu, May 24, 2007 at 06:58:34PM -0400, Eric S. Raymond wrote:
[EMAIL PROTECTED] [EMAIL PROTECTED]:
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).
Can you point me at some of these non-map use cases?
- (still a map use, but not directy connected with map WML) : store a map in a
WML variable (most likely an array)
- inclusion of a list of racial names instead of defining a macro for this
- inclusion of a (large) text file inside a [story] statement
- use of a recruit list defined in a file
- more general: inclusion of a text file inside a WML variable
(the preprocessor is the only way for WML to use some data stored in a text
file)
Btw #include (or any other solution) should be able to handle some complex
cases:
i sometimes use some macro like this :
#define MACRO FILENAME
# some WML code
{{FILENAME}}
#enddef
{{FILENAME}} would be replaced by #include {FILENAME}
Would this still work ?
Or one even more complex real example :
#define MP_SIDE ERA FACTION
[EMAIL PROTECTED]/Extended_Era/factions/{FACTION}-{ERA}.cfg}
#enddef
Would this still work ?
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing the WML include file syntax.
Indeed I support the basic idea of differentiate file and macro. As a coder,
I also like the #include but as it was said you will lose power.
It's possible. But it's also possible that file inclusions in mid-line
are something we shouldn't be doing, or can be more cleanly handled in
a different way. I'm suspicious of this 'feature'; like C macros,
it invites all kinds of hard-to-debug abuses -- for example, when
an included file isn't a balanced syntactic unit.
I think that you can't prevent this. If I want to do it, I just use your
#include file.cfg define a macro in it and use it in mid-line. This a
macro system with all its good and bad things. I suppose that I'm not the
only one who consider that a cfg file is implicitly the declaration of a big
macro with the name of the file.
But I don't like using special character like {%file.cfg}. There is enough
WML complexity to don't add an other special thing for the normal include
of a file. So I propose to simply use {file.cfg} and detect the .cfg
extension to see if it's a file or a macro.
- it's very human/WML noob readable.
- it implicitly enforce the rule to use cfg extension.
- but you can also use it to detect *.map or other future filetypes and
react accordingly
If you want to declare a directory just detect the final / in{directory/}
or maybe use {directory/*.cfg}. And yes, I know, this idea to use the file
extension to decide what to do is not very original (maybe even copyrighted
by M$ ;), but again I think it's best to use the same file tricks as OS do.
Alink
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
