 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://journal.stuffwithstuff.com/2010/10/21/the-language-i-wish-go-was/
An interesting look into some problems we've solved and why. (The fact that
it's phrased as "Go is missing this" isn't what's interesting.)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> http://journal.stuffwithstuff.com/2010/10/21/the-language-i-wish-go-was/
I'm not so sure I agree with the necessity of 'union'.
'union' in C is basically a construct which exists to save some bytes
of memory in some rare circumstances. The price you pay for it is reduced
type safety: You always have to make sure you are using the object with
the correct type, or else you'll get garbage. More often than not, unions
are not used raw, but embedded in structs, where one of the struct members
tells the type of the union. While in some situations you can use this to
save memory (especially if you need to instantiate this struct millions of
times), it introduces the overhead of the type member and having to always
check it. (Without the union there would be no need to write any conditionals
based on the type.)
You could have the language always automatically check the proper type
of the union, but then you'll be having overhead on every single operation
you are doing with that union (overhead which could in many cases be avoided).
It would be rare for the memory saving advantage to be worth the overhead.
As for removing null pointers, that would present problems of its own.
Null pointers in languages like C, C++ and Java are often used for useful
things. For example if you have a linked list, a null 'next' pointer is
a good indication of the element being the last one in the list. Without
the possibility of having null pointers you would have to device some other
kind of solution.
In Objective-C you usually don't have to check for null pointers. You can
(usually) safely make method calls on objects even if the pointer is null
(in this case no method call will be done, and if the method has a return
value, the default value will be returned). This way you can do all kinds
of things without having to worry about null pointers. (Of course this
introduced a slight overhead on every method call, but method calls in
Objective-C are really heavy regardless, so the small null-pointer check
doesn't add significantly).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> http://journal.stuffwithstuff.com/2010/10/21/the-language-i-wish-go-was/
>
> An interesting look into some problems we've solved and why. (The fact
> that it's phrased as "Go is missing this" isn't what's interesting.)
I've read that before on reddit. Is that a co-worker or a pseudonym? :)
This kind of thing only happen to multilingual programmers: they are
always annoyed at the fact that their fav pet abstractions are scattered
among their favorite programming languages and either involve a
performance penalty or expressivity/flexibility penalty...
Guys who think all languages are the same and just choose the most
popular suffer from no such headaches... :p
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 'union' in C is basically a construct which exists to save some bytes
> of memory in some rare circumstances.
I have also seen it used for typecasting, but nowadays I think casting the
address of the thing to the "wrong" pointer type and then indirecting it
gets used more. I.e.; { long x = ...; float f = *(float*)&x; }
> As for removing null pointers, that would present problems of its own.
> Null pointers in languages like C, C++ and Java are often used for useful
> things.
I think the way to think of it is that a pointer that can be null is a
different type than a pointer that can't be null, and you have to do the
equivalent of a dynamic_cast<> from a nullable pointer to a non-nullable
pointer before you can indirect thru it.
Of course, if your language wasn't lame, you'd be able to just say
if (x != null) y = *x;
and the compiler would use typestate or something to let that go, whereas
without the "if (x != null)" on the front, it would complain that maybe *x
is indirecting thru null.
The problem isn't that pointers might be null. The problem is that someone
might indirect thru a null (or otherwise uninitialized) pointer without
knowing it.
> In Objective-C you usually don't have to check for null pointers.
That's the other way to handle it. Or to throw an exception which you can
catch. The Obj-C way certainly sounds more ... PHPish. ;-)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > 'union' in C is basically a construct which exists to save some bytes
> > of memory in some rare circumstances.
> I have also seen it used for typecasting, but nowadays I think casting the
> address of the thing to the "wrong" pointer type and then indirecting it
> gets used more. I.e.; { long x = ...; float f = *(float*)&x; }
The most clever use of 'union' I have seen was like this:
union Matrix4x4
{
double m[4][4];
struct
{
double m11, m12, m13, m14,
m21, m22, m23, m24,
m31, m32, m33, m34,
m41, m42, m43, m44;
};
};
This means you can access the matrix like "transform.m[1][2] = 5;"
or like "transform.m23 = 5;";
Of course in this case this is just a trick to have two naming
conventions to access the same data (rather than to save memory).
> > In Objective-C you usually don't have to check for null pointers.
> That's the other way to handle it. Or to throw an exception which you can
> catch. The Obj-C way certainly sounds more ... PHPish. ;-)
It's actually really handy in Objective-C when developing for the iPhone.
You could have a member which points to some screen element, such as eg.
a label or an image, and you can write code which handles that element
(eg. hides/unhides it, or updates its text to show some info, and of course
when the owner dies, it has to release the object). However, when editing
the GUI of the program with Interface Builder, you can simply remove that
screen element without the program crashing due to a null pointer.
(There are exceptions to this, of course, ie. situations where a null
pointer is invalid and will cause eg. a 'invalid parameter' exception at
runtime, but in many situations null pointers will be quite "transparent".)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/10/2010 05:33 PM, Warp wrote:
> I'm not so sure I agree with the necessity of 'union'.
>
> 'union' in C is basically a construct which exists to save some bytes
> of memory in some rare circumstances. The price you pay for it is reduced
> type safety: You always have to make sure you are using the object with
> the correct type, or else you'll get garbage. More often than not, unions
> are not used raw, but embedded in structs, where one of the struct members
> tells the type of the union. While in some situations you can use this to
> save memory (especially if you need to instantiate this struct millions of
> times), it introduces the overhead of the type member and having to always
> check it. (Without the union there would be no need to write any conditionals
> based on the type.)
>
> You could have the language always automatically check the proper type
> of the union, but then you'll be having overhead on every single operation
> you are doing with that union (overhead which could in many cases be avoided).
> It would be rare for the memory saving advantage to be worth the overhead.
You have just described Algebraic Data Types.
An ADT is basically like a (possibly singleton) union of (possibly
nullary) structs together with an enum that tells you which struct is
present at run-time.
If you just want a normal struct, you make an ADT with only one
constructor. If you just want an enum, you make an ADT with several
constructors each with zero fields. But an ADT generalises both, as you
can see.
Having to check which struct is present every single time you want to
access its fields _would_ be very annoying, except that this is where
Haskell's "pattern matching" comes in. With it, you can check which
struct is there and copy the field values into variables all in a single
operation. (It's a single primitive operation as far as Haskell is
concerned, although obviously the generated machine code is potentially
many instructions long.)
(I suppose it goes without saying that how all of this is actually
implemented isn't specified. But GHC does things like optimising away
constructor checks for singleton constructors, and making zero-field
constructors into static global constants, etc.)
> As for removing null pointers, that would present problems of its own.
> Null pointers in languages like C, C++ and Java are often used for useful
> things. For example if you have a linked list, a null 'next' pointer is
> a good indication of the element being the last one in the list. Without
> the possibility of having null pointers you would have to device some other
> kind of solution.
Again, Haskell does not allow null pointers. (Then again, Haskell really
deals with "references" rather than "pointers" as such.) This neatly
eliminates an entire class of bugs.
"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.
In other words, pointers which can be null are distinguished from
pointers that cannot be null (in the type system). And you have to check
at run-time. (If you don't, your program just won't compile.)
Of course, Maybe is just a plain vanilla ADT, defined in plain vanilla
Haskell. It just happens to be part of the standard library.
I gather Eiffel did this, actually. But they retro-fitted it to the
language. So rather than saying "these [and only these] things might be
null", you get to say "these [and only these] things definitely will NOT
be null". Which is kinda backwards [compatible].
One thing null pointers are often used for are error conditions. Like,
you have a parser function that returns either a pointer to a parse
tree, or a null pointer if there was a parse error. In Haskell, another
ADT comes into play: it's called "Either". Instead of saying "this
returns a SyntaxTree", you say "this returns an Either ParseError
SyntaxTree". Meaning that it either returns a ParseError, or a
SyntaxTree. (And you have to explicitly check which one before you do
stuff to it.) Same deal as above, but you can return a _description_ of
the failure rather than just fail.
Apparently there are two kinds of programmers: The ones who look at all
of the above and go "wow, that's a whole lot of unecessary run-time
overhead!", and the ones who go "wow, that's really going to reduce the
amount of time I waste trying to debug my complex application"...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Of course in this case this is just a trick to have two naming
> conventions to access the same data (rather than to save memory).
That's cool. FORTRAN had this too (a la "named DATA blocks", which is to say
what C would call "static" variables with names), and I'm pretty sure it was
there to save memory. Of course, that was back when 4K was a big machine.
> It's actually really handy in Objective-C when developing for the iPhone.
It's really handy in PHP too. ;-) Seriously, the "@" operator in PHP is all
kinds of convenient. It's basically a one-character way of saying
try { ... } catch {}. So { X = @yadda(this, that()); } means X gets an
empty string if either yadda or that throws an error, or "this" isn't
defined, or whatever.
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. :-)
--
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 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] uwashingtonedu> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Wait. When you posted that, did you *not* think it's a joke?
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Of course in practice people don't usually use exceptions for expected
> errors, only for severe ones.
I don't think it's "expected vs severe", at least not in code where people
have thought about it. It's more "errors you're likely going to want to
handle right where they happen (such as not being able to open the file
you're trying toopen)" vs "errors you likely have a more global catch for
(such as divide by zero or out of disk space)".
The advantage of the exception mechanism is you can catch a bunch of
exceptions anywhere in a bunch of called routines with one catch. If the
type of error is one that 95% of the time I want to handle the error right
where it happens (like "OK, couldn't open it, so I'll create it" or "I'll
prompt the user for a different name" or something) then it doesn't make
sense to code it as an exception.
And I think that's where Java's checked exceptions concept fails: They
explicitly turn the things you want to test for into exceptions, then
require you to test for them anyway with a much more tedious and distracting
syntax.
As for exiting a thread by forcing it to throw an exception, that makes
perfect sense from an implementation point of view.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> As for exiting a thread by forcing it to throw an exception, that makes
> perfect sense from an implementation point of view.
Usually threads are ended by exiting the function that was launched by
the thread...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/10/2010 06:27 PM, Warp wrote:
> Usually threads are ended by exiting the function that was launched by
> the thread...
Yes, usually. But the GHC threading implementation allows you to
forcibly "kill" another thread (by throwing an exception in it, as I say).
It's occasionally useful to do this if the thread performs some kind of
"infinite loop", and it's another thread's job to detect when the loop
should be stopped. You could of course just have a semaphore to signal
to the thread that it should stop now, but if some part of the thread's
loop takes a long time to execute, it might not be convinient to check
the semaphore frequently enough that the thread will stop promptly.
(OTOH, I gather GHC cannot kill a thread except at certain points in the
code, so you can end up with an unkillable thread anyway...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> As for exiting a thread by forcing it to throw an exception, that makes
>> perfect sense from an implementation point of view.
>
> Usually threads are ended by exiting the function that was launched by
> the thread...
Exactly. So the thread equivalent of "exit()" usually throws an exception
that's generally outside the usual exception hierarchy, in order to unwind
the stack and cause the top-most function to exit without screwing up other
threads. And most thread libraries for languages with exceptions give you a
way to make that happen in some other thread.
--
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 23/10/2010 05:39 PM, Darren New wrote:
> I don't think it's "expected vs severe", at least not in code where
> people have thought about it. It's more "errors you're likely going to
> want to handle right where they happen (such as not being able to open
> the file you're trying toopen)" vs "errors you likely have a more global
> catch for (such as divide by zero or out of disk space)".
Makes sense.
> The advantage of the exception mechanism is you can catch a bunch of
> exceptions anywhere in a bunch of called routines with one catch.
True enough.
[In Haskell, exceptions carry the disadvantage that due to lazy
evaluation, it can be a tad unpredictable exactly when an exception will
be thrown. Also, you can only catch these exceptions in the IO monad,
which might be a very, very long way away from where the exception
happened...]
> And I think that's where Java's checked exceptions concept fails: They
> explicitly turn the things you want to test for into exceptions, then
> require you to test for them anyway with a much more tedious and
> distracting syntax.
Heh, yeah, there is that. In all the Java code I've looked at, I don't
think I've ever seen a try/catch block which actually *handles* an
exception. They all just silently ignore it. (Then again, I haven't
looked at a lot of exception code...)
There's a couple of people on the Haskell mailing lists who like to
distinguish between "exceptions" and "errors" (and get all shirty when
people claim that they're the same thing).
As far as I can tell, an "error" is a situation that arises due to a bug
in your program, whereas an "exception" is when a situation is caused by
external events that you can't control.
For example, division by zero or an invalid array index would be errors.
(Your program should be constructed such that these never happen for any
reason.) Trying to open a file that doesn't exist would be an exception.
(Even if you check that the file exists, it could theoretically cease to
exist by the time you go to open it.)
Some people have even gone as far as to suggest that it's a design flaw
that errors can be caught. But of course, if it were not so then a mere
coding glitch could crash a production system with no possibility of
exiting gracefully, closing resources properly, logging what happened,
or maybe, I don't know, restarting the failed operation?
(Ideally your program shouldn't contain any bugs. But if the program is
critical enough, you really don't want it to just shut down because
something bad happened. You might want to have it reset itself and try
again - assuming that this is likely to produce a different result of
course.)
Amusing thing: Last time I checked, a GHC program exits when thread #0
exits. And if (say) thread #13 throws an exception which isn't caught,
then thread #13 just exits, and the rest of the system keeps running.
Isn't that fun? :-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> As far as I can tell, an "error" is a situation that arises due to a bug
> in your program, whereas an "exception" is when a situation is caused by
> external events that you can't control.
Huh. I would say an error is something you don't want to have happen, and an
exception is a data structure describing an alternate return value from a
function. If this is really how it's worded, then there's definitely a
problem of crossing meta boundaries.
Ada of course has standard terms for all these sorts of things. The only one
I remember offhand is "erroneous execution", which means doing something at
runtime that isn't defined by the language as being checked by the runtime,
like accessing heap memory that you've already freed and so on.
> For example, division by zero or an invalid array index would be errors.
In some languages, it's perfectly reasonable to use the
array-index-out-of-bounds exception to exit your loop when you're done
processing. Or, at least, you could do it that way intentionally if you want.
In C# event handlers, there's usually a "XYZing" event handler and an
"XYZed" event handler. So if you want to change the volume, you'd have
audiothing.Volume = 50
That would invoke the VolumeChanging event, to let anyone interested in the
volume level know that someone is *trying* to change the volume. If none of
them throw an exception, it sets the new volume, adjusts the hardware and
all, then invokes the VolumeChanged event to let everyone know it has
changed, none of which are *supposed* to throw errors. If you want to stop
someone from changing the volume at this particular moment (think grabbed
focus or something) then you throw an exception in a routine hooked to the
...ing event.
And of course Eiffel also has a whole mechanism that involves throwing
exceptions when you have errors. And the first routine with the ability to
catch the exception depends on the type of error it is.
> Some people have even gone as far as to suggest that it's a design flaw
> that errors can be caught.
Yes, only in an academic environment, tho. :-)
> Amusing thing: Last time I checked, a GHC program exits when thread #0
> exits. And if (say) thread #13 throws an exception which isn't caught,
> then thread #13 just exits, and the rest of the system keeps running.
> Isn't that fun? :-)
That's pretty much how most systems with threads work, as far as I know.
Some have a mechanism that waits for all threads that aren't "background"
threads to exit, tho, if that's what you mean, but that just means that
there's a blob of code at the end of Thread#0 that says "iterate thru all
non-background threads and wait for them to exit."
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As far as I can tell, an "error" is a situation that arises due to a
>> bug in your program, whereas an "exception" is when a situation is
>> caused by external events that you can't control.
>
> Huh. I would say an error is something you don't want to have happen,
> and an exception is a data structure describing an alternate return
> value from a function. If this is really how it's worded, then there's
> definitely a problem of crossing meta boundaries.
I'm not quite sure what to make of that, other than "people have
different terms for things".
Then again, this is from the community where "parallel" and "concurrent"
aren't the same thing...
>> Some people have even gone as far as to suggest that it's a design
>> flaw that errors can be caught.
>
> Yes, only in an academic environment, tho. :-)
Well, yeah, there is that. This is Haskell, after all. *sigh*
>> Amusing thing: Last time I checked, a GHC program exits when thread #0
>> exits. And if (say) thread #13 throws an exception which isn't caught,
>> then thread #13 just exits, and the rest of the system keeps running.
>> Isn't that fun? :-)
>
> That's pretty much how most systems with threads work, as far as I know.
> Some have a mechanism that waits for all threads that aren't
> "background" threads to exit, tho, if that's what you mean, but that
> just means that there's a blob of code at the end of Thread#0 that says
> "iterate thru all non-background threads and wait for them to exit."
It just amuses me that if you have a single-threaded program that throws
an exception, the program halts and prints out a message on stderr. But
as soon as you have multiple threads... this doesn't happen any more.
You'd think it would make more sense to rethrow an uncaught exception to
thread #0, but anyway...
The GHC threading implementation also lacks things like being able to
assign priorities to threads, and so forth. But hey, at least it works.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I'm not quite sure what to make of that, other than "people have
> different terms for things".
Sure.
> Then again, this is from the community where "parallel" and "concurrent"
> aren't the same thing...
They aren't.
> It just amuses me that if you have a single-threaded program that throws
> an exception, the program halts and prints out a message on stderr. But
> as soon as you have multiple threads... this doesn't happen any more.
I see.
> You'd think it would make more sense to rethrow an uncaught exception to
> thread #0, but anyway...
No, because there's no reasonable context in thread 0 to which you could
throw the exception. If you want to catch the exception, catch it in the
thread where it happened. It's perfectly reasonable, given how threads are
usually defined as "run this function in a separate thread", which makes it
trivial to wrap whatever in a top-level function that catches and handles
otherwise-uncaught exceptions.
The fact that the program doesn't stop when the thread doesn't catch an
execption is exactly why you kill threads from outside by coaxing them into
throwing an exception.
> The GHC threading implementation also lacks things like being able to
> assign priorities to threads, and so forth.
That's a whole 'nuther can of worms.
--
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/23/2010 9:31 AM, Darren New wrote:
>
> Wait. When you posted that, did you *not* think it's a joke?
>
I had heard the story from a friend (told not as a joke) and had only
skimmed a few paragraphs the article to see that it was indeed the one
they were talking about, so yes. I also think the friend had never read
the article, but had heard the story from some one else. I'm sure some
urban legends have started that way. Upon actually reading the article,
yeah, it's quite obvious that it's not real.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler wrote:
> Upon actually reading the article,
> yeah, it's quite obvious that it's not real.
OK. You had me worried there for a minute. :-)
--
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 12:16 PM, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> 'union' in C is basically a construct which exists to save some bytes
>>> of memory in some rare circumstances.
>
>> I have also seen it used for typecasting, but nowadays I think casting the
>> address of the thing to the "wrong" pointer type and then indirecting it
>> gets used more. I.e.; { long x = ...; float f = *(float*)&x; }
>
> The most clever use of 'union' I have seen was like this:
>
> union Matrix4x4
> {
> double m[4][4];
> struct
> {
> double m11, m12, m13, m14,
> m21, m22, m23, m24,
> m31, m32, m33, m34,
> m41, m42, m43, m44;
> };
> };
>
> This means you can access the matrix like "transform.m[1][2] = 5;"
> or like "transform.m23 = 5;";
>
> Of course in this case this is just a trick to have two naming
> conventions to access the same data (rather than to save memory).
As they call it, Syntactic sugar.
I've seen unions as a means of assisting with reading binary file data,
but generally stored in a struct.
the Variant data type used by COM is a union. again, it has a field that
tells what the variant is, but it basically is there to allow data of
any type to be passed around. Not exactly type safe, but necessary for
programs written in VB that insist on not declaring any variable as a
particular type. Or for when you don't know what data type you will be
handing off (e.g. the clipboard)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 26/10/2010 02:59 PM, Mike Raiford wrote:
> As they call it, Syntactic sugar.
Depends on your language.
In an object-oriented language, you generally don't need it, since
anything declared to be of class X can actually be of class X *or* any
subclass thereof.
In Haskell, "unions" are a fundamental part of the language. One of the
fundamental branching primitives is based on them. Nullable fields use
unions, lists are unions, trees are unions, just about everything ends
up being a union. [Insert witty Thatcher jokes here.]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> In Haskell, "unions" are a fundamental part of the language. One of the
> fundamental branching primitives is based on them. Nullable fields use
> unions, lists are unions, trees are unions, just about everything ends
> up being a union. [Insert witty Thatcher jokes here.]
I'm not exactly sure if your concept of "union" is the same as C's
concept of "union". A union in C has a fixed size. It's not a dynamic
data container, like a list or a tree.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It's not a dynamic data container, like a list or a tree.
Remember that in Haskell these are defined recursively. So a "tree" in this
case is union { struct { tree*left, tree*right }, struct { node data } }
A list is
union { struct {node data, list* next} , struct {node data} }
I.e., what he's calling "tree" would be "node of a tree" in C.
--
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 27/10/2010 07:27 PM, Darren New wrote:
> I.e., what he's calling "tree" would be "node of a tree" in C.
Yeah, I should have been clearer about that. A list *node* is a union. A
tree *node* is a union.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> On 27/10/2010 07:27 PM, Darren New wrote:
> > I.e., what he's calling "tree" would be "node of a tree" in C.
> Yeah, I should have been clearer about that. A list *node* is a union. A
> tree *node* is a union.
What would the harm be if eg. list nodes were structs instead?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I.e., what he's calling "tree" would be "node of a tree" in C.
>
>> Yeah, I should have been clearer about that. A list *node* is a union. A
>> tree *node* is a union.
>
> What would the harm be if eg. list nodes were structs instead?
Nothing. It's just that in Haskell, you can't implement it that way.
[Correction: You can't implement *finite* lists that way.] And, with
unions being a fundamental part of the language, you don't need to.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> What would the harm be if eg. list nodes were structs instead?
Since "null" is a union in Haskell to (i.e., it either has data in it or it
has no data in it), this wouldn't really save you anything.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > What would the harm be if eg. list nodes were structs instead?
> Since "null" is a union in Haskell to (i.e., it either has data in it or it
> has no data in it), this wouldn't really save you anything.
It saves checking the node type for each single operation you do to any
node in the list. It the node is a struct, its contents are fixed and thus
you don't have to check anything.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> It saves checking the node type for each single operation you do to any
> node in the list. It the node is a struct, its contents are fixed and thus
> you don't have to check anything.
If the node is a struct, you still have to check if it's the end of the list
or a leaf of the tree. You still have to do the equivalent of the text in
if (node->next != NULL) ...
In any case, this checking process is built into the syntax of the language.
That (and more) is what is meant by "pattern matching" constructs. So
checking the tag on the union (so to speak) is done in a type-safe way with
pretty much the same amount of work as checking for a NULL pointer.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> What would the harm be if eg. list nodes were structs instead?
>
>> Since "null" is a union in Haskell to (i.e., it either has data in it or it
>> has no data in it), this wouldn't really save you anything.
>
> It saves checking the node type for each single operation you do to any
> node in the list. It the node is a struct, its contents are fixed and thus
> you don't have to check anything.
On the other hand, in a language where unions appear all over the place,
the implementors go to great lengths to make it really efficient.
Besides, normally just about any code that does stuff to a linked list
ends up doing something like
while (list != null)
do stuff;
list = next node;
So there's a check in there anyway. All we're doing by using a union is
making it a different check.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah, I should have been clearer about that. A list *node* is a union. A
>> tree *node* is a union.
>
> What would the harm be if eg. list nodes were structs instead?
Perhaps I should elaborate further:
I'm not attempting to argue that unions are such a fundamental feature
that every programming language should have them. I'm just pointing out
that *in Haskell* they are extremely fundamental. Which, clearly, is a
different statement.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Besides, normally just about any code that does stuff to a linked list
> ends up doing something like
> while (list != null)
> do stuff;
> list = next node;
> So there's a check in there anyway. All we're doing by using a union is
> making it a different check.
Ostensibly there could be other types of nodes in the list besides regular
nodes and end nodes. These could, for example, contain different types of
data. Any operation you do on the data would have to first check that the
node is of the correct type (if the node is a union).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28/10/2010 08:36 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull> wrote:
>> Besides, normally just about any code that does stuff to a linked list
>> ends up doing something like
>
>> while (list != null)
>> do stuff;
>> list = next node;
>
>> So there's a check in there anyway. All we're doing by using a union is
>> making it a different check.
>
> Ostensibly there could be other types of nodes in the list besides regular
> nodes and end nodes. These could, for example, contain different types of
> data. Any operation you do on the data would have to first check that the
> node is of the correct type (if the node is a union).
Sure. But the compiler statically knows what all the possibilities are,
and it can decide on some suitable arrangement for doing this efficiently.
Instead of writing the above, in Haskell you end up doing something like
do_stuff list =
case list of
Node data next -> ... [recursively call do_stuff next] ...
End -> ...[do something else]...
If there are more possibilities than just "Node" or "End", you just list
them as extra possibilities. Either way, the compiler is going to build
a multi-way jump. (I believe GHC handles this using indirect code
pointers rather than actual integer comparisons against an ID tag.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> These could, for example, contain different types of data.
> Any operation you do on the data would have to first check that the
> node is of the correct type (if the node is a union).
But you still need to do this, even if it's a struct, unless by "struct" you
mean all the data in every element is always valid, in which case you
wouldn't use a union in Haskell either.
Either you're operating on invalid data, or you're checking if the data is
valid before operating on it. Yes?
--
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 12:33 PM, Warp wrote:
> Darren New<dne### [at] sanrrcom> wrote:
>> http://journal.stuffwithstuff.com/2010/10/21/the-language-i-wish-go-was/
>
> I'm not so sure I agree with the necessity of 'union'.
>
> 'union' in C is basically a construct which exists to save some bytes
> of memory in some rare circumstances. The price you pay for it is reduced
> type safety: You always have to make sure you are using the object with
> the correct type, or else you'll get garbage. More often than not, unions
> are not used raw, but embedded in structs, where one of the struct members
> tells the type of the union. While in some situations you can use this to
> save memory (especially if you need to instantiate this struct millions of
> times), it introduces the overhead of the type member and having to always
> check it. (Without the union there would be no need to write any conditionals
> based on the type.)
>
> You could have the language always automatically check the proper type
> of the union, but then you'll be having overhead on every single operation
> you are doing with that union (overhead which could in many cases be avoided).
> It would be rare for the memory saving advantage to be worth the overhead.
There might be an application in which a set of classes derived from a
common ancestor need to be forced to have the same size. Then a member
which is of a different type in different classes would best be a union.
Class member functions (late bound) would know which member of the
union to access without having to type check.
Really, though, the union is a kludge built into C for the resource-poor
early days of computing.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The most clever use of 'union' I have seen was like this:
>
> union Matrix4x4
> {
> double m[4][4];
> struct
> {
> double m11, m12, m13, m14,
> m21, m22, m23, m24,
> m31, m32, m33, m34,
> m41, m42, m43, m44;
> };
> };
>
> This means you can access the matrix like "transform.m[1][2] = 5;"
> or like "transform.m23 = 5;";
>
> Of course in this case this is just a trick to have two naming
> conventions to access the same data (rather than to save memory).
I know someone who got this to work via C++ operator overloading and other
nasties:
Vector3D a, b;
a.xy = b.zx;
It's equivalent to a.x=b.z; a.y=b.x; Any combination of xyz letters would
work, probably even a.xxx=b.yzy;
IIRC it even used SSE inline assembly to do the assignments.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> I know someone who got this to work via C++ operator overloading and other
> nasties:
> Vector3D a, b;
> a.xy = b.zx;
> It's equivalent to a.x=b.z; a.y=b.x; Any combination of xyz letters would
> work, probably even a.xxx=b.yzy;
All to save typing a few extra characters... :P
> IIRC it even used SSE inline assembly to do the assignments.
And probably hindering any possibility for the compiler to perform
optimizations resulting in even more efficient code...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> It's equivalent to a.x=b.z; a.y=b.x; Any combination of xyz letters would
>> work, probably even a.xxx=b.yzy;
>
> All to save typing a few extra characters... :P
AFAIK, this is the sort of syntax that the 3D graphics cards use for
built-in vector operations. Of course, that's a separate compiler with
"custom" syntax, so it's probably just as efficient if not moreso.
I'm guessing given the name of the class he was trying to duplicate the
syntax used in the grpahics card stuff.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
