date:20090114

On Wed, 2009-01-14 at 18:59 -0500, Brandon S. Allbery KF8NH wrote:
> On 2009 Jan 14, at 10:26, Neil Mitchell wrote:
>   As an example:
>   foo = u"abc\N{VULGAR FRACTION ONE HALF}"
> >>>
> >>> Hmm, looks nice, and sensible. But as soon as you've got \N{}  
> >>> syntax I want:
> >>>
> >>> "foo\E{show i}bar"
> >>>
> >>> i.e. embed expressions in strings. I think this would be fantastic.
> >>
> >> why not simpy "foo\E{i}bar" ?
> >
> > What if i is a string? You'd get: foo"i"bar
> >
> > Having different behaviour for string vs everything else would be  
> > equally bad.
> 
> ...except that show already *has* different behavior for String vs.  
> everything else.

Technically, showList has different behavior for Char vs. everything
else.

And not necessarily for *everything* else.

And that's very well *not* what he meant.

jcc


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Brandon S. Allbery KF8NH



On 2009 Jan 14, at 10:39, Manlio Perillo wrote:

Neil Mitchell ha scritto:

Hi
1) In a Python string it is available the \U{name} escape, where  
name is

 a character name in the Unicode database.

 As an example:
 foo = u"abc\N{VULGAR FRACTION ONE HALF}"
Hmm, looks nice, and sensible. But as soon as you've got \N{}  
syntax I want:

"foo\E{show i}bar"


How this should/can work?
There is Text.Printf for this.


I vaguely recall seeing some TH go by that did this (albeit with $()  
TH foo).


Sometime they are necessary, to avoid circular import problems (but  
this not a problem with Haskell).


...in theory. In practice GHC needs help with circular imports, and  
some cycles might be impossible to resolve.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
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] some ideas for Haskell', from Python

2009-01-14 Thread Brandon S. Allbery KF8NH


On 2009 Jan 14, at 10:26, Neil Mitchell wrote:

 As an example:
 foo = u"abc\N{VULGAR FRACTION ONE HALF}"


Hmm, looks nice, and sensible. But as soon as you've got \N{}  
syntax I want:


"foo\E{show i}bar"

i.e. embed expressions in strings. I think this would be fantastic.


why not simpy "foo\E{i}bar" ?


What if i is a string? You'd get: foo"i"bar

Having different behaviour for string vs everything else would be  
equally bad.


...except that show already *has* different behavior for String vs.  
everything else.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
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] some ideas for Haskell', from Python

2009-01-14 Thread Lennart Augustsson

With macros you can define new variable binding constructs.
That's something I occasionally miss in Haskell.

  -- Lennart

On Wed, Jan 14, 2009 at 6:48 PM, Jonathan Cast
 wrote:
> On Wed, 2009-01-14 at 12:39 -0600, Tim Wawrzynczak wrote:
>> You're probably right.
>> I've played around with LISP macros a little, but it seems
>> that most
>> of the cases where you would use a macro in LISP you don't
>> need one in
>> haskell due to lazy evaluation.  Although I haven't played
>> around with
>> them enough to say much one way or another.
>>
>> Do you know of a particular example where a macro would be a
>> big help
>> in haskell?
>>
>> Well, like many good programming tools, Lisp macros are another
>> abstraction, but instead of dealing with data, they deal with code.
>
> Haskell already has a couple of abstraction tools for dealing with code.
> One is called `first-class functions'; another is called `lazy
> evaluation'.
>
>> They are a syntactic abstraction.
>
> What is this good for?  I suspect most Lisp macros are parametric in
> form, rather than really syntactic; I know that every example of a Lisp
> macro I've seen is parametric in form.  Parametric macros --- macros
> that don't deconstruct their arguments --- don't usually need to be
> macros at all in modern functional languages.  Do you have an example of
> a macro that can't be replaced by higher-order functions and laziness?
>
>> They're often described as "programs that write programs."
>
> So are code generators.  The most common example of a code generator is
> probably YACC --- but Parsec replaces it, with better readability even,
> with first-class parsers (built atop first-class functions).
>
> jcc
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] real haskell difficulties (at least for me)


Duncan Coutts ha scritto:

On Tue, 2009-01-13 at 19:20 +, Andrew Coppin wrote:

I vividle remember Dons repeatedly telling me that I should try out 
[some package who's name escapes me], and then discovering that it 
doesn't actually work on Windows at all. (Couldn't this critical 
information be included somewhere prominent on Hackage??)


This critical information should be provided on each package page on
Hackage. It's not quite as trivial as it looks however.

If you'd like to help out, we're working on a new hackage-server that
allows users to upload build reports. That way we hope to discover
automatically which packages do and do not build on various platforms.
The basics work but we need more help in polishing it up.



Do you know buildbot?
http://buildbot.net/trac



Duncan




Manlio Perillo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Alex Queiroz

Hallo,

