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.
Not at all. It isn't a question of what people do but how they do it. I don't
care if lots of people write extensions. I do care if people expect them all to
work universally. And this is the license that a inline support test
effectively gives to implementors. Its presence will result in it not being
used properly. This isn't logical, but it is nevertheless the lesseon learned
from other languages that used this approach.
Note that I have no problem with having a series of support tests at the time
of script submission which have to pass or else the script won't be accepted. I
don't even have a problem with phrasing this as part of the "language", if
that's how people want it to work. This sort of "in your face" rejection will
have the desired effect of weeding out extensions that don't make the grade and
forcing support of those that do.
We have tons of experience that this extension model works well and does not
hinder the development of extensions.
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.
I disagree; I think it will have exactly this effect.
You are recreating the PostScript situation here. Nothing more and nothing
less.
Removing "support" will not help avoid this.
I disagree; I think it will.
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.
PostScript tried this approach, more or less, in that you were supposed to
bracket the use of certain optional facilities with tests to make sure the
necessary facilities were there. Implementations were allowed and even
encouraged to reject the use of extensions not so marked. But nobody did the
tests and implementations were forced to handle extensions without the tests.
Your proposal differs slightly in that your tests would be mandatory and the
presence of a test would be a bit easier to spot. I do not think, however, that
this is enough of a difference.
(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 don't think it will have this effect.
You are arguing the logic of the situation here. Unfortunately, my experience
says that your logic, while valid, doesn't match what actually happens. Like it
or not, people's behavior in this area isn't logical.
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.
Rob, let me be blunt. I think this is a recipe for disaster. Nothing more and
nothing less. This is a showstopper for me and I will not support or contribute
to the development of a language with these characteristics. If the group's
consensus is to pursue this model I am not interested in chairing it or
participating in it further.
Ned