 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/10/2010 10:02 PM, Darren New wrote:
> As long as the convenience outweighs the problem you get when you didn't
> *expect* the thing to be NULL, you're good. Phone app? Sure. Missile
> launcher? Bad idea. :-)
Suddenly unsafePerformIO takes on a whole new meaning...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/22/2010 2:02 PM, Darren New wrote:
>
> As long as the convenience outweighs the problem you get when you didn't
> *expect* the thing to be NULL, you're good. Phone app? Sure. Missile
> launcher? Bad idea. :-)
>
On a terrifyingly related note:
http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0004.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> On a terrifyingly related note:
> http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0004.html
Excellent! That's a keeper.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/22/2010 3:36 PM, Darren New wrote:
> Kevin Wampler wrote:
>> On a terrifyingly related note:
>> http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0004.html
>
> Excellent! That's a keeper.
>
Turns out it's a joke (as is perhaps obvious from the author's tone of
voice). Still a pretty good read though IMHO.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> On 10/22/2010 3:36 PM, Darren New wrote:
>> Kevin Wampler wrote:
>>> On a terrifyingly related note:
>>> http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0004.html
>>
>> Excellent! That's a keeper.
>>
>
> Turns out it's a joke
Well, yes, of course. But it shows the sort of problem that languages
designed for that sort of thing (e.g., Ada) avoid.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler <wam### [at] u washingtonedu> wrote:
> On 10/22/2010 3:36 PM, Darren New wrote:
> > Kevin Wampler wrote:
> >> On a terrifyingly related note:
> >> http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0004.html
> >
> > Excellent! That's a keeper.
> >
> Turns out it's a joke (as is perhaps obvious from the author's tone of
> voice). Still a pretty good read though IMHO.
There are tell-tale signs of that, which made me suspicious from the
start. For example:
- The whole premise of someone revealing *anything* about the programming
practices and details of NORAD and other US military organizations dealing
with intercontinental nuclear missiles is absolutely ludicrous. Such a
person would find himself in jail faster than he could type "missile".
- The idea of perl being used to control intercontinental nuclear missiles
is ludicrous (no offense to perl enthusiasts).
- "[...] a lie that would later be repeated over and over again at my
court-martial." I don't think someone court-martialed would be allowed
to reveal the details in public.
- "This error went undetected as my Perl code was translated into C using
the Perl Compiler, from C into machine code, and then was burned into missile
EPROMs. Six weeks later, the missiles were interred in their silos with
inertial guidance systems based on my code. If fired, they would have missed
their destination by thousands of miles." This would mean that they put
completely untested code in nuclear missiles. I find that rather unlikely.
(This sounds like something they would *emulate* first, and an error of
"thousands of miles" would be detected pretty quickly.)
- And of course the glaring hint at the end (emphasis mine): "Ray Piodasoll
no longer works for NORAD in Colorado Springs, but occasionally writes
articles intended to be published in *April, toward the beginning of the
month*."
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> "But null pointers can be useful!" I hear you cry. For this, Haskell has
> the "Maybe" type. Basically, if you say "Foo", it will definitely,
> always, be a Foo. But if you say "Maybe Foo", then it may or may not be
> a Foo - and the type system *requires* you to explicitly check whether
> it's "null" or not before you do stuff to it.
It sounds a bit like references vs. pointers in C++: References in C++
cannot be null, they always have to point to an actual object. (Ok,
technically speaking you can force a reference to point to "null",
but that's undefined behavior, and checking if a reference is "null"
is more complicated than simply comparing it to 0 or NULL.)
Of course the limitation with C++ references is that they are const:
You cannot modify a reference to point to another object. Once a reference
has been initialized, it cannot be modified anymore. It will point to the
one and same object until its scope ends. (I'm not exactly sure now why
this was deemed as necessary.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> "But null pointers can be useful!" I hear you cry. For this, Haskell has
>> the "Maybe" type. Basically, if you say "Foo", it will definitely,
>> always, be a Foo. But if you say "Maybe Foo", then it may or may not be
>> a Foo - and the type system *requires* you to explicitly check whether
>> it's "null" or not before you do stuff to it.
Incidentally, this is the general theme with Haskell. Other languages
signal an error by returning a null pointer, or if the result is
supposed to be an integer, returning a zero or a negative or something.
Haskell style is to use ADTs to return something more high-level. This
way, the possibility of failure is explicitly signalled in the type
system, and the type system will complain if you fail to explicitly
check for failure.
(And then you get to the point where you can perform several
possibly-failing operations in sequence, and have the sequence
automatically abort at the first failure, whichout having to write a
bunch of failure-checking code for each and every failure. It's almost
like an exception, except that it's regular program data, rather than a
special "magical" flow control construct...)
> It sounds a bit like references vs. pointers in C++: References in C++
> cannot be null, they always have to point to an actual object.
Sounds potentially quite useful.
> Of course the limitation with C++ references is that they are const:
> You cannot modify a reference to point to another object.
Sounds a lot like Haskell...
> (I'm not exactly sure now why this was deemed as necessary.)
Nor am I, but hey.
Maybe they were worried that you could make a reference point to
something dynamic, and then free that something, leaving a dangling
reference?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Incidentally, this is the general theme with Haskell. Other languages
> signal an error by returning a null pointer, or if the result is
> supposed to be an integer, returning a zero or a negative or something.
> Haskell style is to use ADTs to return something more high-level. This
> way, the possibility of failure is explicitly signalled in the type
> system, and the type system will complain if you fail to explicitly
> check for failure.
> (And then you get to the point where you can perform several
> possibly-failing operations in sequence, and have the sequence
> automatically abort at the first failure, whichout having to write a
> bunch of failure-checking code for each and every failure. It's almost
> like an exception, except that it's regular program data, rather than a
> special "magical" flow control construct...)
Actually in other languages what is often used for that precise purpose
is exception throwing. A function always returns valid values, but in case
of a fatal error it throws an exception instead (which causes the execution
of the program to diverge right to the exception handling code). The error
type is directly thrown as the exception parameter.
Of course in practice people don't usually use exceptions for expected
errors, only for severe ones. (For example, failing to open a file because
it doesn't exist is usually not considered a severe error, but a completely
normal situation, in which case you seldom throw an exception. However,
something like running out of memory is such a severe error that it deserves
throwing an exception in most languages.)
Exceptions are, thus, usually not used as the silver bullet for error
handling.
> Maybe they were worried that you could make a reference point to
> something dynamic, and then free that something, leaving a dangling
> reference?
You can do that with current C++ references, so that's not the problem.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/10/2010 12:09 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull> wrote:
>> Incidentally, this is the general theme with Haskell. Other languages
>> signal an error by returning a null pointer, or if the result is
>> supposed to be an integer, returning a zero or a negative or something.
>> Haskell style is to use ADTs to return something more high-level. This
>> way, the possibility of failure is explicitly signalled in the type
>> system, and the type system will complain if you fail to explicitly
>> check for failure.
>
> Actually in other languages what is often used for that precise purpose
> is exception throwing. A function always returns valid values, but in case
> of a fatal error it throws an exception instead (which causes the execution
> of the program to diverge right to the exception handling code). The error
> type is directly thrown as the exception parameter.
>
> Of course in practice people don't usually use exceptions for expected
> errors, only for severe ones.
>
> Exceptions are, thus, usually not used as the silver bullet for error
> handling.
Right.
The current Haskell language specification doesn't mention exceptions
(and nor to any prior versions), although most current Haskell
implementations provide exception handling. General Haskell style is
that "expected" things (e.g., doing a dictionary lookup and not finding
the requested key, running a parser and getting a parse error, etc.) are
handled as ADTs. Unexpected things throw exceptions. That's things like
I/O errors, "I've run out of memory", "the user pressed Ctrl+C", and so on.
(One mildly unusual one is that terminating a thread is done by throwing
an exception in that thread - which means you could, in theory, catch
the exception and make the thread not terminate. Don't do that.)
In fact, the GHC exceptions implementation recently changed, which broke
a few people's programs. It used to be that all possible exception types
were hard-coded into the system. If you wanted to throw a user
exception, you'd have to just throw an "OtherError" exception with a
descrptive string. Which works, but doesn't make *catching* exceptions a
lot of fun. The new implementation allows you to define new exception
types, which are related in a kind of hierachy.
(The hierachy means you can do things like "catch all I/O exceptions but
ignore any other kind of exception". However, while OO languages like
Java use the class hierachy to define exception type relationships, in
Haskell you have to be a bit more crafty...)
>> Maybe they were worried that you could make a reference point to
>> something dynamic, and then free that something, leaving a dangling
>> reference?
>
> You can do that with current C++ references, so that's not the problem.
Mmm, OK. Was just a thought...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