On Wed, Jan 14, 2009 at 8:47 PM, Dougal Stanton  wrote:
>> (defun avg (&rest args)
>>   (/ (apply #'+ args) (length args)))
>>
>> Or as a macro like this:
>>
>> (defmacro avg (&rest args)
>>   `(/ (+ ,@args) ,(length args)))
>>
>> The reason the macro is better is that the length of the list is known at
>> compile time, so you don't need to traverse the list to calculate the length
>> of the list.
>>
>
>
> I'm trying to work out how awesome the (+) operator is that you can
> add the values together without needing to traverse the list ;-)
>

 Don't need to traverse the list at run time, not compile
(actually macro-expansion) time.

Cheers,
-- 
-alex
http://www.ventonegro.org/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re[2]: [Haskell-cafe] Haskell and C++ program

2009-01-14 Thread Bulat Ziganshin

Hello Jonathan,

Thursday, January 15, 2009, 1:41:23 AM, you wrote:

>   reverseDouble =
> unlines
>   . intro
>   . map show
>   . reverse
>   . map (read :: String -> Double)
>   . takeWhile (/= "end")
>   . words

using arrows, this may be reversed:

  reverseDouble =
  words
  >>> takeWhile (/= "end")
  ...

> I observe also in passing that the cast on read is somewhat inelegant;
> in a real application, the consumer of map read's output would specify
> its type sufficiently that the cast would be un-necessary.

in small scripts explicit read casts are rather common


-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] about System.Posix.Files.fileAccess

2009-01-14 Thread Brandon S. Allbery KF8NH


On 2009 Jan 14, at 9:02, Manlio Perillo wrote:

This is of course a personal opinion, but I think the interface of:
fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool
http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v 
:fileAccess


is not very good.



The underlying system call access() is strongly disrecommended, so  
it's not really worth a better interface.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
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] real haskell difficulties (at least for me)

2009-01-14 Thread Duncan Coutts

On Tue, 2009-01-13 at 19:20 +, Andrew Coppin wrote:

> I vividle remember Dons repeatedly telling me that I should try out 
> [some package who's name escapes me], and then discovering that it 
> doesn't actually work on Windows at all. (Couldn't this critical 
> information be included somewhere prominent on Hackage??)

This critical information should be provided on each package page on
Hackage. It's not quite as trivial as it looks however.

If you'd like to help out, we're working on a new hackage-server that
allows users to upload build reports. That way we hope to discover
automatically which packages do and do not build on various platforms.
The basics work but we need more help in polishing it up.

Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Dougal Stanton

> (defun avg (&rest args)
>   (/ (apply #'+ args) (length args)))
>
> Or as a macro like this:
>
> (defmacro avg (&rest args)
>   `(/ (+ ,@args) ,(length args)))
>
> The reason the macro is better is that the length of the list is known at
> compile time, so you don't need to traverse the list to calculate the length
> of the list.
>


I'm trying to work out how awesome the (+) operator is that you can
add the values together without needing to traverse the list ;-)


D
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell and C++ program

2009-01-14 Thread Peter Verswyvelen

>
>
> PS Stroustrup's comments about vectors are at best half right; push_back
> may extend the vector's length correctly, but operator[] on a vector
> certainly does not do bounds checking.
>

Sure it does, depending on how you configured the STL library. But this is
off topic :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell and C++ program

On Wed, 2009-01-14 at 12:45 -0800, Sukit Tretriluxana wrote:
> Hi all,
> 
> I was looking around Stroustrup's website and found a simple program
> that he showed how standard library can be used to make the program
> succinct and safe. See
> http://www.research.att.com/~bs/bs_faq2.html#simple-program. I
> wondered how a Haskell program equivalent to it looks like and I came
> up with the code below.
> 
> import qualified Control.Exception as E
> 
> main = E.catch (interact reverseDouble) (\_ -> print "format error")
> 
> reverseDouble = unlines . doIt . words
>where doIt = intro . toStrings . reverse . toDoubles . input
>  toDoubles = map (read::String->Double)
>  toStrings = map show
>  input = takeWhile (/= "end")
>  intro l = ("read " ++ (show $ length l) ++ " elements") :
>"elements in reversed order" :

My only criticism is that I find code written with lots of secondary
definitions like this confusing; so I would inline most of the
definitions:

  reverseDouble =
unlines
  . intro
  . map show
  . reverse
  . map (read :: String -> Double)
  . takeWhile (/= "end")
  . words
where
  intro l =
("read " ++ show (length l) ++ " elements") :
"elements in reversed order" :
l

I observe also in passing that the cast on read is somewhat inelegant;
in a real application, the consumer of map read's output would specify
its type sufficiently that the cast would be un-necessary.

For example, the program could be specified to compute sines instead:

main = E.catch (interact unlines . intro . map (show . sin . read) .
words) $ \ _ -> print "format error"
  where
intro l =
  ("read " ++ show (length l) ++ " arguments") :
  "computed sins" :
  l

(Others will no doubt object to the use of lazy I/O.  I disagree in
principle with those objections.)

jcc

PS Stroustrup's comments about vectors are at best half right; push_back
may extend the vector's length correctly, but operator[] on a vector
certainly does not do bounds checking.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Looking for Haskellers on Windows

2009-01-14 Thread John Goerzen

Thank you for the hint.  Please try this patch:

http://git.complete.org/hdbc-odbc?a=commitdiff_plain;h=55af38aac8df9f94498680bc54af173851c32d6c

and let me know if it fixes the issue for you.

-- John

kyra wrote:
> John Goerzen wrote:
>> GЭnther Schmidt wrote:
>>> Kyra I've tried any sort of values to any sort of columns. I tried "insert  
>>> into somesinglecolumntable (someNumbercolumn) values (?)" [toSql 5] ...  
>>> and so on.
>>>
>>> So I'm not certain at all the error message does actually give the right  
>>> clue.
>>>
>>> It just blows no matter what.
> 
> It seems, I've managed to track down the issue.
> 
> Access ODBC driver doesn't support sqlDescribeParam.
> 
> bindCol (Database/HDBC/ODBC/Statement.hsc) contains the following stub 
> for this:
> 
>do poke pdtype #{const SQL_CHAR}
>   poke pcolsize 0
>   poke pdecdigits 0
> 
> This does not work.
> 
> I've made an experiment replacing 'poke pcolsize 0' with 'poke pcolsize 
> 255'. Now all integer or varchar bindings work!
> 
> It seems simpleSqlColumns or something similar must be used.
> 
> Cheers,
> Kyra
> 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] about System.Posix.Files.fileAccess

2009-01-14 Thread Don Stewart

manlio_perillo:
> Hi.
> 
> This is of course a personal opinion, but I think the interface of:
> fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool
> http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v:fileAccess
> 
> is not very good.
> 
> Is it possible to design (in theory) a better interface?
> 

It is possible (in theory) to design a better interface. :)

--   Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: HLint 1.2

2009-01-14 Thread Andrew Coppin


Neil Mitchell wrote:

I can't really be blamed for making mistakes before HLint ;-)
  


Don't worry - self-programming computers are just around the corner... ;-)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] real haskell difficulties (at least for me)

2009-01-14 Thread Andrew Coppin


Krzysztof Skrzętnicki wrote:

My experience from using GHC under Windows XP is very similar. Many
packages (especially those involving bindings to C packages) are at
least painful to build.
  


+1

Also have to love packages that use Unix-specific features as part of 
their build process. (I even found a page on the Wiki that recommends 
the use of Bash scripts. Hmm...)


I vividle remember Dons repeatedly telling me that I should try out 
[some package who's name escapes me], and then discovering that it 
doesn't actually work on Windows at all. (Couldn't this critical 
information be included somewhere prominent on Hackage??)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] unfoldr [ANN: HLint 1.2]

2009-01-14 Thread Andrew Coppin


Colin Adams wrote:

2009/1/13 Andrew Coppin :

  

One of the wonderful things about Haskell is that almost any time anybody
posts code, at least one person will think up an alternative but equivilent
way of achieving the same goal - sometimes by radically different steps.

Maybe we should have a name for this effect?



Confusion.
  


This is a worthy addition to the Humour page, IMHO... :-D

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell and C++ program

2009-01-14 Thread Sukit Tretriluxana

Hi all,

I was looking around Stroustrup's website and found a simple program that he
showed how standard library can be used to make the program succinct and
safe. See http://www.research.att.com/~bs/bs_faq2.html#simple-program. I
wondered how a Haskell program equivalent to it looks like and I came up
with the code below.

import qualified Control.Exception as E

main = E.catch (interact reverseDouble) (\_ -> print "format error")

reverseDouble = unlines . doIt . words
   where doIt = intro . toStrings . reverse . toDoubles . input
 toDoubles = map (read::String->Double)
 toStrings = map show
 input = takeWhile (/= "end")
 intro l = ("read " ++ (show $ length l) ++ " elements") :
   "elements in reversed order" :

I'm not a Haskell expert and I am pretty sure that this is not the optimal
form a Haskell program that's equivalent to the C++ one. So I would like to
see, from the Haskell experts in this group, how else (of course better
form) such a program can be written.

Thanks,
Ed
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: real haskell difficulties (at least for me)

2009-01-14 Thread Erik de Castro Lopo

Simon Marlow wrote:

> Sounds like the Debian folks could use some help with automatically 
> packaging Cabal packages, though.

Well I've joined the debian-haskell mailing list and I'll do what
I can to help.

Erik
-- 
-
Erik de Castro Lopo
-
"I would buy a Mac today if I was not working at Microsoft."
-- Senior Microsoft exective Jim Allchin in a 200 email to Bill
Gates : http://www.iowaconsumercase.org/010807/PLEX_7264.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Max Rabkin

2009/1/14 Tim Wawrzynczak :
> The reason the macro is better is that the length of the list is known at
> compile time, so you don't need to traverse the list to calculate the length
> of the list.

Or you could use a real compiler (perhaps even a glorious one) that
does constant folding when the list length is constant, but have your
function still work when it isn't constant.

--Max
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

On Wed, Jan 14, 2009 at 1:14 PM, Jonathan Cast wrote:

