On Sun, 25 Jan 1998, Ned Freed wrote:
The problem lies in how "support" affects the way the language is used. People
will use the presence of "support" to justify all sorts of extensions. These
extensions will then be used willy-nilly, and they will be used *without*
support tests being made. We will then end up with massive interoperability
problems.
Your argument hinges on the assumption that people will not write all
sorts of extensions unless "support" (done as a test or as a macro or
whatever) is available. I disagree; I think people will write extensions
anyway.
Removing support will not stop people from writing extensions and from
writing code that uses those extensions (requiring everyone who wants to
be interoperable to support the common extensions). The only thing
removing support will do is prevent people who'd like to be able to write
portable code and still take advantage of extensions from being able to do
so.
You are recreating the PostScript situation here. Nothing more and nothing
less.
Removing "support" will not help avoid this.
The only solution I can think of, actually, requires "support": forbid
servers from permitting extensions to be used unless the existance of the
extension has been tested as a condition for entering the block of code in
which the extension occurs. So,
if (support "vacation") {
vacation;
}
would be legal;
vacation;
occuring on its own, outside of a block wrapped with a "support" test,
would be forbidden.
(At that point, it'd probably be much simpler for implementors if
"support" were its own control structure with a required "else" clause,
giving us something like
ifsupport "vacation" {
vacation "I'm on vacation";
} else {
reply "I'm on vacation";
}
)
It's kind of a gross idea, but it's the only way that comes to mind to
*make* script writers do feature tests before using features.
I have no problem with facilities that discover the abilities of a given
server
and then write scripts in accordance with those abilities. I do not, however,
think this justifies having a "support" language construct so that scripts can
be generated with conditionals around code that some servers don't understand.
I'd like to be able to generate scripts without any knowledge of which
extensions the server supports; discovering the list of extensions is
another level of complexity, and prevents the generated scripts from
taking advantage of new extensions as they're introduced to old
interpreters.
The reason this multiple parser argument is a strawman is that many if not
most
extensions will simply add functional forms to the language, not control
structures.
That still involves parsing (you could have a general lexical analysis
module for the plugin parsers to call, but the extension modules will
still be able to do whatever parsing they want). If most extensions will
simply add functional forms, why not just hand them a parse tree to
manipulate?
Frankly, I don't _want_ to expose the ability to add control
structures via plugins in my implementation.
Reasonable. :-)
)Rob