A Pointless Library Proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Samuel Bronson
On 10/24/06, Russell O'Connor <[hidden email]> wrote:
> Conor McBride <ctm <at> Cs.Nott.AC.UK> writes:
>
> > Elements of Zero are rather special, powerful things.
> >
> > > magic :: Zero -> a
> > > magic _ = error "There's magic, as no such thing!"
>
> Why have a function body at all?  Shouldn't the type signature be sufficent?

Remember that type signatures need not be adjacent to function
definitions. Now ponder what would happen if you forgot to define a
function. Have a clue why it isn't sufficient now?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

roconnor
Samuel Bronson <naesten <at> gmail.com> writes:

> On 10/24/06, Russell O'Connor <roconnor <at> theorem.ca> wrote:
> > Why have a function body at all?  Shouldn't the type signature be sufficent?
>
> Remember that type signatures need not be adjacent to function
> definitions. Now ponder what would happen if you forgot to define a
> function. Have a clue why it isn't sufficient now?

If you turn on -Wall in GHC, you would get a warning that your pattern coverage
is incomplete.  We should make it so that if the pattern coverage is incomplete
and there is no function body, then that is an error.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

(functions without bodies) Re: A Pointless Library Proposal

Christian Maeder
Russell O'Connor schrieb:

> Samuel Bronson <naesten <at> gmail.com> writes:
>
>> On 10/24/06, Russell O'Connor <roconnor <at> theorem.ca> wrote:
>>> Why have a function body at all?  Shouldn't the type signature be sufficent?
>> Remember that type signatures need not be adjacent to function
>> definitions. Now ponder what would happen if you forgot to define a
>> function. Have a clue why it isn't sufficient now?
>
> If you turn on -Wall in GHC, you would get a warning that your pattern coverage
> is incomplete.  We should make it so that if the pattern coverage is incomplete
> and there is no function body, then that is an error.

You mean a warning for a completely missing body, don't you?

I'ld find type signatures of functions only perfect for specification
purposes. Some time ago I even submitted a feature request.

http://hackage.haskell.org/trac/ghc/ticket/393

Christian
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Conor McBride
In reply to this post by roconnor
Hi

Russell O'Connor wrote:
> Samuel Bronson <naesten <at> gmail.com> writes:
>
>  
>> On 10/24/06, Russell O'Connor <roconnor <at> theorem.ca> wrote:
>>    
>>> Why have a function body at all?  Shouldn't the type signature be sufficent?
>>>      

Hmmm

>> Remember that type signatures need not be adjacent to function
>> definitions. Now ponder what would happen if you forgot to define a
>> function. Have a clue why it isn't sufficient now?
>>    
>
> If you turn on -Wall in GHC, you would get a warning that your pattern coverage
> is incomplete.  We should make it so that if the pattern coverage is incomplete
> and there is no function body, then that is an error.
>  

So, taking Void to be the colour of the empty bikeshed and

  avoid :: Void -> x

suppose I define

  data WrapVoid = Wrap Void

may I now write

  boo :: WrapVoid -> x

with no equations? Does this cover? Or does it neglect the crucial boo
(Wrap _|_) case?

What about

  hoo :: Void -> Bool -> x

? Does this cover, or did I forget hoo v True and hoo v False?

Funny business, coverage checking. With GADTs, things become even more
entertaining...

All the best

Conor

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

roconnor
Conor McBride <ctm <at> cs.nott.ac.uk> writes:

> So, taking Void to be the colour of the empty bikeshed and
>
>   avoid :: Void -> x
>
> suppose I define
>
>   data WrapVoid = Wrap Void
>
> may I now write
>
>   boo :: WrapVoid -> x
>
> with no equations? Does this cover? Or does it neglect the crucial boo
> (Wrap _|_) case?

It would be considered ``covered''; however you may, at your option, wish to add
function body to handle (Wrap x).
 
> What about
>
>   hoo :: Void -> Bool -> x
>
> ? Does this cover, or did I forget hoo v True and hoo v False?

This is considered covered, but again you may, at your option, wish to add a
function body to handle the hoo v True and hoo v False cases.

Basically we considered all the cases covered if they are covered for all
non-bottom values.  This is (I understand) what the warning in GHC does.

I would also be willing to consider Christian Maeder's proposal where a missing
function body is never an error.




_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Conor McBride
Hi again

[editing slightly]