> On Wed, 2009-01-14 at 11:06 -0800, Max Rabkin wrote:
> > On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast
> >  wrote:
> > > Do you have an example of
> > > a macro that can't be replaced by higher-order functions and laziness?
> >
> > I believe I do: one macro I found useful when writing a web app in
> > Lisp was something I called hash-bind, which binds variables to the
> > values in a hashtable, with the variable names as keys. For example:
> >
> > (hash-bind (a b) hashtable body)
> > ==
> > (let
> > ((a (lookup hashtable "a"))
> >  (b (lookup hashtable "b"))
> > body)
> >
> > I found this very useful in places where I was given URL request
> > parameters in a hashtable and wanted to extract some variables from
> > it. I don't believe it can be replaced by a higher order function
> > (though I may be wrong).
>
> Thanks!  When you *know* there's a good reason people say something, and
> can't find a good example of *why*, it's a tremendous relief when when
> you find one.  Sort of restores your faith in humanity :)
>
> jcc
>
>
>
I thought of another good case (Shamelessly stolen from Paul Graham's 'On
Lisp').  When defining a function to average the results of the list, you
could define avg like this:

(defun avg (&rest args)
  (/ (apply #'+ args) (length args)))

Or as a macro like this:

(defmacro avg (&rest args)
  `(/ (+ ,@args) ,(length args)))

The reason the macro is better is that the length of the list is known at
compile time, so you don't need to traverse the list to calculate the length
of the list.

Food for thought, anyway.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Alex Queiroz

Hallo,

On Wed, Jan 14, 2009 at 5:16 PM, Max Rabkin  wrote:
> On Wed, Jan 14, 2009 at 11:11 AM, Alex Queiroz  wrote:
>> I have one for binding GET/POST variables to regular variables
>> transparently and with error checking, just inside the body of the
>> macro.
>
> N! You reinvented PHP. What happens if a request variable shadows
> the name of another variable used in the body?
>

 I list the variables I want to bind in the form. I do not ask to
automatically bind all of them. :)

(query-let (id name job salary)
   (if (> salary 1000) ...))

-- 
-alex
http://www.ventonegro.org/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Max Rabkin

On Wed, Jan 14, 2009 at 11:11 AM, Alex Queiroz  wrote:
> I have one for binding GET/POST variables to regular variables
> transparently and with error checking, just inside the body of the
> macro.

N! You reinvented PHP. What happens if a request variable shadows
the name of another variable used in the body?

> --
> -alex
> http://www.ventonegro.org/
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

On Wed, 2009-01-14 at 11:06 -0800, Max Rabkin wrote:
> On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast
>  wrote:
> > Do you have an example of
> > a macro that can't be replaced by higher-order functions and laziness?
> 
> I believe I do: one macro I found useful when writing a web app in
> Lisp was something I called hash-bind, which binds variables to the
> values in a hashtable, with the variable names as keys. For example:
> 
> (hash-bind (a b) hashtable body)
> ==
> (let
> ((a (lookup hashtable "a"))
>  (b (lookup hashtable "b"))
> body)
> 
> I found this very useful in places where I was given URL request
> parameters in a hashtable and wanted to extract some variables from
> it. I don't believe it can be replaced by a higher order function
> (though I may be wrong).

Thanks!  When you *know* there's a good reason people say something, and
can't find a good example of *why*, it's a tremendous relief when when
you find one.  Sort of restores your faith in humanity :)

jcc


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Alex Queiroz

Hallo,

On Wed, Jan 14, 2009 at 5:06 PM, Max Rabkin  wrote:
> On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast
>  wrote:
>> Do you have an example of
>> a macro that can't be replaced by higher-order functions and laziness?
>
> I believe I do: one macro I found useful when writing a web app in
> Lisp was something I called hash-bind, which binds variables to the
> values in a hashtable, with the variable names as keys. For example:
>

 I have one for binding GET/POST variables to regular variables
transparently and with error checking, just inside the body of the
macro.

-- 
-alex
http://www.ventonegro.org/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Max Rabkin

On Wed, Jan 14, 2009 at 10:48 AM, Jonathan Cast
 wrote:
> Do you have an example of
> a macro that can't be replaced by higher-order functions and laziness?

I believe I do: one macro I found useful when writing a web app in
Lisp was something I called hash-bind, which binds variables to the
values in a hashtable, with the variable names as keys. For example:

(hash-bind (a b) hashtable body)
==
(let
((a (lookup hashtable "a"))
 (b (lookup hashtable "b"))
body)

I found this very useful in places where I was given URL request
parameters in a hashtable and wanted to extract some variables from
it. I don't believe it can be replaced by a higher order function
(though I may be wrong).

--Max
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Martijn van Steenbergen


Tim Wawrzynczak wrote:
Woah fellas, I wasn't trying to start a flame war, I was merely 
commenting that those who have not used Lisp don't really understand the 
power that macros can have in a language (such as Lisp) that supports 
them, and where code and data can be used interchangeably.  And I've 
never used TH so I can't comment on that.  Don't worry, I'm on your side :)


Oh, I didn't mean that in a bad way. :-)

I was just thinking that if something turns out hard to express in pure 
functions, you can always resort to Template Haskell.


Martijn.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

On Wed, Jan 14, 2009 at 12:56 PM, Martijn van Steenbergen <
mart...@van.steenbergen.nl> wrote:

> Jonathan Cast wrote:
>
>> Haskell already has a couple of abstraction tools for dealing with code.
>> One is called `first-class functions'; another is called `lazy
>> evaluation'.
>>
>
> And for all the rest there is TH?
>
> M.
>
>
Woah fellas, I wasn't trying to start a flame war, I was merely commenting
that those who have not used Lisp don't really understand the power that
macros can have in a language (such as Lisp) that supports them, and where
code and data can be used interchangeably.  And I've never used TH so I
can't comment on that.  Don't worry, I'm on your side :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Martijn van Steenbergen


Jonathan Cast wrote:

Haskell already has a couple of abstraction tools for dealing with code.
One is called `first-class functions'; another is called `lazy
evaluation'.


And for all the rest there is TH?

M.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

On Wed, 2009-01-14 at 12:39 -0600, Tim Wawrzynczak wrote:
> You're probably right.
> I've played around with LISP macros a little, but it seems
> that most
> of the cases where you would use a macro in LISP you don't
> need one in
> haskell due to lazy evaluation.  Although I haven't played
> around with
> them enough to say much one way or another.
> 
> Do you know of a particular example where a macro would be a
> big help
> in haskell?
> 
> Well, like many good programming tools, Lisp macros are another
> abstraction, but instead of dealing with data, they deal with code.

Haskell already has a couple of abstraction tools for dealing with code.
One is called `first-class functions'; another is called `lazy
evaluation'.

> They are a syntactic abstraction.

What is this good for?  I suspect most Lisp macros are parametric in
form, rather than really syntactic; I know that every example of a Lisp
macro I've seen is parametric in form.  Parametric macros --- macros
that don't deconstruct their arguments --- don't usually need to be
macros at all in modern functional languages.  Do you have an example of
a macro that can't be replaced by higher-order functions and laziness?

> They're often described as "programs that write programs."

So are code generators.  The most common example of a code generator is
probably YACC --- but Parsec replaces it, with better readability even,
with first-class parsers (built atop first-class functions).

jcc

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Miguel Mitrofanov

Well, like many good programming tools, Lisp macros are another  
abstraction, but instead of dealing with data, they deal with code.


I didn't know Lisp puts such an emphasis on the difference between  
code and data.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

>
> You're probably right.
> I've played around with LISP macros a little, but it seems that most
> of the cases where you would use a macro in LISP you don't need one in
> haskell due to lazy evaluation.  Although I haven't played around with
> them enough to say much one way or another.
>
> Do you know of a particular example where a macro would be a big help
> in haskell?
>

Well, like many good programming tools, Lisp macros are another abstraction,
but instead of dealing with data, they deal with code.  They are a syntactic
abstraction.  They're often described as "programs that write programs."  We
all know how much Haskell likes abstractions ;)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stack Overflow, tail recursion and CPS

On Wed, 2009-01-14 at 19:19 +0100, Günther Schmidt wrote:
> Hello Neil,
> 
> thanks, that did indeed work.
> 
> I guess I shot myself in the foot a bit here ...
> 
> Cause my real problem isn't actually with Map but with IxSet (from HAppS)  
> which to my knowledge does not have some sort of strict insert function.

Does it by any chance have a Control.Parallel.Strategies.NFData
instance?  If it should happen to, then replacing (I didn't look up the
type of insert!)

foldl insert empty xn

with

foldl' ((result.result) (`using` rnf) insert) empty xn

(where result is the Semantic Editor Combinator[1]

result e f = e . f)

would give you as much strictness as possible.

Which might not be an improvement.

jcc

[1] This term was invented by Conal Elliot at
.  Semantic
Editor Combinators are a clever technique for making point-less code
readable.[2]

[2] Does making point-free code readable miss the point of point-free
style?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Job Vranish

On Wed, Jan 14, 2009 at 12:48 PM, Tim Wawrzynczak
 wrote:
>
>
>> Having an import/module feature like this would replace almost all cases 
>> where someone might wish for a macro system for Haskell.
>
> Don't say that until you've tried Lisp macros... read some of Paul Graham's 
> essays or try some Common Lisp for yourself... macros can be an incredibly 
> powerful tool, but "macros" from C, etc. aren't really macros, they're more 
> like find-and-replace expressions :)

You're probably right.
I've played around with LISP macros a little, but it seems that most
of the cases where you would use a macro in LISP you don't need one in
haskell due to lazy evaluation.  Although I haven't played around with
them enough to say much one way or another.

Do you know of a particular example where a macro would be a big help
in haskell?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stack Overflow, tail recursion and CPS

2009-01-14 Thread Günther Schmidt


Hello Neil,

thanks, that did indeed work.

I guess I shot myself in the foot a bit here ...

Cause my real problem isn't actually with Map but with IxSet (from HAppS)  
which to my knowledge does not have some sort of strict insert function.  
Me trying to be really clever just used Map as a random example here  
quietly hoping to get confirmation for "Yes, CPS is the anwer to force  
evaluation here, keep digging in that direction boy", or a straight CPS  
solution which I then would just translate to my problem.


Um ...

Didn't work, you were to clever, thanks a bunch Neil :)


Günther


Am 14.01.2009, 18:32 Uhr, schrieb Neil Mitchell :


Hi

I have changed the insertion algo to use foldl to make it  
tail-recursive but

still get a stack overflow as the "insert" remains lazy.


Try foldl' and insertWith' - that should work.

Thanks

Neil




--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread David Leimbach

On Wed, Jan 14, 2009 at 10:13 AM, David Leimbach  wrote:

>
>> joinPath' root name = import.System.FilePath.joinPath [root,name]
>>
>
> How is this different from
>
> joinPath' root name = System.FilePath.joinPath [root,name]
>
>
> I'm sorry I didn't mean "different", I meant "better than"?  I don't get
the advantage.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread David Leimbach

>
>
> joinPath' root name = import.System.FilePath.joinPath [root,name]
>

How is this different from

joinPath' root name = System.FilePath.joinPath [root,name]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

Having an import/module feature like this would replace almost all cases
> where someone might wish for a macro system for Haskell.
>

Don't say that until you've tried Lisp macros... read some of Paul Graham's
essays or try some Common Lisp for yourself... macros can be an incredibly
powerful tool, but "macros" from C, etc. aren't really macros, they're more
like find-and-replace expressions :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Job Vranish

What I would really like to see is locally scoped imports but with
parameterized modules. (so modules could take types and values as
parameters)
The places where I most want a feature like this is when I have a group of
helper functions that need a value that is outside the modules scope, but
that in general doesn't change. Usually we just curry the functions, but
that generates a lot of wasted code.
A good example might be the token
parsersin
parsec. Rather than have something like this:

whiteSpace= P.whiteSpace

lexer
lexeme= P.lexeme lexer
symbol= P.symbol
 lexer
natural   = P.natural

lexer
...

We could do something like:

import ParsecToken lexer

Having an import/module feature like this would replace almost all cases
where someone might wish for a macro system for Haskell.

>> Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax
I want:
>>
>> "foo\E{show i}bar"
>
> "foo"++show i++"bar"
>
>Change the language - save two characters.

For simple cases, doing "foo" ++ show i ++ "bar" isn't bad at all, but when
you have five or six or ten (show i)s that you want to mix in, it can get
pretty hard to read.

On Wed, Jan 14, 2009 at 11:43 AM, Ketil Malde  wrote:

> "Neil Mitchell"  writes:
>
> >> 1) In a Python string it is available the \U{name} escape, where name is
> >>   a character name in the Unicode database.
>
> >>   As an example:
> >>   foo = u"abc\N{VULGAR FRACTION ONE HALF}"
>
> Why not:
>
>import Unicode.Entities as U
>
>foo = "abc"++U.vulgar_fraction_one_half
>
> > Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax
> I want:
> >
> > "foo\E{show i}bar"
>
>   "foo"++show i++"bar"
>
> Change the language - save two characters.
>
> >> 2) In Python it is possible to import modules inside a function.
> >>
> >>   In Haskell something like:
> >>
> >>   joinPath' root name =
> >>   joinPath [root, name]
> >>   importing System.FilePath (joinPath)
>
> > It does mean you need to read an entire file to see
>
> Well, then you might as well allow multiple modules per file as per
> the recent discussion.  And multi-module files will possibly let you
> achieve the desired encapsulation without actually changing the
> language.
>
> -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
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stack Overflow, tail recursion and CPS

Hi

> I have changed the insertion algo to use foldl to make it tail-recursive but
> still get a stack overflow as the "insert" remains lazy.

Try foldl' and insertWith' - that should work.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stack Overflow, tail recursion and CPS

2009-01-14 Thread Günther Schmidt


Hi Eugene,


tried that, but since the action to be evaluated is the insertion into a  
structure that won't work.


The strictness here doesn't go deep enough, it stopps short.

Günther



Am 14.01.2009, 18:27 Uhr, schrieb Eugene Kirpichov :


Use foldl' ?

2009/1/14 Günther Schmidt :

Hi all,

I get a stack overflow when I want to insert a huge, lazy list into a  
Map.


I have changed the insertion algo to use foldl to make it  
tail-recursive but

still get a stack overflow as the "insert" remains lazy.

Could CPS be a solution in these cases?

Günther

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe





--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monads aren't evil? I think they are.

2009-01-14 Thread Alberto G. Corona

The question of imperative versus pure declarative coding has brought to my
mind some may be off-topic speculations.  (so please don´t read it if you
have no time to waste):  I´m interested in the misterious relation bentween
mathematics, algoritms and reality (see
thisfor example).  Functional
programming is declarative, you can model the
entire world functionally with no concern for the order of calculations. The
world is mathematical. The laws of physics have no concern for sequencing.
But CPUs and communications are basically sequential.  Life is sequential,
and programs run along the time coordinate. Whenever you have to run a
program,  you or your compiler must sequence it.  The sequentiation  must be
done by you or your compiler or both. The functional declarative code can be
sequenced on-the-run by the compiler in the CPU by the runtime. but IO is
different.
You have to create, explicitly or implicitly the sequence of IO actions
because the external events in the external world  are not controlled by you
or the compiler. So you, the programmer are the responsible of sequencing
effects in coordination with the external world. so every language must give
you ways to express  sequencing of actions. that is why, to interact with
the external world you must think in terms of algorithms, that is ,
imperatively, no matter if you make the imperative-sequence  (relatively)
explicit with monads or if you make it trough pairs (state, value) or
unsafePerformIO or whatever. You have to think imperatively either way,
because yo HAVE TO construct a sequence. I think that the elegant option is
to recognize this different algorithmic nature of IO by using the IO monad.
In other terms, the appearance of input-output in a problem means that you
modelize just a part of the whole system. the interaction with the part of
the system that the program do not control appears as input output. if the
program includes the model of the environment that give the input output
(including perhaps a model of yourself), then, all the code may be side
effects free and unobservable. Thus, input output is a measure of the lack
of  a priori information.  Because this information is given and demanded at
precide points in the time dimension with a quantitative (real time) or
ordered (sequential) measure, then these impure considerations must be taken
into account in the program. However, the above is nonsensical, because if
you know everithing a priory, then you don´t have a problem, so you don´t
need a program. Because problem solving is to cope with unknow data that
appears AFTER the program has been created, in oder to produce output at the
corrrect time, then the program must have timing on it. has an algoritmic
nature, is not pure mathemathical. This applies indeed to all living beings,
that respond to the environment, and this creates the notion of time.

Concerning monadic code with no side effects, In mathematical terms,
 sequenced (monadic) code are mathematically different from declarative
code: A  function describes what in mathematics is called a  "manifold" with
a number of dimensions equal to the number of parameters.  In the other
side, a sequence describe a particular  trayectory in a manifold, a ordered
set of points in a wider manyfold surface. For this reason the latter must
be described algorithmically. The former can be said that include all
possible trajectories, and can be expressed declaratively. The latter is a
sequence  . You can use the former to construct the later, but you must
express the sequence because you are defining the concrete trajectory in the
general manifold that solve your concrete problem, not other infinite sets
of related problems. This essentially applies also to IO.

 Well this does not imply that you must use monads for it. For example, a
way to express a sequence is a list where each element is a function of the
previous.  The complier is forced to sequence it in the way you whant, but
this happens also with monad evaluation.

This can be exemplified with the laws of Newton: they are declarative. Like
any phisical formula. has no concern for sequencing. But when you need to
simulate the behaviour of a ballistic weapon, you must use a sequence of
instructions( that include the l newton laws). (well, in this case the
trajectory is continuous integrable and can be expressed in a single
function. In this case, the manifold includes a unique trajectory, but  this
is not the case in ordinary discrete problems,) . So any language need
declarative as well as imperative elements to program mathematical models as
well as algorithms.

Cheers
  Alberto.

2009/1/11 Apfelmus, Heinrich 

> Ertugrul Soeylemez wrote:
> > Let me tell you that usually 90% of my code is
> > monadic and there is really nothing wrong with that.  I use especially
> > State monads and StateT transformers very often, because they are
> > convenient and are just a clean combinator frontend to what y

[Haskell-cafe] Stack Overflow, tail recursion and CPS

2009-01-14 Thread Günther Schmidt


Hi all,

I get a stack overflow when I want to insert a huge, lazy list into a Map.

I have changed the insertion algo to use foldl to make it tail-recursive  
but still get a stack overflow as the "insert" remains lazy.


Could CPS be a solution in these cases?

Günther

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Arch Haskell News: Jan 11 2009

2009-01-14 Thread Vesa Kaihlavirta

On Tue, Jan 13, 2009 at 9:27 PM, Peter Hercek  wrote:
> Hi,
>
> Any idea why ghc 6.10.1 is still in Testing repository on archlinux?

I have some idea :P

The obvious reason: we wanted to minimize the amount of breakage the
upgrade would cause. My guess was that the most common usage pattern
for ghc on Arch is building one's own xmonad config, and there's still
no release version of xmonad-contrib that builds on ghc-6.10.1.

--vk

P.S. you might wanna consider subscribing to
http://www.haskell.org/mailman/listinfo/arch-haskell
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Ketil Malde

"Neil Mitchell"  writes:

>> 1) In a Python string it is available the \U{name} escape, where name is
>>   a character name in the Unicode database.

