Re: [haskell-cafe] Monad and kinds
On 9/4/08, John Dorsey [EMAIL PROTECTED] wrote: I'm no master either, but I'd argue that if we promise new programmers that they don't need to care about strictness, we thereby ensure that default laziness is treacherous. A year or two ago, ISTR that *most* of the newbie-generated traffic in the cafe was about atrocious performance of naive programs due to strict/lazy concerns. I think it was scaring people away. I think it's debatable what the various causality relationships might be here. Adding strictness can improve asymptotic space performance, as an example. Is there a reason to think this won't always be true? Honest question, since I don't know nearly enough about strictness analysis to guess how good it'll be some day. Adding strictness can also worsen asymptotic space (and time) performance. That's one reason why we use a lazy language at all. Strictness analysis is an approximation to the problem of determining what parts of a program can be evaluated strictly without changing their meaning, because if we had a perfect solution to that problem, we could solve the halting problem. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt There are no difficult problems, just unfortunate notations. -- Alfonso Gracia-Saz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
Tim, A year or two ago, ISTR that *most* of the newbie-generated traffic in the cafe was about atrocious performance of naive programs due to strict/lazy concerns. I think it was scaring people away. I think it's debatable what the various causality relationships might be here. Certainly... Adding strictness can improve asymptotic space performance, as an example. Is there a reason to think this won't always be true? Honest question, since I don't know nearly enough about strictness analysis to guess how good it'll be some day. Adding strictness can also worsen asymptotic space (and time) performance. That's one reason why we use a lazy language at all. Strictness analysis is an approximation to the problem of determining what parts of a program can be evaluated strictly without changing their meaning, because if we had a perfect solution to that problem, we could solve the halting problem. No argument. I was responding to your comment that ... IMO, arguing that programmers should care at all amounts to conceding that default laziness is treacherous. ... which sounds like you're arguing against programmers giving due attention to lazy/strict choices. I was suggesting that there is good reason to think that we should pay attention to it; that it's a necessary part of learning Haskell; and that it will likely remain so. Newbies should be encouraged to think and experiment more with laziness and strictness. Regards, John (pondering an IDE mode for visualizing strictness properties) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: Sittampalam, Ganesh wrote: Oh dear. To fix this, I suppose the RTS would have to be able to keep track of all static initialisers. But it shouldn't otherwise affect program optimisation. What would the RTS actually do? I don't know enough about the RTS to say. I imagine initialisers would have to be marked in object files, so the RTS could link them separately when dynamically loading. The RTS would also keep a list of initialisers in the main program. Sounds plausible, although dynamic relocations do slow down linking. Unloading is another interesting problem. Are we allowed to re-run - if the module that contained it is unloaded and then reloaded? I'm not quite sure what the conditions for allowing a module to be unloaded in general should be, though. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
Jake Mcarthur wrote: On Sep 4, 2008, at 9:52 PM, Tim Chevalier wrote: I'm no master, but I've never encountered a situation where strictness annotations would be useful as documentation, nor can I imagine one. I'm no master either, but how about these simple examples? data Stream a = Cons !a (Stream a) data Vector3 a = Vector3 !a !a !a The compiler will certainly be able to infer the strictness itself in most uses, so obviously the purpose for these annotations is not for optimization, but I still would find these annotations useful. As far as I am aware this statement is false. I do not believe the compiler infers strictness in common uses of either of these cases, and I have seen space blowups / stack blowups because of it. I use the rule of thumb : simple 'scalar' field components should be strict. Scalar is an ill-defined term but typically means non-recursive data types, like Int and Bool. The most natural exception to this rule is the 'memoizing constructor' idiom. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
Jules Bean [EMAIL PROTECTED] writes: On Sep 4, 2008, at 10:19 AM, Tim Chevalier wrote: The master programmer does not add strictness annotations, for she has not yet run the profiler. The compiler will certainly be able to infer the strictness itself As far as I am aware this statement is false. The master programmer does not add strictness annotations, she improves the strictness analyser. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
You should package this up and put it on hackage. It is nice, but there is already another FRef package on hackage (Data.Accessor) and I have a home-grown one of my own, which uses different notation / combinators to either the hackage one or Tim's. There are also fragments of FRef-like things in some of the big libraries like OpenGL and GTK. I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Top Level -
Sittampalam, Ganesh wrote: Sounds plausible, although dynamic relocations do slow down linking. Unloading is another interesting problem. Are we allowed to re-run - if the module that contained it is unloaded and then reloaded? I'm not quite sure what the conditions for allowing a module to be unloaded in general should be, though. Interesting question. I suppose it's allowable if the guarantees attached to the ACIO type imply that it would not be possible to tell the difference. I think this means that all values of types, including newtypes, belonging to the module must be unreachable before unloading. Consider Data.Unique as a separate loadable module. It's loaded, and various Unique values are obtained. But Unique is just a newtype of Integer, and comparison between Uniques doesn't use code from Data.Unique. This might be difficult to track as once the newtype is boiled away, the code is basically dealing with Integers, not Uniques. I really don't know enough about the RTS to know. The alternative would be to keep all initialised values when the module is unloaded. I'm guessing this is more feasible. -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] Top Level -
Ashley Yakeley wrote: I really don't know enough about the RTS to know. The alternative would be to keep all initialised values when the module is unloaded. I'm guessing this is more feasible. Easier, but a guaranteed memory leak. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters
In the online version of Real world Haskell, there's a problem with examples in ghci when the module Database.HDBC.Sqlite3 is imported. It goes on like this for all of chapter 21 and 22. Example : ( note: this is not me trying to reproduce the examples, it's an actual copy paste from the site url http://book.realworldhaskell.org/read/using-databases.html ) ghci :module Database.HDBC Database.HDBC.Sqlite3 Could not find module `Database.HDBC.Sqlite3': Use -v to see a list of the files searched for. ghci conn - connectSqlite3 test1.db interactive:1:8: Not in scope: `connectSqlite3' ghci :type conn interactive:1:0: Not in scope: `conn' ghci disconnect conn interactive:1:0: Not in scope: `disconnect' interactive:1:11: Not in scope: `conn' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters
See John's comment, right there in the online version: The system that generated this webpage didn't have HDBC installed at the time. We'll get that fixed and re-post this chapter. In the meantime, unfortunately, all of the examples on this page will look that way. david48 wrote: In the online version of Real world Haskell, there's a problem with examples in ghci when the module Database.HDBC.Sqlite3 is imported. It goes on like this for all of chapter 21 and 22. Example : ( note: this is not me trying to reproduce the examples, it's an actual copy paste from the site url http://book.realworldhaskell.org/read/using-databases.html ) ghci :module Database.HDBC Database.HDBC.Sqlite3 Could not find module `Database.HDBC.Sqlite3': Use -v to see a list of the files searched for. ghci conn - connectSqlite3 test1.db interactive:1:8: Not in scope: `connectSqlite3' ghci :type conn interactive:1:0: Not in scope: `conn' ghci disconnect conn interactive:1:0: Not in scope: `disconnect' interactive:1:11: Not in scope: `conn' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters)
Now that is real world - problems even before release!-)
Seriously, though, what is the RWH authors' plan for tackling
the eternal frustration of Haskell book authors, a moving target?
There used to be a time when one could guess the poster's
Haskell book from their question topics:
- 'HGL' doesn't work: Hudak's book
- 'fromInt' issues: Thompson's book
The problem arises because the books survive far longer than
the version of the code base they refer to. The only way to reduce
this friction has been to avoid fast-changing details, eg, focussing
on programming, problem solving, reasoning (Hutton, Thompson,
Bird), and even that isn't safe ('n+k', 'fromInt',..). Neither is
keeping a separate library - 'SOEGraphics' has been revived
several times, on different GUI/graphic libs, even different Haskell
implementations, but has always fallen prey to bitrot again.
I've only scanned RWH briefly, but it seems to be on the other
end of the spectrum, focussing precisely on the details of stuff
that is likely to evolve much faster than the book. Is the plan to
keep someone employed over the years to keep the online
version updated?
Claus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters)
On Fri, 2008-09-05 at 13:04 +0100, Claus Reinke wrote:
Now that is real world - problems even before release!-)
Seriously, though, what is the RWH authors' plan for tackling
the eternal frustration of Haskell book authors, a moving target?
There used to be a time when one could guess the poster's
Haskell book from their question topics:
- 'HGL' doesn't work: Hudak's book
- 'fromInt' issues: Thompson's book
The problem arises because the books survive far longer than
the version of the code base they refer to. The only way to reduce
this friction has been to avoid fast-changing details, eg, focussing
on programming, problem solving, reasoning (Hutton, Thompson,
Bird), and even that isn't safe ('n+k', 'fromInt',..). Neither is
keeping a separate library - 'SOEGraphics' has been revived
several times, on different GUI/graphic libs, even different Haskell
implementations, but has always fallen prey to bitrot again.
There are currently two independent working implementations
of SOEGraphics on GUI libs that are maintained. I think it'll probably
be ok.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters)
On Fri, Sep 05, 2008 at 01:04:03PM +0100, Claus Reinke wrote:
Seriously, though, what is the RWH authors' plan for tackling
the eternal frustration of Haskell book authors, a moving target?
There used to be a time when one could guess the poster's
Haskell book from their question topics:
- 'HGL' doesn't work: Hudak's book
- 'fromInt' issues: Thompson's book
The problem arises because the books survive far longer than
the version of the code base they refer to. The only way to reduce this
friction has been to avoid fast-changing details, eg, focussing on
programming, problem solving, reasoning (Hutton, Thompson,
Bird), and even that isn't safe ('n+k', 'fromInt',..).
One of the specific aims of Haskell 98 was to provide a stable base
for authors. It did not include fromInt, which was an internal quirk
of the Hugs implementation, and nor did any other Haskell implementation.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters)
On Fri, Sep 05, 2008 at 01:04:03PM +0100, Claus Reinke wrote: Now that is real world - problems even before release!-) Seriously, though, what is the RWH authors' plan for tackling the eternal frustration of Haskell book authors, a moving target? Hope that enough copies are sold that O'Reilly lets us make a 2nd edition when things change? :-) More seriously, you do the best you can. We tried to mostly write about things that are in the libraries that ship with GHC. There are some exceptions, such as HDBC and gtk2hs. But these things happen in any language, and you publish errata, or a new edition. We've already been bitten by this, and we're not even in production yet. The regex library included with GHC 6.8.3 can be used in a [String] context, but the newer regex library on Hackage (which is shipped by Debian) can't. Doh. I've only scanned RWH briefly, but it seems to be on the other end of the spectrum, focussing precisely on the details of stuff that is likely to evolve much faster than the book. Is the plan to keep someone employed over the years to keep the online version updated? We haven't specifically discussed that, but in general, doing a book is a *lot* of work, and I suspect all three of us will be wanting to take a break from book-writing or -maintaining activities for a bit after O'Reilly starts cutting down trees on our behalf. That said, we're still maintaining all the infrastructure for the project, so we could go and update things at any time. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Reducing code for efficient ShowS
It happens very often that I want to convert a number of values to strings
and
concatenate those strings into one. No surprise there, of course. Well, I'd
prefer to do it efficiently and with as little code as necessary.
{-# LANGUAGE TypeSynonymInstances #-}
module ShowsDemo where
Let's say I want to generate the string (42 abc) starting with a number
and a
string stored in variables.
n = 42 :: Int
s = abc
What are my options?
There's the obvious approach that's described in every tutorial, book, and
research paper (for didactic purposes, of course).
ex1 = ( ++ show n ++ ++ s ++ )
It's pretty concise, but it's horribly inefficient due to the use of (++).
Then, there's the ShowS approach.
ex2 = showChar '(' . shows n . showChar ' ' . showString s . showChar ')'
$
This is more efficient, but now the code has bloated up a lot.
Why can't I have my cake and eat it, too? I want to write with as little
code as
|ex1| (or less if possible), and I want it to be as efficient as |ex2|.
I propose this example as an improvement.
ex3 = '(' .+. n .+. ' ' .+. s .$. ')'
It uses a class I'm calling |Shows|. The class has one method that simply
converts a value to the type |ShowS|, where |ShowS| is a type synonym for
|String - String| and is defined in the Prelude.
class Shows a where
toShows :: a - ShowS
Notice the lack of context involving the |Show| class. That's important,
because
it allows us to create more instances than we could if we were restricted by
|(Show a) = ...|, esp. the |ShowS| instance below.
The instances for types are all very simple. Most will appear like the
instance
for |Int|.
instance Shows Int where
toShows = shows
Since we don't have |Show| in the class context above, we can't make this a
default method.
We need a few special instances for |Char| and |String| to make these types
convenient to use in the expected way.
instance Shows Char where
toShows = showChar
instance Shows String where
toShows = showString
We also need an instance for |ShowS| in order to facilitate concatenation.
instance Shows ShowS where
toShows = id
Now, we define a few operators that use |toShows| and make our lives easier
and
our code more concise.
The |(.+.)| replaces list appending, |(++)|, in |ex1| and function
composition,
|.|, in |ex2|.
infixl 5 .+.
(.+.) :: (Shows a, Shows b) = a - b - ShowS
a .+. b = toShows a . toShows b
The |(.$.)| replaces the need for |($)| in |ex2|.
infixl 4 .$.
(.$.) :: (Shows a, Shows b) = a - b - String
a .$. b = (a .+. b)
I would find something like this very useful. I'm guessing the idea can be
applied to |ByteString| as well. Does it exist in some other form?
Sean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Consequences of implementing a library in Haskell for C consumption?
On Thu, Sep 04, 2008 at 08:04:25PM -0500, Austin Seipp wrote: Excerpts from Justin Bailey's message of Thu Sep 04 17:00:58 -0500 2008: Looking at the package, I think would be pretty painful though. It seems I'd have to build the AST by hand, The AST Language.C defines for C is actually fairly regular once you wrap your head around it - I got it to generate working programs that I could compile in approximately an hour after looking through nothing but the documentation, essentially. The AST is very 'raw' though: I found that defining some simple functions for things like just creating a global variable, creating declarations and the like cut down on overall AST size tremendously (although hints of the AST types/constructors were still around, naturally.) Here's the example I put on HPaste a few days ago: http://hpaste.org/10059#a1 You'll notice that the actual shim you're looking at - with the help of the defined functions - is actually fairly small, and those functions help out with those *a lot.* That was the first thing I wrote with it though, so the functions could probably be further generalized and abstracted. Nice. On that note (although a little OT,) does anybody think it would be nice to have a higher level library designed specifically around emitting C that uses Language.C? A lot of repetetive stuff can be cut down considerably, I think. That sounds great to me. I'd love to see something like this with some handy classes, so that I could write my haskell code using Int and/or Integer rather than CInt. e.g. change mkConst (ConInt i) = CConst $ CIntConst (cInteger i) undef mkConst (ConChar c) = CConst $ CCharConst (cChar c) undef mkConst (ConFloat f) = CConst $ CFloatConst (readCFloat f) undef mkConst (ConStr s) = CConst $ CStrConst (cString s) undef to class CConst i where mkConst i :: ??? instance CConst Int instance CConst Double etc. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters)
On Fri, Sep 5, 2008 at 5:04 AM, Claus Reinke [EMAIL PROTECTED] wrote: Seriously, though, what is the RWH authors' plan for tackling the eternal frustration of Haskell book authors, a moving target? Other tech books face the same problem, which, if they sell successfully and the authors haven't moved into caves afterwards to recover, they address with subsequent editions. If readers find that specific pieces of information have bitrotted, I'm sure we'll hear about it. In that case, we'll create a wiki page with errata, and link to it from the book site. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters
On Fri, Sep 5, 2008 at 3:45 AM, david48 [EMAIL PROTECTED] wrote: In the online version of Real world Haskell, there's a problem with examples in ghci when the module Database.HDBC.Sqlite3 is imported. Oops, should be fixed now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Functional references
I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. Indeed. I have my own version here: http://code.haskell.org/yi/Yi/Accessor.hs I'd rather use a standard package, but I could not contact the author of the data-accessor package to join efforts. Cheers -- JP ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
On Fri, 5 Sep 2008, Jules Bean wrote: I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. This sounds like a good plan, but please make sure the result is as free as GHC, rather than GPL like data-accessor is. It's so simple that it being GPL just drives people for whom licencing is an issue to write an alternative rather than consider complying. Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Functional references
Jean-Philippe Bernardy wrote: I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. Indeed. I have my own version here: http://code.haskell.org/yi/Yi/Accessor.hs I'd rather use a standard package, but I could not contact the author of the data-accessor package to join efforts. I too have a home-rolled version nearly identical to this one. The only real difference is using a (whole - part - whole) modifier instead of ((part - part) - whole - whole) in the dictionary type. That decision was salient for my particular uses, but on the whole I like the Yi.Accessor approach better. For an official API, I think a (setter = modifier . const) function would be helpful for brevity and clarity. The other difference, in terms of API, is I was using names theX and resetX rather than getter and modifier (I also have a setX which requires a class declaring an emptyX value for the whole type). I'm not too invested in my particular names, but I think having something short which isn't too evocative of the StateMonad is important. The reason I think it shouldn't be too evocative of State is that the functions are pure and keeping their names distinct gives a good mnemonic to remember which ones are State-ful and which ones are pure. Tim Newsham's approach with invertible functions is interesting, though it feels like it's another layer wrapped on top of the primitive idea of functional references. My code also had an extra layer lifting the explicit dictionaries into type class dictionaries. This was helpful for writing functions which are polymorphic over the state type, though it suffers from the limitation that you can only have a single accessor for each part type in a given whole type. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Top Level -
Sittampalam, Ganesh wrote: Ashley Yakeley wrote: I really don't know enough about the RTS to know. The alternative would be to keep all initialised values when the module is unloaded. I'm guessing this is more feasible. Easier, but a guaranteed memory leak. But it's limited to the initialisers. An IORef holding an Integer isn't much memory, and it only ever gets leaked once. -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reducing code for efficient ShowS
Sean Leather wrote:
There's the obvious approach that's described in every tutorial, book, and
research paper (for didactic purposes, of course).
ex1 = ( ++ show n ++ ++ s ++ )
It's pretty concise, but it's horribly inefficient due to the use of (++).
Then, there's the ShowS approach.
ex2 = showChar '(' . shows n . showChar ' ' . showString s . showChar ')'
$
This is more efficient, but now the code has bloated up a lot.
Why can't I have my cake and eat it, too? I want to write with as little
code as
|ex1| (or less if possible), and I want it to be as efficient as |ex2|.
I propose this example as an improvement.
ex3 = '(' .+. n .+. ' ' .+. s .$. ')'
Why not use the dlist library:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist
With something like (untested code):
xs +++ ys = showsxs `append` showsys
x .++ ys = showChar x `cons` showsys
xs ++. y = showsxs `snoc` showChar y
ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')'
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top Level -
On Fri, 5 Sep 2008, Ashley Yakeley wrote: Sittampalam, Ganesh wrote: Ashley Yakeley wrote: I really don't know enough about the RTS to know. The alternative would be to keep all initialised values when the module is unloaded. I'm guessing this is more feasible. Easier, but a guaranteed memory leak. But it's limited to the initialisers. An IORef holding an Integer isn't much memory, and it only ever gets leaked once. It happens every time you load and unload, surely? Also I thought this was a general discussion with Data.Unique as a concrete example; something else might leak substantially more memory. Your witnesses stuff would leak one Integer per module, wouldn't it? Finally, any memory leak at all can be unacceptable in some contexts. It's certainly not something we should just dismiss as oh, it's only small. Cheers, Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online RealWorld Haskell, problem with Sqlite3 chapters)
Seriously, though, what is the RWH authors' plan for tackling the eternal frustration of Haskell book authors, a moving target? Other tech books face the same problem, which, if they sell successfully and the authors haven't moved into caves afterwards to recover, they address with subsequent editions. If readers find that specific pieces of information have bitrotted, I'm sure we'll hear about it. In that case, we'll create a wiki page with errata, and link to it from the book site. Just saying, it is worth planning for, especially if the book is going to be successful. I understand if creating that book at breakneck speed has left you looking forward to a break (not of the neck;-), but laying out a strategy for this, and putting it in the preface, might avoid sorrows later. You do have the online version and commenting system in place which you could keep around, you could even keep copies of the precise code versions you use, although adapting the text is more appropriate for this style of book. Thompson and Hudak both have had home pages for their books, but that didn't prevent their readers coming to the mailing lists instead, often frustrated at the beginning of their threads, sometimes disappointed at the end (in spite of a succession of strong Haskell hackers reviving SOE support again and again, there were gaps in between). And your book looks like it is going to suffer more, being completed before, but published after several changes (more base breakup, last time that extralibs come with ghc, haskell platform, extensible exceptions, ..) as well as being detailed and concrete about the use of several real-world libraries/tools subject to normal evolution. Anyway, good luck!-) Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
On Thu, 4 Sep 2008, Ryan Ingram wrote: Nice. I've written similar stuff a couple of times before, but the formulation using Maybe and modify definitely solves some problems I started to notice as I used it on bigger structures. However, it might be better to separate a class of never failing references, where the reader is guaranteed to succeed, from potentially failing references which give a Maybe value. I'd also not use the names get and modify because they are already used by MonadState.I always used frGet, frSet, and frModify, and then tended to not use them directly as I was generally working in a state monad. Haskell already supports qualification, why manual prefixing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Functional references
On Fri, 5 Sep 2008, Jean-Philippe Bernardy wrote: I think it would be worth spending some time (on this mailing list, perhaps, or in another forum) trying to hash out a decent API which meets most people's requirements, rather than ending up with 4 or 5 slightly different ones. Indeed. I have my own version here: http://code.haskell.org/yi/Yi/Accessor.hs I'd rather use a standard package, but I could not contact the author of the data-accessor package to join efforts. I had no problem contacting Luke Palmer and I have recently added my stuff to the package. See also http://www.haskell.org/haskellwiki/Record_access You may add the other existing packages for reference. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters)
On 2008 Sep 5, at 12:45, Bryan O'Sullivan wrote: On Fri, Sep 5, 2008 at 5:04 AM, Claus Reinke [EMAIL PROTECTED] wrote: Seriously, though, what is the RWH authors' plan for tackling the eternal frustration of Haskell book authors, a moving target? Other tech books face the same problem, which, if they sell successfully and the authors haven't moved into caves afterwards to recover, they address with subsequent editions. If readers find that Errata pages are common; as authors become more aware of the Internet, they often put updates in the same place. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online Real World Haskell, problem with Sqlite3 chapters)
allbery: On 2008 Sep 5, at 12:45, Bryan O'Sullivan wrote: On Fri, Sep 5, 2008 at 5:04 AM, Claus Reinke [EMAIL PROTECTED] wrote: Seriously, though, what is the RWH authors' plan for tackling the eternal frustration of Haskell book authors, a moving target? Other tech books face the same problem, which, if they sell successfully and the authors haven't moved into caves afterwards to recover, they address with subsequent editions. If readers find that Errata pages are common; as authors become more aware of the Internet, they often put updates in the same place. And our book is online already, and accepts comments :-) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reducing code for efficient ShowS
Why not use the dlist library:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist
With something like (untested code):
xs +++ ys = showsxs `append` showsys
x .++ ys = showChar x `cons` showsys
xs ++. y = showsxs `snoc` showChar y
ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')'
I think you're missing the fromList parts among other things.
That's an interesting idea. It appears to use the same idea as ShowS, but
more generally with lists and not just strings.
I think there's an added benefit to not having to remember the the type of
the value being appended. It's one of the more convenient things about many
dynamically typed languages. So, I would still vote for the class-based
method, so that I can use (.+.) for both Char and everything else.
Sean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reducing code for efficient ShowS
Sean Leather wrote:
Why not use the dlist library:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist
With something like (untested code):
xs +++ ys = showsxs `append` showsys
x .++ ys = showChar x `cons` showsys
xs ++. y = showsxs `snoc` showChar y
ext3' = toList $ '(' .++ n +++ ' ' .++ s ++. ')'
I think you're missing the fromList parts among other things.
Ah yes, dlist uses a newtype instead of an alias so `shows` isn't enough.
There's also the question of where exactly to hide the (Show a = a -
DList Char) conversions if you want to be more succinct than the (++)
route.
That's an interesting idea. It appears to use the same idea as ShowS, but
more generally with lists and not just strings.
The difference-list approach to solving the appending problem is classic.
There's a variant for unification-based logic languages as well. Both are
functional takes on the imperative approach of keeping a tail pointer.
Dons just took the time to package it up for us all :)
I think there's an added benefit to not having to remember the the type of
the value being appended. It's one of the more convenient things about many
dynamically typed languages. So, I would still vote for the class-based
method, so that I can use (.+.) for both Char and everything else.
Sure.
If you're planning on releasing the code, I'd suggest a different spelling
of (.+.) though. The (.X.) pattern for a family of operators is pretty
common, so it's good to avoid it for modules that want to be used in
combination with many others. YMMV and all that.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reducing code for efficient ShowS
That's an interesting idea. It appears to use the same idea as ShowS, but more generally with lists and not just strings. The difference-list approach to solving the appending problem is classic. There's a variant for unification-based logic languages as well. Both are functional takes on the imperative approach of keeping a tail pointer. Dons just took the time to package it up for us all :) Yes, I've seen it before in UU.DData.Seq. Though, where it was that I originally found it, I don't remember, but it wasn't the uulib. I didn't know what a difference list was, so I didn't pay much attention when Don released it. http://hackage.haskell.org/packages/archive/uulib/0.9.5/doc/html/UU-DData-Seq.html If you're planning on releasing the code, I'd suggest a different spelling of (.+.) though. The (.X.) pattern for a family of operators is pretty common, so it's good to avoid it for modules that want to be used in combination with many others. YMMV and all that. That sounds reasonable. My only motivations were to keep the operators short, sweet, and somewhat representative. Any suggestions are welcome. Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
On Fri, Sep 5, 2008 at 1:39 PM, Henning Thielemann [EMAIL PROTECTED] wrote: Haskell already supports qualification, why manual prefixing? This is just a stylistic opinion, but I absolutely hate required qualifications; it is a waste of typing and, in my opinion, it makes the resulting code look more cluttered and harder to read. It's especially bad when modules are extremely likely to be used together, like Control.Monad.State FRef, or Data.Map the Prelude. You end up being required to import one or the other qualified. I direct you to my proposal for ad-hoc overloading, recently discussed on this list, as a way to solve this problem. In my experience, the code is almost always unambiguous without the qualification because using the wrong operator would fail to typecheck. In this case, I agree that manual prefixing isn't really better, but using ugly names encourages people to find better ones. I couldn't think of any off the top of my head, but I wasn't trying very hard. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 2 modules in one file
On 2008-08-30, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On 2008 Aug 30, at 4:22, Aaron Denney wrote: On 2008-08-27, Henrik Nilsson [EMAIL PROTECTED] wrote: And there are also potential issues with not every legal module name being a legal file name across all possible file systems. I find this unconvincing. Broken file systems need to be fixed. Language people trying to impose constraints on filesystems is the tail wagging the dog. I'd say it's just the opposite. The purpose of a filesystem is to hold user data, in ways convenient to the user, which means dictating a usable interface. Dictating the implementation would be closer to tail wagging the dog, though even that's not quite the right metaphor -- it's just a layering violation. The user is in this case GHC or other compiler adopting the suggestion in the Hierarchical modules extension. Just as non-hierarchical file systems have long been considered broken, I think it's safe to now declare that one that doesn't support unicode in some fashion, even if only a userland convention of using UTF-8, is indeed less usable, and hence broken. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 2 modules in one file
On 2008 Sep 5, at 19:36, Aaron Denney wrote: On 2008-08-30, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On 2008 Aug 30, at 4:22, Aaron Denney wrote: On 2008-08-27, Henrik Nilsson [EMAIL PROTECTED] wrote: And there are also potential issues with not every legal module name being a legal file name across all possible file systems. I find this unconvincing. Broken file systems need to be fixed. Language people trying to impose constraints on filesystems is the tail wagging the dog. I think it's safe to now declare that one that doesn't support unicode in some fashion, even if only a userland convention of using UTF-8, is indeed less usable, and hence broken. It's not just UTF-8; Windows filesystems restrict a number of special characters (I don't think any are significant for module naming, but I can't swear to it either off the top of my head). Is this broken? If so, what do you think the chances are of getting it fixed? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional references
It's especially bad when modules are extremely likely to be used together, like Control.Monad.State FRef, or Data.Map the Prelude. You end up being required to import one or the other qualified. I think in the case of State vs. FRef a simple solution is to make two modules: FRef, which uses get and set and modify naturally, and FRef.State which defines State equivalents without polluting the namespace. Then if you're working with pure functions you can import FRef and use the natural names, and when you're using the State monad you can import FRef.State and get the State definitions that dont interfere with the standard get and modify names. In the rare case (I think, am I wrong?) where you use both State and FRef modify and get definitions in the same file, you can import the one you use less off qualified... -- ryan Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: xmonad 0.8 released!
http://xmonad.org The xmonad dev team is pleased to announce xmonad 0.8! The headlines: * A general purpose replacement for gaps has been adopted. * Floating windows pop up on the current screen by default * Locale support * Rock solid code: No new crash-inducing bugs reported in this release cycle * Many new extensions, including the ability to write your own configuration parsers. * The 1000th commit was made to the project Change logs: http://haskell.org/haskellwiki/Xmonad/Notable_changes_since_0.7 About: xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is extensible in Haskell, allowing for powerful customisation. Custom layout algorithms, key bindings and other extensions may be written by the user in config files. Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several physical screens. Features: * Very stable, fast, small and simple. * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating, tabbing and decorated windows * Full support for Gnome and KDE utilities * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Compositing support * Powerful, stable customisation and reconfiguration * Large extension library * Excellent, extensive documentation * Large, active development team, support and community Get it! Information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.8 release, and its dependencies, are available from hackage.haskell.org: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad xmonad packages are available in the package systems of at least: Debian, Gentoo, Arch, Ubuntu, OpenBSD, NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware and 0.8 packages will appear in coming days (some are already available). On the fly updating to xmonad 0.8 is supported. You can even use cabal-install: $ cabal update $ cabal install xmonad-0.8 $ cabal install xmonad-contrib-0.8 $ xmonad --recompile mod-q Extensions: xmonad comes with a huge library of extensions (now around 9 times the size of xmonad itself), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. For more information on using and writing extensions see the webpage. The library of extensions is available from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-contrib Full documentation for using and writing your own extensions: http://xmonad.org/contrib.html This release brought to you by the xmonad dev team: Spencer Janssen Don Stewart Jason Creighton David Roundy Brent YorgeyDevin Mullins Braden Shepherdson Roman Cheplyaka Lukas Mai Featuring code contributions from over 60 developers: Aaron DenneyAdam Vogt Alec Berryman Alex Tarkovsky Alexandre BuisseAndrea Rossato Austin SeippBas van Dijk Ben VouiBrandon Allbery Chris Mears Christian Thiemann Clemens Fruhwirth Daniel Neri Daniel Wagner Dave Harrison David Glasser David Lazar Dmitry KurochkinDominik Bruhn Dougal Stanton Eric Mertens Ferenc Wagner Gwern Branwen Hans Philipp Annen Ivan Tarasov Ivan VeselovJamie Webb Jeremy Apthorp Malebria Joachim BreitnerJoachim Fasting Joe ThornberJoel Suovaniemi Juraj HercekJustin Bogner Kai Grossjohann Karsten Schoelzel Klaus Weidner Mathias Stearn Mats Jansborg Matsuyama Tomohiro Michael Fellinger Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Nicolas Pouillard Nils Anders Danielsson Peter De WachterRobert Marlow Sam Hughes Shachaf Ben-Kiki Shae ErissonSimon Peyton Jones Stefan O'Rear Tom Rauchenwald Valery V. Vorotyntsev Will Farrington Yaakov Nemoytimthelion Rickard Gustafson Trevor Elliott Ian Zerny Ivan Miljenovic Marco e
Re: [haskell-cafe] Monad and kinds
On Thu, 2008-09-04 at 08:19 -0700, Tim Chevalier wrote: On 9/3/08, wren ng thornton [EMAIL PROTECTED] wrote: If you want the datatype to be strict in state and rec, then you should add strictness annotations to those fields directly: data Query state rec = Query !state !rec The novice programmer scatters strictness annotations to and fro like dust in the wind. The average programmer understands that annotating a field's strictness injudiciously is like discarding the finger pointing at the moon when you might still need it to scratch yourself. The master programmer does not add strictness annotations, for she has not yet run the profiler. This attitude is wrong. Many potentially significant performance problems can easily be spotted and solved during construction without affecting the readability of the code, problems that would be much harder to diagnose at the end running a profiler. This is especially crucial for library code. The users of the library may be the ones that find the easily resolved space leak your profiling didn't reveal and now they can't do anything about it until a new version is released e.g. Data.Map.insertWith. A performance problem that renders your code unusable is a bug and catching it early or not making it in the first place is much better than catching it late. A (highly related) analogy would be telling Scheme programmers (or Haskell programmers for that matter) not to use to tail recursive code until a profiler tells them to and transforming to a tail recursive style is much more intrusive than adding a strictness annotation. Highly competent Haskell programmers add strictness annotations relatively systematically. The details of mixing eager and lazy code is one of the significant contributions to the pragmatics of programming lazy functional languages have made. At another extreme, things like Chris Okasaki's data structures rely on a specific balance of eagerness and laziness. Also, it is easier (as in not impossible) to turn a strict in the elements data structure into a lazy one than the other way around. Eager by default or lazy by default are both have (actually dual) pitfalls that are best solved by a laziness or strictness annotation respectively. There is no need to walk into those pitfalls with your eyes wide open. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online RealWorld Haskell, problem with Sqlite3 chapters)
On Fri, 2008-09-05 at 20:55 +0100, Claus Reinke wrote: Seriously, though, what is the RWH authors' plan for tackling the eternal frustration of Haskell book authors, a moving target? Other tech books face the same problem, which, if they sell successfully and the authors haven't moved into caves afterwards to recover, they address with subsequent editions. If readers find that specific pieces of information have bitrotted, I'm sure we'll hear about it. In that case, we'll create a wiki page with errata, and link to it from the book site. Just saying, it is worth planning for, especially if the book is going to be successful. I understand if creating that book at breakneck speed has left you looking forward to a break (not of the neck;-), but laying out a strategy for this, and putting it in the preface, might avoid sorrows later. You do have the online version and commenting system in place which you could keep around, you could even keep copies of the precise code versions you use, although adapting the text is more appropriate for this style of book. To make what (I believe) Claus is saying more explicit and direct, add a note to the beginning of the book (or somewhere reasonably prominent) that states something along the lines: As time progresses parts of this book are going to become out-of-date, in particular code examples will. See url for errata or read the comments for that section on the online version of the book for details resolving these issues. Alternatively, send an email to rwhmailinglistaddress. I would recommend having a mailing list or some such as then you can potentially leverage the community to resolve such issues leading to less pressure on you three and likely faster responses. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On Fri, Sep 5, 2008 at 7:23 PM, Derek Elkins [EMAIL PROTECTED] wrote: This attitude is wrong. Many potentially significant performance problems can easily be spotted and solved during construction without affecting the readability of the code, problems that would be much harder to diagnose at the end running a profiler. This is especially crucial for library code. The users of the library may be the ones that find the easily resolved space leak your profiling didn't reveal and now they can't do anything about it until a new version is released e.g. Data.Map.insertWith. A performance problem that renders your code unusable is a bug and catching it early or not making it in the first place is much better than catching it late. Library writers don't write applications that use their code as part of the testing process? A (highly related) analogy would be telling Scheme programmers (or Haskell programmers for that matter) not to use to tail recursive code until a profiler tells them to and transforming to a tail recursive style is much more intrusive than adding a strictness annotation. Tail recursion isn't always a win in Haskell. I'm not much in touch with the Scheme world, so can't speak to that. Highly competent Haskell programmers add strictness annotations relatively systematically. The details of mixing eager and lazy code is one of the significant contributions to the pragmatics of programming lazy functional languages have made. At another extreme, things like Chris Okasaki's data structures rely on a specific balance of eagerness and laziness. Also, it is easier (as in not impossible) to turn a strict in the elements data structure into a lazy one than the other way around. Eager by default or lazy by default are both have (actually dual) pitfalls that are best solved by a laziness or strictness annotation respectively. There is no need to walk into those pitfalls with your eyes wide open. That may be, but are the holes that one falls into due to unexpected laziness and the ones that one falls into due to unexpected strictness equally numerous? Are they equally deep? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
On Fri, 2008-09-05 at 20:11 -0700, Tim Chevalier wrote: On Fri, Sep 5, 2008 at 7:23 PM, Derek Elkins [EMAIL PROTECTED] wrote: This attitude is wrong. Many potentially significant performance problems can easily be spotted and solved during construction without affecting the readability of the code, problems that would be much harder to diagnose at the end running a profiler. This is especially crucial for library code. The users of the library may be the ones that find the easily resolved space leak your profiling didn't reveal and now they can't do anything about it until a new version is released e.g. Data.Map.insertWith. A performance problem that renders your code unusable is a bug and catching it early or not making it in the first place is much better than catching it late. Library writers don't write applications that use their code as part of the testing process? They don't use their libraries in every conceivable way. A (highly related) analogy would be telling Scheme programmers (or Haskell programmers for that matter) not to use to tail recursive code until a profiler tells them to and transforming to a tail recursive style is much more intrusive than adding a strictness annotation. Tail recursion isn't always a win in Haskell. I'm very well aware of that. Due to the extremely close relationship with when to tail recursion and when to use laziness, your original statement almost obligates you to also believe that masters don't write tail recursive code until after profiling. I'm not much in touch with the Scheme world, so can't speak to that. Stick in any strict functional language or any other strict language (preferably higher order, but that isn't really important) that also supports tail call optimization. Highly competent Haskell programmers add strictness annotations relatively systematically. The details of mixing eager and lazy code is one of the significant contributions to the pragmatics of programming lazy functional languages have made. At another extreme, things like Chris Okasaki's data structures rely on a specific balance of eagerness and laziness. Also, it is easier (as in not impossible) to turn a strict in the elements data structure into a lazy one than the other way around. Eager by default or lazy by default are both have (actually dual) pitfalls that are best solved by a laziness or strictness annotation respectively. There is no need to walk into those pitfalls with your eyes wide open. That may be, but are the holes that one falls into due to unexpected laziness and the ones that one falls into due to unexpected strictness equally numerous? Are they equally deep? As I said, this particular issue is a duality. For at least a certain class of problems, the ones most relevant here, the holes are equally deep and equally numerous. What is correct in one language is a problem in the other. For examples and more discussion see: http://lambda-the-ultimate.org/node/2273#comment-40156 These last questions, though, are both flawed and irrelevant. They are flawed because the issue isn't which is the default: having both available -at all- makes you vulnerable to the pitfalls of both. Here's a good example: compose = foldr (.) id or should it be compose = foldl' (.) id maybe something else? The fact that Haskell has both strict and non-strict functions makes neither of these implementations correct. It is irrelevant because all that needs to be shown is that there exist -any- problem that can easily be identified and fixed with a strictness annotation. The Haskell implementation of factorial in the above has such a bug, it can be fixed with the addition of two characters, $!, I don't need a profiler to tell me this, and for every standard numeric type there will be no change in semantics (where semantics here does not include performance aspects.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: the real world of Haskell books (Re: [Haskell-cafe] Online RealWorld Haskell, problem with Sqlite3 chapters)
On Fri, Sep 5, 2008 at 7:50 PM, Derek Elkins [EMAIL PROTECTED] wrote: To make what (I believe) Claus is saying more explicit and direct, add a note to the beginning of the book (or somewhere reasonably prominent) that states something along the lines [...] We will add a link to an errata site in the final version. Thanks for the suggestion; it's an obvious thing to do in retrospect. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
