[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf language implementation
Ray Byler wrote:
rb> I still think nested comments should be allowed. We are not
rb> re-implementing C, we are creating a new language, and that
rb> gives us the chance to remedy defects in C.
As Joel said, no it doesn't. While we may consider this a
blatantly obvious and trivial thing, such things are to some
degree in the eye of the beholder. This is a dangerous, very
slippery slope that we've been (very) rigorous about avoiding.
While this may appear stubborn and stupid, there have been
numerous "wishes" for "improvements" to the languages we are
stealing from that have previously been removed from the table,
because the rule is: we are "not inventing a new language."
I'm sure that if we were to begin down this path, we'd get
numerous things that the community considers bugs in C/C++
and we'd finish the language in 2004. :-)
The primary reason for this as I see it is that we are
(network) management people, not language people (I know there
are exceptions). We should defer to language people in the
design of PolicyScript.
rb> Not allowing nested
rb> comments is a defect. Many C compiler implementors recognized
rb> this, and created their compilers accordingly. Cost: none; it
rb> is trivial to implement in the lexer. Benefit: it saves the
rb> programmer from wasting time on spurious errors. Finally,
rb> any compiler that does allow nested comments will have a
rb> competitive advantage over one that doesn't.
rb> Also, I feel strongly that the C defect of not specifying
rb> argument evaluation order is not something that should be
rb> carried over to this language. I don't really care whether
rb> the order is left-to-right or right-to-left, as long as we
rb> have a standard. I'm perfectly willing to take the extra
rb> hour to rewrite my code so evaluation is left-to-right. That
rb> way we have a much greater chance that scripts will always
rb> produce the intended results.
Wes Hardaker wrote:
wh> I agree with you that this is a serious defect in C and I'd
wh> like to not inherit C's bugs into this language just because
wh> we're deriving from it.
wh> Actually, we're now deriving from C++. I assume its not
wh> specified there either?
If I could be convinced that either of these issues (1)
are clearly standardized in ISO C or C++ or (2) are clearly
set to be decided on in the Near Future for either C or C++,
I'd be much more willing to back up these changes.
With kind regards,
David Partain David.Partain@ericsson.com
Ericsson Radio Systems AB Tel: +46 13 28 41 44
Research and Innovation Fax: +46 13 28 75 67
P.O. Box 1248
SE-581 12 Linköping, Sweden