>>   As an example:
>>   foo = u"abc\N{VULGAR FRACTION ONE HALF}"

Why not:

import Unicode.Entities as U

foo = "abc"++U.vulgar_fraction_one_half

> Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax I 
> want:
>
> "foo\E{show i}bar"

  "foo"++show i++"bar"

Change the language - save two characters.

>> 2) In Python it is possible to import modules inside a function.
>>
>>   In Haskell something like:
>>
>>   joinPath' root name =
>>   joinPath [root, name]
>>   importing System.FilePath (joinPath)

> It does mean you need to read an entire file to see

Well, then you might as well allow multiple modules per file as per
the recent discussion.  And multi-module files will possibly let you
achieve the desired encapsulation without actually changing the
language. 

-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] some ideas for Haskell', from Python

2009-01-14 Thread Lennart Augustsson

When Haskell was designed there was a bried discussion (if my memory
serves me) to have import be a decl, so it could occur anywhere a
normal declaration can occur.
I kinda like the idea, but some people didn't and it never happened.

  -- Lennart

On Wed, Jan 14, 2009 at 3:12 PM, Neil Mitchell  wrote:
> Hi
>
>> 1) In a Python string it is available the \U{name} escape, where name is
>>   a character name in the Unicode database.
>>
>>   As an example:
>>   foo = u"abc\N{VULGAR FRACTION ONE HALF}"
>
> Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax I 
> want:
>
> "foo\E{show i}bar"
>
> i.e. embed expressions in strings. I think this would be fantastic.
>
>> 2) In Python it is possible to import modules inside a function.
>>
>>   In Haskell something like:
>>
>>   joinPath' root name =
>>   joinPath [root, name]
>>   importing System.FilePath (joinPath)
>
> Looks a bit ugly, but kind of useful. I'd make the syntax:
>
> joinPath' root name = joinPath [root,name]
>  where import System.FilePath(joinPath)
>
> It does mean you need to read an entire file to see what functions it
> imports, but perhaps that is the way it should be. I could also
> imagine a syntax:
>
> joinPath' root name = import.System.FilePath.joinPath [root,name]
>
> i.e. doing an import and use at the same time.
>
> Nice ideas, but they probably want implemented in a Haskell compiler
> and using in real life before they are ready for Haskell' like
> thoughts.
>
> Thanks
>
> Neil
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python


