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
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
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
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 every
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 errors we
could
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 = maybe
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, fromMaybe:
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
function,
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
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 topic:
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 sorry for
| 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
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,
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
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 [ v
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
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
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 awkward
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 that the
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
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
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
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 head gets you
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 problem
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 about ??
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 Haskell
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 invariant in
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', 'fromJust'
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
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
| 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.
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
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
33 matches
Mail list logo
