13 May
2005
13 May
'05
1:11 p.m.
At 12:42 13/05/2005 -0700, you wrote:
Point taken; my first guess was 0 0 0, but it is
apparently left
ambiguous by the standards committee. I did use the term "almost
always" to hedge, but still, you're right.
Nevertheless, for any given compiler there is only one interpretation.
So I hereby clarify my statement to say that programming languages as
implemented by actual compilers or interpreters are the most succinct,
clear and unambigious specification languages imaginable.
Now I disagree with you - if you rely on a particular implementations
handling of undefined behaviour, your abstraction is no longer clear
or unambiguous - in fact, quite the opposite...
The only correction to be made to your original statement, is that
the programming language must be used correctly - an idea that I
automatically assumed from the beginning, hence I originally had
nothing to add to it.
To another poster's point about
"overspecification," I guess that's
true. So? That's what comments and thoughtful use of identifiers is
for.
... and avoid undefined bahaviour ...
Sorry my first couple of posts on the list are to OT
threads. I'll try
to do better in the future :-)
[I've seen worst OT go on a lot longer :-]
but yeah - this is getting to far away from where we should be - time to
go down to the basement and blink some lights!
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
13 May
13 May
1:59 p.m.
On 5/13/05, Dave Dunfield <dave04a at dunfield.com> wrote:
Now I disagree with you - if you rely on a particular
implementations
handling of undefined behaviour, your abstraction is no longer clear
or unambiguous - in fact, quite the opposite...
The only correction to be made to your original statement, is that
the programming language must be used correctly - an idea that I
automatically assumed from the beginning, hence I originally had
nothing to add to it.
Well yeah, I'll buy that... there's usually no good reason to make
dependencies on implementation dependent behavior. I'd make exception
for areas where standards committees don't define something just
because they can't get squabbling vendors to agree... SQL standard
comes to mind... last version I looked at (a long time ago) couldn't
come to a standard 'date' type. Also some languages like Forth have a
culture of extending the language and room must be made for differing
implementations of even the same words.
All I was saying is that implementation dependent behavior is real as
opposed to abstract so you can determine exactly what any given line
of code will do as opposed to a dodgy/out-of-date specification or
design document.
-- John.
2:16 p.m.
On Friday 13 May 2005 13:59, John Hogerhuis wrote:
On 5/13/05, Dave Dunfield <dave04a at
dunfield.com> wrote:
In K&R's "THE C PROGRAMMING LANGUAGE", 1978, section 2.12
"Precedence and
Order of Evaluation" is a discussion of compilers generating different
answers depending on interpretation (side effects). The first sentence in
the final paragraph reads: "The moral of this discussion is that writing code
which depends on order of evaluation is a bad programming practice in any
language."
I'll buy that.
Lyle
--
Lyle Bickley
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
Now I disagree with you - if you rely on a
particular implementations
handling of undefined behaviour, your abstraction is no longer clear
or unambiguous - in fact, quite the opposite...
The only correction to be made to your original statement, is that
the programming language must be used correctly - an idea that I
automatically assumed from the beginning, hence I originally had
nothing to add to it.
Well yeah, I'll buy that... there's usually no good reason to make
dependencies on implementation dependent behavior. I'd make exception
for areas where standards committees don't define something just
because they can't get squabbling vendors to agree... SQL standard
comes to mind... last version I looked at (a long time ago) couldn't
come to a standard 'date' type. Also some languages like Forth have a
culture of extending the language and room must be made for differing
implementations of even the same words.
All I was saying is that implementation dependent behavior is real as
opposed to abstract so you can determine exactly what any given line
of code will do as opposed to a dodgy/out-of-date specification or
design document.
7164
days inactive
7164
days old
2 comments
3 participants
participants (3)
-
dave04a＠dunfield.com -
jhoger＠gmail.com -
lbickley＠bickleywest.com