Neil Mitchell ha scritto:

Hi


1) In a Python string it is available the \U{name} escape, where name is
  a character name in the Unicode database.

  As an example:
  foo = u"abc\N{VULGAR FRACTION ONE HALF}"


Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax I want:

"foo\E{show i}bar"



How this should/can work?
There is Text.Printf for this.


i.e. embed expressions in strings. I think this would be fantastic.


2) In Python it is possible to import modules inside a function.

  In Haskell something like:

  joinPath' root name =
  joinPath [root, name]
  importing System.FilePath (joinPath)


Looks a bit ugly, but kind of useful. I'd make the syntax:

joinPath' root name = joinPath [root,name]
  where import System.FilePath(joinPath)



It seems a good solution.


It does mean you need to read an entire file to see what functions it
imports, 


Yes.
That's the same with Python.

I use imports inside a function only with care.
Sometime they are necessary, to avoid circular import problems (but this 
not a problem with Haskell).


> [...]

Nice ideas, but they probably want implemented in a Haskell compiler
and using in real life before they are ready for Haskell' like
thoughts.



The first feature requires some works.
As far as I know GHC does not support the Unicode database at all.

It would be nice to have an Haskell interface for the CLDR (Common 
Locale Data Repository), like done in

babel: http://babel.edgewall.org/
http://unicode.org/cldr/