Russell O'Connor wrote:

> Conor McBride <ctm <at> cs.nott.ac.uk> writes:
>  
>> may I now write
>>
>>   boo :: WrapVoid -> x
>>   hoo :: Void -> Bool -> x
>>
>> with no equations?
> It would be considered ``covered''; however you may, at your option, wish to add
> function body to handle (Wrap x).
>  
> This is considered covered, but again you may, at your option, wish to add a
> function body to handle the hoo v True and hoo v False cases.
>  

Hmmm. For GADTs, I fear that this coverage checking problem may be
undecidable. To see why, check page 179 of my PhD thesis, although the
result (due to Gerard Huet, I believe) was certainly known to Thierry
Coquand in 1992. But...

> Basically we considered all the cases covered if they are covered for all
> non-bottom values.  This is (I understand) what the warning in GHC does.
>  

...isn't (Wrap _|_) a non-bottom value? Doesn't

  moo (Wrap v) = True

distinguish (Wrap _|_) from _|_ ?

If you're willing to tolerate the need to cover these cases, coverage
checking becomes decidable! Of course, it leaves you wondering what to
write on the right-hand side...

> I would also be willing to consider Christian Maeder's proposal where a missing
> function body is never an error.
>  

I'd be more comfortable with a more explicit way to leave a stub, but I
agree that there should be a way to indicate 'unfinished' which is
distinct from 'defined to be _|_'.

Moreover, I should very much like to have a token I can write in the
place of an expression, such that on compilation, I receive a diagnostic
giving me as much type information as possible about what must replace
the token. When you try the old trick of making a deliberate type error
to achive this effect, you often get less back than you might hope. Fine
for genuine errors, but not enough to satisfy the ulterior motive.

Cheers

Conor

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Jason Dagit-2
On 10/25/06, Conor McBride <[hidden email]> wrote:
[snippage]

> Moreover, I should very much like to have a token I can write in the
> place of an expression, such that on compilation, I receive a diagnostic
> giving me as much type information as possible about what must replace
> the token. When you try the old trick of making a deliberate type error
> to achive this effect, you often get less back than you might hope. Fine
> for genuine errors, but not enough to satisfy the ulterior motive.

I often want something similar but just a hair different.  Sometimes I
going along writing some code and I need a function or some monadic
action but maybe I don't want to think yet how to define it.  So I'll
stick in the name of the function as a place holder, then quickly
define the function to be undefined.  This way I can try to compile my
program to make sure all the defined code has the right types.  This
trick becomes even handier with Visual Haskell since it only displays
type information if the whole module type checks.

The obvious problem is that I may go off and forget to finish defining
that undefined function.  It would be nice if the compiler could say,
"Oh, don't forget to finish writing that function stub!".  In fact,
maybe the special token in this case could be stub :: a, that is just
designed to pass type checking and give an error as late in the
compilation as possible.  Hmm...maybe stub could be defined using some
TH...Although, the error may still happen too soon.  Ideally it would
happen after all the relevant modules have been type checked.

Jason
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Bugzilla from robdockins@fastmail.fm
In reply to this post by Conor McBride
On Oct 25, 2006, at 5:24 AM, Conor McBride wrote:

> Hi again
>
> [editing slightly]
>
> Russell O'Connor wrote:
>> Conor McBride <ctm <at> cs.nott.ac.uk> writes:
>>
>>> may I now write
>>>
>>>   boo :: WrapVoid -> x
>>>   hoo :: Void -> Bool -> x
>>>
>>> with no equations?
>> It would be considered ``covered''; however you may, at your  
>> option, wish to add
>> function body to handle (Wrap x).
>>   This is considered covered, but again you may, at your option,  
>> wish to add a
>> function body to handle the hoo v True and hoo v False cases.
>>
>
> Hmmm. For GADTs, I fear that this coverage checking problem may be  
> undecidable. To see why, check page 179 of my PhD thesis, although  
> the result (due to Gerard Huet, I believe) was certainly known to  
> Thierry Coquand in 1992. But...
>
>> Basically we considered all the cases covered if they are covered  
>> for all
>> non-bottom values.  This is (I understand) what the warning in GHC  
>> does.
>>
>
> ...isn't (Wrap _|_) a non-bottom value? Doesn't
>
>  moo (Wrap v) = True
>
> distinguish (Wrap _|_) from _|_ ?
>
> If you're willing to tolerate the need to cover these cases,  
> coverage checking becomes decidable! Of course, it leaves you  
> wondering what to write on the right-hand side...
>
>> I would also be willing to consider Christian Maeder's proposal  
>> where a missing
>> function body is never an error.
>>
>
> I'd be more comfortable with a more explicit way to leave a stub,  
> but I agree that there should be a way to indicate 'unfinished'  
> which is distinct from 'defined to be _|_'.


