On Sun, Aug 24, 2008 at 5:44 AM, Thomas M. DuBuisson <
[EMAIL PROTECTED]> wrote:
> wrt head [], Niels said:
> > So now what? Action plan = []
>
> Oh come now. Between ghci, hpc, and manual analysis I've never hit a
> Haskell error and thrown my hands up, "I can't go any further, I'm at a
> comple
Richard A. O'Keefe wrote:
On 28 Aug 2008, at 8:34 am, Aaron Tomb wrote:
What type safety buys you, in my mind, is that Nothing is only a valid
value for explicit Maybe types. In cases where you don't use Maybe,
the "null" situation just can't occur. In languages with null
pointers, any pointe
On Thu, Aug 28, 2008 at 5:02 PM, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> Hi
>
>> Tools like Neil Mitchell's Catch can do more sophisticated checking, as long
>> as your program can be compiled by YHC. Sometimes fromJust can be quite
>> useful, though, especially in tandem with isJust. For exampl
Hi
> Tools like Neil Mitchell's Catch can do more sophisticated checking, as long
> as your program can be compiled by YHC. Sometimes fromJust can be quite
> useful, though, especially in tandem with isJust. For example,
>
>> prop_foobar :: SomeType -> Property
>> prop_foobar x
>> = isJust (someT
On Thu, 28 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 13:21, Tim Newsham wrote:
GNU ld supports "pragmas" which cause the use of certain functions to
output warnings at link time (try compiling a C program that uses gets()).
It occurs to me that this, either in compiler or li
On 2008 Aug 28, at 13:21, Tim Newsham wrote:
GNU ld supports "pragmas" which cause the use of certain functions
to output warnings at link time (try compiling a C program that
uses gets()). It occurs to me that this, either in compiler or
linker, would be a nice thing for ghc to do when usi
GNU ld supports "pragmas" which cause the use of certain functions to output
warnings at link time (try compiling a C program that uses gets()). It
occurs to me that this, either in compiler or linker, would be a nice thing
for ghc to do when using fromJust or other partial functions.
would y
On 2008 Aug 28, at 2:41, Don Stewart wrote:
ketil:
The great thing about Maybe is that once I've checked it isn't
Nothing, I can extract the value and dispense with further checks.
foo mbx = maybe default (bar x) mbx
And GHC will warn me when I forget to check all cases, and prevent me
from
ketil:
> Aaron Tomb <[EMAIL PROTECTED]> writes:
>
> >> Huh? Type safety buys [...] nothing about dereferencing null
> >> pointers, which are the moral equivalent of Nothing.
>
> > What type safety buys you, in my mind, is that Nothing is only a valid
> > value for explicit Maybe types. In cases w
Aaron Tomb <[EMAIL PROTECTED]> writes:
>> Huh? Type safety buys [...] nothing about dereferencing null
>> pointers, which are the moral equivalent of Nothing.
> What type safety buys you, in my mind, is that Nothing is only a valid
> value for explicit Maybe types. In cases where you don't use Ma
The ECMA Eiffel standard has
?Teither a void reference or a reference to an instance of T
!Ta reference to an instance of T
Tsame as !T in ECMA Eiffel; used to be same as ?T
similarly, C# "invented" Maybe and called it Nullable:
http://msdn.microsoft.com/en-us/library/
On 28 Aug 2008, at 8:34 am, Aaron Tomb wrote:
What type safety buys you, in my mind, is that Nothing is only a
valid value for explicit Maybe types. In cases where you don't use
Maybe, the "null" situation just can't occur. In languages with null
pointers, any pointer could possibly be null
Dan Weston wrote:
> Tim Docker wrote:
>
> > That differs from my experience. Most segfaults that *I've* caused
(in
> > C or C++) have been due to dereferencing null pointers. Type safety
> > does help you here, in that Maybe lets you distinguish the types of
> > things that are optionally pres
On 2008 Aug 27, at 16:39, Jonathan Cast wrote:
The last `case' is a catch-all, so you do know the result of the
mplus's
is a Just, but you still need the Maybe.
I have to admit my thought here is that the problem isn't the Maybe,
it's the fromJust. Make it go away, force people to explicit
--- On Wed, 8/27/08, Dan Weston <[EMAIL PROTECTED]> wrote:
>
> Failure to handle a null pointer is just like using
> fromJust and results
> in the same program termination (undefined).
>
> Dan
>
Well, not (IMHO) 'just like': 'fromJust Nothing' turns into a 'catchable'
exception in the IO Mona
On Wed, 2008-08-27 at 13:34 -0700, Aaron Tomb wrote:
> On Aug 27, 2008, at 12:23 PM, Dan Weston wrote:
>
> > Huh? Type safety buys you not having to worry about dereferencing
> > stale nonnull pointers (lifetime of reference exceeding lifetime of
> > referent), but nothing about dereferencing
On Aug 27, 2008, at 12:23 PM, Dan Weston wrote:
Huh? Type safety buys you not having to worry about dereferencing
stale nonnull pointers (lifetime of reference exceeding lifetime of
referent), but nothing about dereferencing null pointers, which are
the moral equivalent of Nothing.
What
On Wed, 2008-08-27 at 12:23 -0700, Dan Weston wrote:
> Tim Docker wrote:
> >
> > David Roundy wrote:
> >
> >> Which illustrates the point that it's not type safety
> >> that protects us from segfaults, so much as bounds checking,
> >> and that's got a non-trivial runtime cost. At least, most
>
Tim Docker wrote:
David Roundy wrote:
Which illustrates the point that it's not type safety
that protects us from segfaults, so much as bounds checking,
and that's got a non-trivial runtime cost. At least, most
segfaults that *I've* caused (in C or C++) have been from
overwriting the bounds
David Roundy wrote:
> Which illustrates the point that it's not type safety
> that protects us from segfaults, so much as bounds checking,
> and that's got a non-trivial runtime cost. At least, most
> segfaults that *I've* caused (in C or C++) have been from
> overwriting the bounds of arrays,
On Sat, Aug 23, 2008 at 6:15 PM, Daniel Fischer
<[EMAIL PROTECTED]> wrote:
> Am Samstag, 23. August 2008 23:17 schrieb Thomas Davie:
>>
>> I'd be interested to see your other examples -- because that error is
>> not happening in Haskell! You can't argue that Haskell doesn't give
>> you no segfault
On Mon, Aug 25, 2008 at 7:54 PM, Niels Aan de Brugh <[EMAIL PROTECTED]>wrote:
> Christopher Lane Hinson wrote:
>
>> Here's an error the Haskell run-time system might throw:
>>> *** Exception: Prelude.head: empty list
>>> (or whatever)
>>>
>>> So now what? Action plan = [].
>>>
>>
>> rgrep " head "
Christopher Lane Hinson wrote:
Here's an error the Haskell run-time system might throw:
*** Exception: Prelude.head: empty list
(or whatever)
So now what? Action plan = [].
rgrep " head " .
Lists 17 items for three projects I've been working on summing to
1 lines of haskell. Use listToM
On 2008 Aug 24, at 7:16, C.M.Brown wrote:
OK, so you're basically saying that segfaults can be eliminated with a
strong type system, whereas pattern matching errors is the result of
some
Not really, no. A sufficiently strong type system will eliminate
segfaults (modulo bugs in the language
On 2008 Aug 24, at 4:00, Thomas Davie wrote:
On 24 Aug 2008, at 05:04, Albert Y. C. Lai wrote:
"Dear friends, Haskell prevents more errors and earlier." This is
honest, relevant, good advocacy.
"Dear friends, segfaults are type errors, not logical errors." Why
would you indulge in this? It
Chris said:
> I personally think such pattern matching errors
> are a weaknesss of the language; with possibly no solutions to resolve.
Actually tools like CATCH [1] exist and could be incorporated into a
compiler to eliminate this problem.
[1] http://www-users.cs.york.ac.uk/~ndm/catch/
Hi Brandon,
OK, so you're basically saying that segfaults can be eliminated with a
strong type system, whereas pattern matching errors is the result of some
dodgy laziness going on? I personally think such pattern matching errors
are a weaknesss of the language; with possibly no solutions to resol
On 24 Aug 2008, at 05:04, Albert Y. C. Lai wrote:
"Dear friends, Haskell prevents more errors and earlier." This is
honest, relevant, good advocacy.
"Dear friends, segfaults are type errors, not logical errors." Why
would you indulge in this? It's even less relevant than bikeshed
colours
On 2008.08.24 01:29:18 +0200, Niels Aan de Brugh <[EMAIL PROTECTED]> scribbled
1.0K characters:
> Thomas Davie wrote:
>> http://games.slashdot.org/comments.pl?sid=654821&cid=24716845
>>
>> Apparently, no one realises that a SEGFAULT is a type error, just not
>> a very helpful one.
> Right, so here
"Dear friends, Haskell prevents more errors and earlier." This is
honest, relevant, good advocacy.
"Dear friends, segfaults are type errors, not logical errors." Why would
you indulge in this? It's even less relevant than bikeshed colours.
On the bright side, only mainstream communities have
G'day all.
Quoting Don Stewart <[EMAIL PROTECTED]>:
We promise both safety and efficiency.
We also provide (though don't promise) modularity, robustness
and correctness, which is not something that Java gives you out
of the box.
Cheers,
Andrew Bromage
wrt head [], Niels said:
> So now what? Action plan = []
Oh come now. Between ghci, hpc, and manual analysis I've never hit a
Haskell error and thrown my hands up, "I can't go any further, I'm at a
complete loss!" Also it helps that I run into this extremely rarely - I
have a larger habit of hid
brian wrote:
Here's an error the Haskell run-time system might throw:
*** Exception: Prelude.head: empty list
(or whatever)
So now what? Action plan = [].
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14
Thank you for the URL, but I'm aware of the work in GHC(i). As I've
mentioned
On Sat, Aug 23, 2008 at 6:29 PM, Niels Aan de Brugh <[EMAIL PROTECTED]> wrote:
>
> Here's an error the Haskell run-time system might throw:
> *** Exception: Prelude.head: empty list
> (or whatever)
>
> So now what? Action plan = [].
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14
On 2008 Aug 23, at 17:29, C.M.Brown wrote:
I wonder whether seg faults are the true analogue to errors such as
"error: head empty list." or pattern match errors.
Not really; while laziness does introduce a certain amount of "spooky
action at a difference" to such errors, it's not nearly as ba
Thomas Davie wrote:
http://games.slashdot.org/comments.pl?sid=654821&cid=24716845
Apparently, no one realises that a SEGFAULT is a type error, just not
a very helpful one.
Right, so here's an action plan for a clueless C-programmer:
- Recompile program in debug mode.
- Start application in deb
You can get nice exception (but not segfault) when trying to fire this code:
> {-# OPTIONS_GHC -XRecursiveDo #-}
>
> module Main where
>
> import Control.Concurrent
> import Control.Monad.Fix
>
> loopChan :: IO (Chan ())
> loopChan = mdo chan <- dupChan chan
> return chan
>
> main = do
> c <- loop
Am Samstag, 23. August 2008 23:17 schrieb Thomas Davie:
>
> I'd be interested to see your other examples -- because that error is
> not happening in Haskell! You can't argue that Haskell doesn't give
> you no segfaults, because you can embed a C segfault within Haskell.
>
> Bob
Use ST(U)Arrays, a
As a day-time java programmer, I can say from experience that sometimes (100%
pure) Java programs DO segfault.
I've had it happen to me, and while you can justifiably say it's an error in
the JVM somehow triggered by your program behaviour/timing, that doesn't help
you very much at the time.
> I guess I didn't express my point very clearly... That C programmers
> apparently don't realise that a type system that's sound will give
> them something -- i.e. their programmer won't ever segfault. I wonder
> when we try to advertise Haskell if we should be saying "we can give
> you programs
On 23 Aug 2008, at 23:10, Tim Newsham wrote:
I guess I didn't express my point very clearly... That C
programmers apparently don't realise that a type system that's
sound will give them something -- i.e. their programmer won't ever
segfault. I wonder when we try to advertise Haskell if we
On 23 Aug 2008, at 23:10, Tim Newsham wrote:
I guess I didn't express my point very clearly... That C
programmers apparently don't realise that a type system that's
sound will give them something -- i.e. their programmer won't ever
segfault. I wonder when we try to advertise Haskell if we
newsham:
> >I guess I didn't express my point very clearly... That C programmers
> >apparently don't realise that a type system that's sound will give them
> >something -- i.e. their programmer won't ever segfault. I wonder when we
> >try to advertise Haskell if we should be saying "we can give
I guess I didn't express my point very clearly... That C programmers
apparently don't realise that a type system that's sound will give them
something -- i.e. their programmer won't ever segfault. I wonder when we try
to advertise Haskell if we should be saying "we can give you programs that
n
On 23 Aug 2008, at 22:36, Matus Tejiscak wrote:
On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote:
Today I made an interesting discovery.
We all know the benefits of a strong type system, and often tout it
as
a major advantage of using Haskell. The discovery I made, was that C
programm
On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote:
> Today I made an interesting discovery.
>
> We all know the benefits of a strong type system, and often tout it as
> a major advantage of using Haskell. The discovery I made, was that C
> programmer don't realise the implications of that,
Today I made an interesting discovery.
We all know the benefits of a strong type system, and often tout it as
a major advantage of using Haskell. The discovery I made, was that C
programmer don't realise the implications of that, as this comment
highlights:
http://games.slashdot.org/comm
47 matches
Mail list logo