Thanks

Neil




Regards  Manlio Perillo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2


Sigbjorn Finne wrote:

Thanks Simon,

great stuff; I like the introduction of these  'native code finalizers', 
they've

been sorely missed at times.

You don't say, but will there be a dynamic check to catch such re-entries?


There is (now) a dynamic check, yes.

Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2


Johan Tibell wrote:

On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow  wrote:

By popular demand, GHC 6.10.2 will support finalizers that are actually
guaranteed to run, and run promptly.  There aren't any API changes: this
happens for finalizers created using newForeignPtr as normal.


Does this effect GC performance even if you don't use finalizers?

My knowledge of how finalizers affect GC performance is limited but
now and then I stumble on some Java article (e.g. [1]) that claims
that they can slow things down. That's no problem if there's no
additional cost added to code which doesn't use finalizers.


Yes, having lots of finalizers could affect GC performance, but that hasn't 
changed.  There are things we could do to speed it up, if it became a 
serious bottleneck - for example, we currently look at all the weak 
pointers on every GC, but we could separate them by generation like we do 
for threads.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread Dougal Stanton

On Wed, Jan 14, 2009 at 3:12 PM, Neil Mitchell  wrote:

>> 2) In Python it is possible to import modules inside a function.
>>
>>   In Haskell something like:
>>
>>   joinPath' root name =
>>   joinPath [root, name]
>>   importing System.FilePath (joinPath)
>
> Looks a bit ugly, but kind of useful. I'd make the syntax:
>
> joinPath' root name = joinPath [root,name]
>  where import System.FilePath(joinPath)
>
> It does mean you need to read an entire file to see what functions it
> imports, but perhaps that is the way it should be. I could also
> imagine a syntax:
>
> joinPath' root name = import.System.FilePath.joinPath [root,name]
>
> i.e. doing an import and use at the same time.
>

This can be done with a fully-qualified name (or two). Not quite as
succinct, but I assume the scope of these imports is only local
anyway.

> joinPath root path = jp [root,filename path]
>  where jp = System.FilePath.joinPath
>filename = System.FilePath.takeFileName

or

> joinPath root path = System.FilePath.joinPath 
> [root,System.FilePath.takeFileName path]


Cheers,

D
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

>>>   As an example:
>>>   foo = u"abc\N{VULGAR FRACTION ONE HALF}"
>>
>> Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax I 
>> want:
>>
>> "foo\E{show i}bar"
>>
>> i.e. embed expressions in strings. I think this would be fantastic.
>
> why not simpy "foo\E{i}bar" ?

What if i is a string? You'd get: foo"i"bar

Having different behaviour for string vs everything else would be equally bad.

>> joinPath' root name = import.System.FilePath.joinPath [root,name]
>>
>> i.e. doing an import and use at the same time.
>
> and why not simply System.FilePath.joinPath (without the import.) ?

That is the same as saying everything is always in scope but fully
qualified. I'd rather have to explicitly say which modules were being
used - I'm not sure my enhanced import idea is a good idea at all.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2

2009-01-14 Thread Sigbjorn Finne


Thanks Simon,

great stuff; I like the introduction of these  'native code finalizers', 
they've

been sorely missed at times.

You don't say, but will there be a dynamic check to catch such re-entries?

--sigbjorn

On 1/14/2009 04:14, Simon Marlow wrote:
By popular demand, GHC 6.10.2 will support finalizers that are 
actually guaranteed to run, and run promptly.  There aren't any API 
changes: this happens for finalizers created using newForeignPtr as 
normal.


However, there's a catch.  Previously it was possible to call back 
into Haskell from a finalizer (finalizers are C functions), by using 
foreign import "wrapper" or foreign export.  According to the FFI 
spec, whether this is allowed or not is "system dependent".  In GHC 
6.10.1 and earlier it was allowed, but in 6.10.2 and later it is not.  
The reason being that C finalizers are now executed directly by the 
GC, when the runtime is not in a position to handle callbacks.


You can still have fully-fledged Haskell finalizers if you want: we 
have Foreign.Concurrent.newForeignPtr for that purpose.  But those 
finalizers are not subject to the same promptness guarantees that you 
get with C finalizers - they run in a separate thread, and are not 
guaranteed to be run at program exit.


We'll make sure this is documented prominently in the 6.10.2 release 
notes, but I thought a heads-up would be a good idea right now as it 
turns out that there are existing libraries (e.g. LLVM) that will be 
affected.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

2009-01-14 Thread minh thu

2009/1/14 Neil Mitchell :
> Hi
>
>> 1) In a Python string it is available the \U{name} escape, where name is
>>   a character name in the Unicode database.
>>
>>   As an example:
>>   foo = u"abc\N{VULGAR FRACTION ONE HALF}"
>
> Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax I 
> want:
>
> "foo\E{show i}bar"
>
> i.e. embed expressions in strings. I think this would be fantastic.

Hi,

why not simpy "foo\E{i}bar" ?

>> 2) In Python it is possible to import modules inside a function.
>>
>>   In Haskell something like:
>>
>>   joinPath' root name =
>>   joinPath [root, name]
>>   importing System.FilePath (joinPath)
>
> Looks a bit ugly, but kind of useful. I'd make the syntax:
>
> joinPath' root name = joinPath [root,name]
>  where import System.FilePath(joinPath)
>
> It does mean you need to read an entire file to see what functions it
> imports, but perhaps that is the way it should be. I could also
> imagine a syntax:
>
> joinPath' root name = import.System.FilePath.joinPath [root,name]
>
> i.e. doing an import and use at the same time.

and why not simply System.FilePath.joinPath (without the import.) ?

Cheers,
Thu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] some ideas for Haskell', from Python

Hi

> 1) In a Python string it is available the \U{name} escape, where name is
>   a character name in the Unicode database.
>
>   As an example:
>   foo = u"abc\N{VULGAR FRACTION ONE HALF}"

Hmm, looks nice, and sensible. But as soon as you've got \N{} syntax I want:

"foo\E{show i}bar"

i.e. embed expressions in strings. I think this would be fantastic.

> 2) In Python it is possible to import modules inside a function.
>
>   In Haskell something like:
>
>   joinPath' root name =
>   joinPath [root, name]
>   importing System.FilePath (joinPath)

Looks a bit ugly, but kind of useful. I'd make the syntax:

joinPath' root name = joinPath [root,name]
  where import System.FilePath(joinPath)

It does mean you need to read an entire file to see what functions it
imports, but perhaps that is the way it should be. I could also
imagine a syntax:

joinPath' root name = import.System.FilePath.joinPath [root,name]

i.e. doing an import and use at the same time.

Nice ideas, but they probably want implemented in a Haskell compiler
and using in real life before they are ready for Haskell' like
thoughts.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2

2009-01-14 Thread Johan Tibell

On Wed, Jan 14, 2009 at 1:14 PM, Simon Marlow  wrote:
> By popular demand, GHC 6.10.2 will support finalizers that are actually
> guaranteed to run, and run promptly.  There aren't any API changes: this
> happens for finalizers created using newForeignPtr as normal.

Does this effect GC performance even if you don't use finalizers?

My knowledge of how finalizers affect GC performance is limited but
now and then I stumble on some Java article (e.g. [1]) that claims
that they can slow things down. That's no problem if there's no
additional cost added to code which doesn't use finalizers.

1. 
http://java2go.blogspot.com/2007/09/javaone-2007-performance-tips-2-finish.html