I'd have to say that all we really need for the original problem is a  
case statement with no arms.  eg,


data Void

void :: Void -> a
void x = case x of {}


However, I feel this whole conversation is pretty academic because

void x = undefined

has exactly the same semantics, and

void x = x `seq` undefined

will even have pretty much the same operational behavior.  I agree  
that being able to directly implement the Void catamorphism is  
appealing, I just don't think it makes a big practical difference.


I would not at all like to see the ability to define functions by  
just writing type signatures.

> Moreover, I should very much like to have a token I can write in  
> the place of an expression, such that on compilation, I receive a  
> diagnostic giving me as much type information as possible about  
> what must replace the token. When you try the old trick of making a  
> deliberate type error to achive this effect, you often get less  
> back than you might hope. Fine for genuine errors, but not enough  
> to satisfy the ulterior motive.
>
> Cheers
>
> Conor


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

David Menendez
In reply to this post by Conor McBride
Conor McBride writes:

> > magic :: Zero -> a
> > magic _ = error "There's magic, as no such thing!"
>
> It's a little frustrating to have to define this function lazily. I
> prefer the strict definition with no lines, but it isn't valid
> Haskell!

I think you could avoid that frustration by defining Zero/Void/Bikeshed
liko so:

    newtype Void = Void { avoid :: forall a. a }

That gets you a strictly defined avoid and emphasizes that Void is
isomorphic to (forall a. a).



On a semi-related note, how about instances for the Prelude classes?

For example,
   
    instance Show Void where
        show = avoid
   
    instance Read Void where
        readsPrec _ _ = []

    instance Eq Void where
        a == b = avoid a
   
    instance Ord Void where
        compare a b = avoid a

Enum and Bounded are out, because they have methods which produce
values, but Data and Typeable instances might be reasonable.
--
David Menendez <[hidden email]> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Conor McBride
Hi

David Menendez wrote:

> Conor McBride writes:
>
>  
>>> magic :: Zero -> a
>>> magic _ = error "There's magic, as no such thing!"
>>>      
>> It's a little frustrating to have to define this function lazily. I
>> prefer the strict definition with no lines, but it isn't valid
>> Haskell!
>>    
>
> I think you could avoid that frustration by defining Zero/Void/Bikeshed
> liko so:
>
>     newtype Void = Void { avoid :: forall a. a }
>
> That gets you a strictly defined avoid and emphasizes that Void is
> isomorphic to (forall a. a).
>  

Aha, the Church Void! That's a neat way of doing it under the
circumstances. The datatype with no constructors issue will show up
again with GADTs, but this is a sensible way to postpone it.

I guess (to answer Rob Dockins) that it's not the number of lines I'm
bothered by, but rather the invocation of 'undefined', 'error' or some
other signal of /underdefinition/ to present a function which is
entirely well-defined, indeed trivially so. This may seem academic, but
with types being used increasingly in their role as evidence, we'll
eventually need to be comfortable with negative information as well as
positive.

> On a semi-related note, how about instances for the Prelude classes?
>
> For example,
>    
>     instance Show Void where
>         show = avoid
>    
>     instance Read Void where
>         readsPrec _ _ = []
>
>     instance Eq Void where
>         a == b = avoid a
>    
>     instance Ord Void where
>         compare a b = avoid a

Absolutely! It's not a joke. Some notion of Zero (and here's really why
I like Zero) is very useful if you're doing algebra, let alone calculus
with data structures. Given how many of our favourite datatypes are
fixpoints of polynomial functors, with Show, Eq, etc, it's important
that each of the building blocks of polynomials is closed under these
things. You might not often need to use a Zero in the polynomial
datatypes you define, but it's useful to have Zero if you're calculating
one polynomial from another. I want to get for free that if my datatype
has polynomial nodes, its type of one-hole contexts is showable.

All the best

Conor

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

