On Saturday 18 November 2006 00:37, Neil Mitchell wrote:
> Hi
>
> > > How controversial would a proposal to {-# DEPRECATE fromJust #-} be, in
> > > favour of:
> > >
> > > Just _ = x -- which will give you the precise line number
> > >
> > > It seems to me this is one cause of mysterious newbie
On Fri, Nov 17, 2006 at 11:37:12AM +, Neil Mitchell wrote:
> fromJust is simple, useful and clear. What you mean is that
> implementations aren't very good at debugging this. It seems unfair to
> blame partial functions for the lack of a debugger. If a call stack
> was automatically output ever
Exactly!
On Nov 17, 2006, at 07:30 , Henning Thielemann wrote:
It seems to me like the discussion about static typesafety vs. no
or weak
typesafety. (Which still exists with respect to several Haskell
libraries.) Of course, all type errors can be catched also by a
debugger.
So was the de
On Fri, 17 Nov 2006, Neil Mitchell wrote:
> Hi
>
> > > How controversial would a proposal to {-# DEPRECATE fromJust #-} be, in
> > > favour of:
> > >
> > > Just _ = x -- which will give you the precise line number
>
> > > It seems to me this is one cause of mysterious newbie errors we
> >
Hi
> How controversial would a proposal to {-# DEPRECATE fromJust #-} be, in
> favour of:
>
> Just _ = x -- which will give you the precise line number
> It seems to me this is one cause of mysterious newbie errors we
> could easily discourage, with little harm.
Btw, I'm not seriously s
On Fri, 17 Nov 2006, S. Alexander Jacobson wrote:
> As long as we are doing this, perhaps we should also discourage the use of
> (head list)?
Is 'cycle' also bad style, because it fails on empty lists?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell
As long as we are doing this, perhaps we should also discourage the
use of (head list)?
-Alex-
__
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On Fri, 17 Nov 2006, Donald Bruce Stewart wrote:
dons:
dmhouse:
On 1
dons:
> dmhouse:
> > On 16/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >And if we are absolutely positive that the value is (Just x),
> > >we can always write
> > >maybe (assert False undefined) id v
> >
> > It should be pointed out that Data.Maybe does export a less well-known
dmhouse:
> On 16/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >And if we are absolutely positive that the value is (Just x),
> >we can always write
> >maybe (assert False undefined) id v
>
> It should be pointed out that Data.Maybe does export a less well-known
> function, fromMay
On 16/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
And if we are absolutely positive that the value is (Just x),
we can always write
maybe (assert False undefined) id v
It should be pointed out that Data.Maybe does export a less well-known
function, fromMaybe:
fromMaybe z = mayb
Jan-Willem Maessen wrote:
> In addition, we have this rather nice assembly of functions which
> work on ordinary lists. Sadly, rewriting them all to also work on
> NonEmptyList or MySpecialInvariantList is a nontrivial task.
That's an excellent question. Indeed, let us assume we have a func
It must be stressed that the advocated technique for avoiding partial
function errors requires *NO* research advances, *NO* dependent types,
*NO* annotations, and *NO* tools. Everything is possible in Haskell as
it is -- actually, even in Haskell98. As a matter of fact, exactly the
same approach a
This isn't a trivial point. We know that error handling code is a major part of software cost--it
can even >dominate the cost of the "correct case" code (by a large factor). Erlang's "program for
the correct case" >strategy, coupled with good fault tolerance mechanisms, is one reason for its
com
On Nov 15, 2006, at 3:21 AM, [EMAIL PROTECTED] wrote:
Donald Bruce Stewart wrote:
So all this talk of locating head [] and fromJust failures got me
thinking:
Couldn't we just use rewrite rules to rewrite *transparently*
all uses of fromJust to safeFromJust, tagging the call site
On Wednesday 15 November 2006 15:53, John Hughes wrote:
> > From: Robert Dockins <[EMAIL PROTECTED]>
> >
> > It seems to me that every possible use of a partial function has some
> > (possibly imagined) program invariant that prevents it from failing.
> > Otherwise it is downright wrong. 'head', '
> From: Robert Dockins <[EMAIL PROTECTED]>
> It seems to me that every possible use of a partial function has
some > (possibly imagined) program invariant that prevents it from
failing. > Otherwise it is downright wrong. 'head',
'fromJust' and friends > don't do anything to put that inva
Robert Dockins wrote:
Or how about ??
lookupVarible target env =
case [ v | (n,v) <- env, n==target ] of
(x:_) -> x
_ -> assert False $ "BUG: Unexpected variable out of scope
"++(show target)++" in environment "++(show env)
Other have pointed out that, in the CURRENT Hask
Robert Dockins <[EMAIL PROTECTED]> writes:
> On Nov 15, 2006, at 9:48 AM, Jón Fairbairn wrote:
> > But instead of “blah (head [ v | (n,v) <- env, n==target ])
> > blah”, you could write
> >
> > blah the_v_in_scope blah
> > where (the_v_in_scope:_) = [ v | (n,v) <- env, n==target ]
>
> Or how abo
On 11/15/06, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote:
Yes, these techniques are fairly well known now, and hopefully some ofthe more experienced Haskellers are using them (I certainly use thenon-empty list tricks). Any anyone with more than 6 months Haskell knows
to avoid fromJust.The proble
"Neil Mitchell" <[EMAIL PROTECTED]> writes:
> Hi
>
> Haskell is great for equational reasoning.
>
> > blah the_v_in_scope blah
> > where (the_v_in_scope:_) = [ v | (n,v) <- env, n==target ]
>
> This piece of code isn't.
Strange. It's semantically the same, isn't it? Indeed, the
definition of
On Nov 15, 2006, at 9:48 AM, Jón Fairbairn wrote:
Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
| The problem I see is that head/fromJust errors are usually
|caused by *beginner* Haskellers, who don't know the
|techniques for statically avoiding them.
I don't agree. My programs have invari
Lennart Augustsson <[EMAIL PROTECTED]> writes:
> Should Haskell also provide unrestricted side effects, setjmp/
> longjmp, missile launching functions, etc? After all, people who
> don't want to use them can just avoid them. :)
Yes.
It is indeed a common problem that programs have unintended be
Hi
Haskell is great for equational reasoning.
blah the_v_in_scope blah
where (the_v_in_scope:_) = [ v | (n,v) <- env, n==target ]
This piece of code isn't. If you used head then you could trivially
inline the_v_in_scope, this way is a lot harder. You might spot a
pointfree pattern and lift i
Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
> | The problem I see is that head/fromJust errors are usually
> |caused by *beginner* Haskellers, who don't know the
> |techniques for statically avoiding them.
>
> I don't agree. My programs have invariants that I can't
> always express in a way t
Hello Lennart,
Wednesday, November 15, 2006, 3:37:34 PM, you wrote:
> Should Haskell also provide unrestricted side effects, setjmp/
> longjmp, missile launching functions, etc? After all, people who
> don't want to use them can just avoid them. :)
these are documented in "tackling the awkwa
Donald Bruce Stewart wrote:
> So how do we help out the beginners, other than warning about fromJust,
> and providing a useful error message as we can, for when they just go
> ahead and use head anyway?
Kill head and tail right now and provide a safe equivalent? Either
uncons :: [a] -> Maybe (
Hi
Should Haskell also provide unrestricted side effects, setjmp/
longjmp, missile launching functions, etc? After all, people who
don't want to use them can just avoid them. :)
Fair point. But if you eliminate incomplete cases, and the error
function, you'd probably need to increase the powe
| Looks good! But that is deceiving: the assert was expanded before the rule
| fired, and refers to the rewrite rule source line (line 19), not the fromJust
| call site (line 12). Now if we could just have the 'assert' token inserted
| into the AST before it was expanded, we'd be home and dry. Cou
On Wed, Nov 15, 2006 at 09:04:01AM +, Simon Peyton-Jones wrote:
> I don't agree. My programs have invariants that I can't always express
> in a way that the type system can understand. E.g. I know that a
> variable is in scope, so searching for it in an environment can't fail:
> head [
Should Haskell also provide unrestricted side effects, setjmp/
longjmp, missile launching functions, etc? After all, people who
don't want to use them can just avoid them. :)
On Nov 15, 2006, at 05:07 , Neil Mitchell wrote:
Hi
Yes, these techniques are fairly well known now, and hopefully
Hi
Yes, these techniques are fairly well known now, and hopefully some of
the more experienced Haskellers are using them (I certainly use the
non-empty list tricks). Any anyone with more than 6 months Haskell knows
to avoid fromJust.
I'm not, I use fromJust all the time. Ditto for head, init,
| > The fromJust and `head of empty list' errors are totally equivalent to
| > the dereferencing of zero pointer in C++ or NullPointerException in
| > Java. It pains me to see that exactly the same problem arises in
| > Haskell -- keeping in mind that already in C++ and Java one may
| > exterminate
oleg:
>
> Donald Bruce Stewart wrote:
> > So all this talk of locating head [] and fromJust failures got me
> > thinking:
> >
> > Couldn't we just use rewrite rules to rewrite *transparently*
> > all uses of fromJust to safeFromJust, tagging the call site
> > with a location?
>
> I'm
Donald Bruce Stewart wrote:
> So all this talk of locating head [] and fromJust failures got me
> thinking:
>
> Couldn't we just use rewrite rules to rewrite *transparently*
> all uses of fromJust to safeFromJust, tagging the call site
> with a location?
I'm sorry for shifting the top
34 matches
Mail list logo