Cheers,

Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] some ideas for Haskell', from Python


Hi.

There are two features found in Python language, that I would like to 
see in Haskell.


1) In a Python string it is available the \U{name} escape, where name is
   a character name in the Unicode database.

   As an example:
   foo = u"abc\N{VULGAR FRACTION ONE HALF}"

2) In Python it is possible to import modules inside a function.

   In Haskell something like:

   joinPath' root name =
   joinPath [root, name]
   importing System.FilePath (joinPath)



Thanks  Manlio Perillo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] walking a directory tree efficiently

Don Stewart ha scritto:

manlio_perillo:

Hi.

During a tentative (quite unsuccessfull) to convert a simple Python
script that prints on stdout a directory and all its subdirectory [1] in
a good Haskell (mostly to start to do real practice with the language),
I came across this blog post:

http://blog.moertel.com/articles/2007/03/28/directory-tree-printing-in-haskell-part-three-lazy-i-o

Since recently I read about alternatives to lazy IO (like iteratee), I'm
curious to know if a flexible, efficient and safe alternative exists,
for the task of display a directory tree.

[1] http://paste.pocoo.org/show/99523/

If you can do it with strict IO in Python, do the same thing in Haskell
with System.IO.Strict.
It should be mechanical to translate Python

programs directly into naive IO-based Haskell using strict IO. Boring,
but mechanical.

But that's not the purpose of what I'm doing ;).

I'm trying to practice with Haskell, by converting small Python scripts
I have written.

I hope, in future, to write a "big" program in Haskell.

There's no iteratee/fold-based IO system yet.

Yes, I know.

By the way, I have managed to have a working program:
http://hpaste.org/13919

I would like to receive some advices:
1) I have avoided the do notation, using functions like liftM.
Is this a good practice?
Is this as efficient as using do notation?
2) I have written some support functions: mapM' and filterM'
Are they well written and generic?
Are they already available in some package?
Can you suggest better names?
3) I find
(,) node `liftM` walkTree' path
not very readable.
Is it possible to express it in a more (not too much) verbose way?

Thanks Manlio Perillo

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Maintaining laziness

2009-01-14 Thread Henning Thielemann



On Tue, 13 Jan 2009, Jan Christiansen wrote:

I would be very interested in functions that can be improved with respect to 
non-strictness as test cases for my work.


See the List functions in
  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utility-ht

Version 0.0.1 was before applying StrictCheck, 0.0.2 after processing its 
suggestions. I have stopped when I saw that it repeatedly shows examples 
where I expect, that they are unresolvable.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] about System.Posix.Files.fileAccess


Hi.

This is of course a personal opinion, but I think the interface of:
fileAccess :: FilePath -> Bool -> Bool -> Bool -> IO Bool
http://haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#v:fileAccess

is not very good.

Is it possible to design (in theory) a better interface?



Thanks  Manlio Perillo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANN] Working with HLint from Emacs

2009-01-14 Thread Alex Ott

> "AV" == Andrea Vezzosi writes:
 AV> Does it also let you apply a suggestion automatically?  

Not, i'll look for this suggestion, but i'm not sure, that this is possible 

--
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/   http://xtalk.msk.su/~ott/
http://alexott-ru.blogspot.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: real haskell difficulties (at least for me)


Erik de Castro Lopo wrote:

Don Stewart wrote:


Well, the number one thing is to use Cabal and the cabal-install tool.
That is the simplest way to avoid headaches.


I'm sure cabal  works very  well for many people, but for anyone who
has used Debian based distributions for some time,  cabal really
does seem like a backward step.

For instance, I regularly develop on 6 machines; personal laptop,
home desktop, 2 work desktops and 2 work build machines.

At work, the main output of my development work is Debian packages
(which get installed on hundreds of machines), and the Debian packages
I create have build depends on whatever compilers and libraries are
required to build them. We also have a build bot that runs nightly
in a clean chroot for each package so that build depends can  be
verified to be correct.

However, if I install compilers or libraries using cabal there is
no package to build depend on, breaking a system which currently
works very, very  well for all the code we build in C, C++ and
Ocaml.


Just in case this isn't clear yet - Cabal is not meant to be a replacement 
for native Debian packages, it is supposed to let the Debian folks package 
Haskell stuff more easily.  We didn't want to duplicate everything that a 
good OS packaging system does in Cabal, that's just a waste of time and 
likely to conflict with what the OS packager is already doing.


Sounds like the Debian folks could use some help with automatically 
packaging Cabal packages, though.


Cheers,
Simon

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Recursive modules, GHC /= Report?

2009-01-14 Thread Thorkil Naur

Hello,

On Wednesday 14 January 2009 12:59, Mauricio wrote:
> Hi,
> 
> Here:
> 
> http://www.haskell.org/onlinereport/modules.html
> 
> I read:
> 
>"Modules may reference other modules via
>explicit import declarations, each giving
>the name of a module to be imported and
>specifying its entities to be imported.
>Modules may be mutually recursive."
> 
> However, I get this from GHC:
> 
> ---
> Module imports form a cycle for modules:
>main:Main
>  imports: Control.Concurrent.MVar GtkMostrarConfig GtkLerECG
>   Graphics.UI.Gtk
>main:GtkMostrarConfig
>  imports: Control.Concurrent.MVar Graphics.UI.Gtk Main
> ---
> 
> Aren't cycles of modules just recursive modules? Why
> wasn't that allowed?

Have you looked at 
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#mutual-recursion
 ? 
I never tried this myself, but it seems to explain some important details 
about how to compile mutually recursive modules using GHC.

> 
> Thanks,
> Maurício
> 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

Best regards
Thorkil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: databases in Haskell & type-safety

2009-01-14 Thread Mauricio


Mauricio> No. Only sqlite3_exec with INSERT, SELECT stuff,
Mauricio> and saving everything that needs structure in pseudo-xml
Mauricio> strings. Not that efficient, but easy to change to blobs when
Mauricio> everything is ready and tested.

I see...I'm thinking to maybe store only paths for bigger BLOBs, but
still there is need to store smaller (thumbnails pics) ones...



You can always uuencode the pictures. Package 'dataenc'
seems nice, although I have not used it.

Best,
Maurício

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] HEADS UP: finalizer changes coming in GHC 6.10.2

By popular demand, GHC 6.10.2 will support finalizers that are actually 
guaranteed to run, and run promptly.  There aren't any API changes: this 
happens for finalizers created using newForeignPtr as normal.


However, there's a catch.  Previously it was possible to call back into 
Haskell from a finalizer (finalizers are C functions), by using foreign 
import "wrapper" or foreign export.  According to the FFI spec, whether 
this is allowed or not is "system dependent".  In GHC 6.10.1 and earlier it 
was allowed, but in 6.10.2 and later it is not.  The reason being that C 
finalizers are now executed directly by the GC, when the runtime is not in 
a position to handle callbacks.


You can still have fully-fledged Haskell finalizers if you want: we have 
Foreign.Concurrent.newForeignPtr for that purpose.  But those finalizers 
are not subject to the same promptness guarantees that you get with C 
finalizers - they run in a separate thread, and are not guaranteed to be 
run at program exit.


We'll make sure this is documented prominently in the 6.10.2 release notes, 
but I thought a heads-up would be a good idea right now as it turns out 
that there are existing libraries (e.g. LLVM) that will be affected.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Recursive modules, GHC /= Report?

2009-01-14 Thread Mauricio


Hi,

Here:

http://www.haskell.org/onlinereport/modules.html