John Meacham
In reply to this post by David Menendez
On Thu, Oct 26, 2006 at 02:11:18AM -0400, David Menendez wrote:
> Enum and Bounded are out, because they have methods which produce
> values, but Data and Typeable instances might be reasonable.

definitely! Most of the uses percolating through my brain involve Data
and Typeable instances.

of coures, I am of the opinion that _every_ type should automatically
get a Typeable instance. (but not Data obviously)

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: A Pointless Library Proposal

Simon Peyton Jones
In reply to this post by Conor McBride
| > magic :: Zero -> a
| > magic _ = error "There's magic, as no such thing!"
|
| It's a little frustrating to have to define this function lazily. I
| prefer the strict definition with no lines, but it isn't valid
| Haskell!

I've occasionally wondered about emitting a warning, but not an error,
when there's a type signature for a function but no definition. The
compiler could automatically generate an error message stub
implementation, much as it does for an incomplete pattern match, of
which this is an extreme example.

If anyone is keen on this, pls create a Trac feature request, and fill
out the details (e.g. what flags, what should the warning look like..).
Better still do that, and submit a patch!

Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Ben Rudiak-Gould
In reply to this post by Ashley Yakeley
Ashley Yakeley wrote:
>   data MyGADT a where
>     MyInt :: MyGADT Int
>     MyChar :: MyGADT Char
>
>   never :: MyGADT Bool -> a
>
> Annoyingly, this doesn't compile without adding a definition line
> mentioning a bottom value.

This can't be fixed because the desugaring is ambiguous. never might be _|_
or \x. _|_ or \x y. _|_ or ...

How about

   never :: MyGADT Bool -> a
   never x = case x of {}

which is just the desugared form of your intended empty definition? GHC
doesn't allow it, but it would be a simple extension.

-- Ben

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Ben Rudiak-Gould
In reply to this post by Simon Peyton Jones
Simon Peyton-Jones wrote:
> I've occasionally wondered about emitting a warning, but not an error,
> when there's a type signature for a function but no definition. The
> compiler could automatically generate an error message stub
> implementation, much as it does for an incomplete pattern match, of
> which this is an extreme example.

I don't like this idea because the necessary stub is different for different
numbers of arguments, and there's no way to tell how many arguments the
programmer intended. I do like the idea of allowing empty case expressions,
though, and I don't think that even a warning would be necessary.

-- Ben

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: A Pointless Library Proposal

Simon Peyton Jones
| I don't like this idea because the necessary stub is different for
different
| numbers of arguments, and there's no way to tell how many arguments
the
| programmer intended.

Why?  What's wrong with expanding
        foo :: Int -> Int -> Int
into
        foo :: Int -> Int -> Int
        foo = error "foo is not yet implemented"

which is what I usually write by hand.

|I do like the idea of allowing empty case expressions,
| though, and I don't think that even a warning would be necessary.

So how would you define foo?  How would it be better than the above
(even if written by hand)?

Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Bugzilla from robdockins@fastmail.fm
In reply to this post by Ben Rudiak-Gould

On Oct 30, 2006, at 9:38 AM, Ben Rudiak-Gould wrote:

> Simon Peyton-Jones wrote:
>> I've occasionally wondered about emitting a warning, but not an  
>> error,
>> when there's a type signature for a function but no definition. The
>> compiler could automatically generate an error message stub
>> implementation, much as it does for an incomplete pattern match, of
>> which this is an extreme example.
>
> I don't like this idea because the necessary stub is different for  
> different numbers of arguments, and there's no way to tell how many  
> arguments the programmer intended. I do like the idea of allowing  
> empty case expressions, though, and I don't think that even a  
> warning would be necessary.


This opinion++



> -- Ben


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Lennart Augustsson
In reply to this post by Simon Peyton Jones
I like to use undefined is the stub for unimplemented functions since  
it's nice and terse.  Unfortunately, ghc doesn't give much  
information about where the undefined was called.
It would be great if the message for undefined could include file  
name and line number (like hbc did :).

        -- Lennart

On Oct 30, 2006, at 09:54 , Simon Peyton-Jones wrote:

> | I don't like this idea because the necessary stub is different for
> different
> | numbers of arguments, and there's no way to tell how many arguments
> the
> | programmer intended.
>
> Why?  What's wrong with expanding
> foo :: Int -> Int -> Int
> into
> foo :: Int -> Int -> Int
> foo = error "foo is not yet implemented"
>
> which is what I usually write by hand.
>
> |I do like the idea of allowing empty case expressions,
> | though, and I don't think that even a warning would be necessary.
>
> So how would you define foo?  How would it be better than the above
> (even if written by hand)?
>
> Simon
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Conor McBride
In reply to this post by Bugzilla from robdockins@fastmail.fm
Robert Dockins wrote:

>
> On Oct 30, 2006, at 9:38 AM, Ben Rudiak-Gould wrote:
>
>> Simon Peyton-Jones wrote:
>>> I've occasionally wondered about emitting a warning, but not an error,
>>> when there's a type signature for a function but no definition. The
>>> compiler could automatically generate an error message stub
>>> implementation, much as it does for an incomplete pattern match, of
>>> which this is an extreme example.
>>
>> I don't like this idea because the necessary stub is different for
>> different numbers of arguments, and there's no way to tell how many
>> arguments the programmer intended. I do like the idea of allowing
>> empty case expressions, though, and I don't think that even a warning
>> would be necessary.
>
>
> This opinion++

Yes, when I'm not being facetious, I'm inclined to think that some
syntax which represents the explicit dismissal of impossible input is
preferable to the mere absence of anything to deliver an output. Empty
case expressions are one possibility, but I'd also be pleased to see a
'definition form', ie some sort of pattern rejection, in the same way
that pattern equations give a neat definition form for nonempty case
analysis. Moreover, in the case of GADTs, if you want coverage checking,
you need something of the sort.

The key question, unless this is just a storm in a teacup in a bikeshed,
is how to distinguish underdefined programs from well-defined but
vacuous ones. To do the job properly, whatever syntax is used to reject
some element of an uninhabited datatype should be considered erroneous
if there is a constructor-pattern of that type in some context. That is
(if it's empty case)

  voo :: Void -> x
  voo v = case v of {}

should be fine, but

  boo :: Bool -> x
  boo b = case b of {}

should be rejected because True (and False) provide a case to answer.
Moreover, if we have

  data Overjoid = Joy Void
  woo :: Overjoid -> a
  woo x = case x of {}
  noo :: Overjoid -> a
  noo (Joy x) = case x of {}

then woo should be rejected but noo accepted.

I'd also like to see more support for stubs in code, by way of being
able to ask a compiler 'what more must I do here?', but I should also
prefer this to be more actively indicated than just by an empty space.

Artful silence may be alright for Samuel Beckett, but it strikes me a
dangerous way to be straightforward about what sort of nothing you mean.

All the best

Conor
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

John Meacham
In reply to this post by Lennart Augustsson
On Mon, Oct 30, 2006 at 10:16:46AM -0500, Lennart Augustsson wrote:
> I like to use undefined is the stub for unimplemented functions since  
> it's nice and terse.  Unfortunately, ghc doesn't give much  
> information about where the undefined was called.
> It would be great if the message for undefined could include file  
> name and line number (like hbc did :).

jhc has the SRCLOC_ANNOTATE pragma, which lets you attach file and line
number information to arbitrary functions. sort of a generalization of
the 'assert' feature of ghc. One day I will get around to implementing
it in ghc. perhaps the next time a program I write mysteriously dies
with "Prelude.undefined" being the only thing printed.

        John


--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: A Pointless Library Proposal

Donald Bruce Stewart
john:

> On Mon, Oct 30, 2006 at 10:16:46AM -0500, Lennart Augustsson wrote:
> > I like to use undefined is the stub for unimplemented functions since  
> > it's nice and terse.  Unfortunately, ghc doesn't give much  
> > information about where the undefined was called.
> > It would be great if the message for undefined could include file  
> > name and line number (like hbc did :).
>
> jhc has the SRCLOC_ANNOTATE pragma, which lets you attach file and line
> number information to arbitrary functions. sort of a generalization of
> the 'assert' feature of ghc. One day I will get around to implementing
> it in ghc. perhaps the next time a program I write mysteriously dies
> with "Prelude.undefined" being the only thing printed.

I've previously used assert for this,

For locating errors with line numbers:
    http://www.cse.unsw.edu.au/~dons/tmp/Exception.hs
and adding line numbers to 'trace'
    http://www.cse.unsw.edu.au/~dons/tmp/Location.hs

But seems like we need a 'proper' solution. undefineds with lines
numbers, and errors with line numbers, would be a good start.

-- Don
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123