I read:

  "Modules may reference other modules via
  explicit import declarations, each giving
  the name of a module to be imported and
  specifying its entities to be imported.
  Modules may be mutually recursive."

However, I get this from GHC:

---
Module imports form a cycle for modules:
  main:Main
imports: Control.Concurrent.MVar GtkMostrarConfig GtkLerECG
 Graphics.UI.Gtk
  main:GtkMostrarConfig
imports: Control.Concurrent.MVar Graphics.UI.Gtk Main
---

Aren't cycles of modules just recursive modules? Why
wasn't that allowed?

Thanks,
Maurício


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: databases in Haskell & type-safety

2009-01-14 Thread Duncan Coutts

On Wed, 2009-01-14 at 10:19 +0800, Xie Hanjian wrote:
> * John Goerzen  [2009-01-13 12:37:45 -0600]:
> 

> > To anyone annoyed with Haskell's library install process: you have no
> > idea how good you have it unless you've tried Ruby and rails.
> 
> Disagree. Rubygems is fairly easy to use. At lease, I can guess how to
> uninstall a package by trying 'gem uninstall foobar', but failed by
> trying 'cabal uninstall/remove foobar' :-)

It's a fair point. Patches gratefully accepted! :-)


Duncan

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Slow Text.JSON parser

2009-01-14 Thread Ketil Malde

Sjoerd Visscher  writes:

> JSON is a UNICODE format, like any modern format is today. ByteStrings
> are not going to work.

Well, neither is String as used in the code I responded to.  I'm not
intimately familiar with JSON, but I believe ByteStrings would work on
UTF-8 input, and both ByteString and String would fail on UTF-16 and
UTF-32. 

> If everybody starts yelling "ByteString" every time String performance
> is an issue, I don't see how Haskell is ever going to be a "real world
> programming language".

Insisting on linked lists of 32-bit characters isn't going to help,
either.  I'm also looking forward to a fast, robust, and complete
UniCode support, but the OP asked about performance.

-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-beginners] Re: [Haskell-cafe] The problem with Monads...

2009-01-14 Thread Peter Verswyvelen

>
> I have written a reference manual for the basic Haskell monad functions, "A
> Tour of the Haskell Monad functions". It contains a lot of examples. You can
> find it at:
>  http://members.chello.nl/hjgtuyl/tourdemonad.html


Wow! I like these examples. I'm a pragmatist, and although Haskell gave me
the most intense joy I ever experienced with programming (and also
frustrations ;-), I find it extremely difficult to learn it from research
papers.

But these small examples are exactly what I need, because my brain will
easier recognize a pattern match with the specific examples, than with the
abstract explanation (and I was pretty good at abstract algebra, but that's
20 years ago, and I filled these 2 decades with lots and lots of imperative
and OO hacking ;-).

I wish every function in every module in the documentation had an "examples"
link next to the "source" link, or a link to examples on the wiki or
something.

I guess the smart computer scientists here will tell me that I need to lift
my brain to learn to recognize abstract patterns, but I'm afraid this is not
something that is given to all of us, certainly not in the short term. But I
still want to enjoy Haskell, so keep the short examples coming :)


>
> As far as I know, there is no reference guide for advanced monads, like the
> Reader, Writer and State monads.
>
> --
> Regards,
> Henk-Jan van Tuyl
>
>
> --
> http://functor.bamikanarie.com
> http://Van.Tuyl.eu/
> --
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Issues with posix-realtime package


Galchin, Vasili ha scritto:

Hi Manlio,

 Are you now talking about code in Code from HsUnix.h and execvpe.h?



Yes.


Manlio
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: The problem with Monads...

2009-01-14 Thread Rafael Gustavo da Cunha Pereira Pinto

Wadler's examples are way better than the ones in the documentation. But
without his explanations of what he is doing, the examples alone are pretty
worthless.

I agree that all_about_monads could be a better source for the
documentation, at least for completeness. But even there I would consider
choosing simpler examples, like Wadler's expression evaluator.




On Tue, Jan 13, 2009 at 21:07, Benedikt Huber  wrote:

> Rafael Gustavo da Cunha Pereira Pinto schrieb:
>
>> Yes, I've read it twice, and it is a nice explanation that "yes, the
>> reader monad is an application and is a monad". How do I use it? Why not the
>> function itself? How would the plumbing work in a real world example?
>>
> Hi Rafael,
>
> First of all, I agree that the documentation for mtl should be improved.
> Especially Control.Monad.RWS and Control.Monad.List really need some more
> information.
>
> The documentation for the Reader and Identity monad are quite detailled
> though. They seem to be "inspired" by
> http://www.haskell.org/all_about_monads/, which also has documentation on
> Writer and Cont.
>
> Control.Monad.List is a good example for the lack of documentation:
> There is a single sentence at the beginning
> > "The List monad."
> and then one declaration
> > newtype ListT m a = ListT { runListT :: m [a] }
> while the important information is hidden as one of many instance
> declarations:
> > Monad m => Functor (ListT m)
> > Monad m => MonadPlus (ListT m)
>
> Btw, the quality of the examples in Control.Monad.Reader is debutable. From
> Example 1:
>
> > -- The Reader monad, which implements this complicated check.
> > calc_isCountCorrect :: Reader Bindings Bool
> > calc_isCountCorrect = do
> >count <- asks (lookupVar "count")
> >bindings <- ask
> >return (count == (Map.size bindings))
>
> I think it is wrong (or weird at least) to call the function a 'Reader
> monad'; the name 'calc_isCountCorrect' is horrible too (because of the calc_
> prefix),  Finally, implementing
>
> > isCountCorrect :: Bindings -> Bool
> > isCountCorrect bs = (bs Map.! "count") == Map.size bs
>
> using the Reader monad will convince everybody _not_ to use it.
>
> A suggestion: If license permits it, short versions of the articles on
> all_about_monads would make a great documentation for mtl (except for RWS
> and List, which are missing).
>
> benedikt
>
>
>
>> BTW, the article is really great as an brief introduction to monad
>> transformers. For the whole concept of monads, my all time favorite is "The
>> Haskell Programmer's Guide to the IO Monad" by Stefan Klinger.
>>
>> Chapters 14 to 19 of "Real World Haskell" also have a good introduction on
>> the usage of the monads, but it lacks other monads, like the RWS or the
>> Continuation...
>>
>> See, that is my point. The mathematical concept of monads is very
>> palatable. The idea that monads are either patterns or structures to hide
>> computations in sequence is also very easy to see. But how do we use them?
>> Why should I use a Writer monad when I can use a (a,w) tuple?
>>
>>
>>
>> On Tue, Jan 13, 2009 at 13:51, Jonathan Cast 
>> > jonathancc...@fastmail.fm>> wrote:
>>
>>On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira
>> Pinto
>>wrote:
>> >
>> > Last night I was thinking on what makes monads so hard to take, and
>> > came to a conclusion: the lack of a guided tour on the implemented
>> > monads.
>>
>>...
>>
>> > Inspired by the paper "Functional Programming with Overloading and
>> > Higher-Order Polymorphism",
>> > Mark P Jones
>> > 
>> (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html
>>)
>> >   Advanced School of Functional Programming, 1995.
>> >
>> > SO WHAT?
>>
>>So have you read Jones' paper?  Or do you have a *concrete* explanation
>>of how it differs from your desired `guided tour'?
>>
>>jcc
>>
>>
>>
>>
>>
>> --
>> Rafael Gustavo da Cunha Pereira Pinto
>> Electronic Engineer, MSc.
>>
>>
>> 
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>


-- 
Rafael Gustavo da Cunha Pereira Pinto
Electronic Engineer, MSc.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [ANN] Working with HLint from Emacs