Re: [Haskell-cafe] New slogan for haskell.org

[Henning Thielemann]

On Tue, 11 Dec 2007 [EMAIL PROTECTED] wrote:

> The Haskell one is dominated by the technical terms, while the Python
> one is by more generic features. Let's break them down:

Plese, not again. Did you follow the earlier phases of that thread?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] library to read/write audio files

[Henning Thielemann]

On Tue, 11 Dec 2007, Jed Brown wrote:

> Perhaps you are looking for storablevector which is a direct
> generalization of bytestring from Word8 to any Storable.  It is not in
> hackage yet, but seems stable.  There isn't a `lazy' version, but that
> could be changed.
>
> http://code.haskell.org/~sjanssen/storablevector

Great, that's what I asked for on this list recently ...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] library to read/write audio files

[Henning Thielemann]

On Tue, 11 Dec 2007, John Lato wrote:

> I've been working on a library to encode/decode audio files (wave,
> aiff, etc.) to and from lazy bytestrings, and it's finally in a form
> where I'm willing to share.  It's available at
> http://mml.music.utexas.edu/jwlato/HSoundFile/, lightly cabalized and
> haddock-ified.  The basic item is a Data.SoundFile datatype and a
> SndFileCls class.  Each file format (wave, etc.) has a datatype with
> instances of SndFileCls and Data.Binary (thanks to Don S. for
> suggesting Data.Binary).  At least that's the idea, I've only
> implemented the Wave format so far, but I wanted to make it easy to
> add new formats.

These are great news. So far I used Sox to write files in several formats
- reading is not nicely possible with this approach, because Sox does not
output header information.

Would you like to advertise your library at:
  http://haskell.org/haskellwiki/Applications_and_libraries/Music_and_sound

I also reply to the Haskell Art Mailing list.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] New slogan for haskell.org

[Marc A. Ziegert]

i did just read the haskell description from galois [1]. i like
 1) "...enabling much higher coding efficiency, in addition to formalisms that 
greatly ease verification."
 2) "All programming languages suffer from a semantic gap:..."

maybe we could compose sth similar to 1) to introduce static typed functional 
programming, and to 2) to introduce some strange new buzzwords coming with 
haskell.
i'm sure, there will be no problem in using scary words, iff we introduce them 
as easy-to-handle master solutions to all incurable programming diseases. ;)



...imho the present slogan [2] is not that bad, too.

- marc

[1] 
[2] 



signature.asc
Description: This is a digitally signed message part.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Haskell-mode 2.4

[Stefan Monnier]

Here's for Xmas, version 2.4 of the Haskell-mode package.
Haskell-mode is an Elisp package to support editing Haskell in Emacs.
See the home page at

   http://www.iro.umontreal.ca/~monnier/elisp/


-- Stefan


Changes since 2.3:

* Update license to GPLv3.

* New derived major mode for .hsc files.

* Removed the C-c C-r binding to reload a file.  You can still call
  inferior-haskell-reload-file (and/or bind it to your favorite key,
  including C-c C-r) or you can now use C-u C-c C-l.

* C-c C-d looks up the symbol at point in the Haddock docs.

* Haddock comments are highlighted with font-lock-doc-face if it exists.

* Use `tex' rather than `latex' for haskell-literate.

* inf-haskell.el tries to find the root of the module hierarchy to determine
  the root of a project (either by looking for a Cabal file or relying on
  the `module' declaration line).  If all works well, this will make C-c C-l
  automatically switch to the root dir, so that dependencies in other
  directories are automatically found.  If it doesn't, complain and/or set
  inferior-haskell-find-project-root to nil.

* The new command haskell-hoogle helps you query Hoogle from Emacs.


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

Re: [Haskell-cafe] New slogan for haskell.org

[Derek Elkins]

On Tue, 2007-12-11 at 23:06 -0500, [EMAIL PROTECTED] wrote:
> On 2007.12.12 03:29:13 +0100, Wolfgang Jeltsch <[EMAIL PROTECTED]> scribbled 
> 1.6K characters:
> > Am Mittwoch, 12. Dezember 2007 03:12 schrieb [EMAIL PROTECTED]:
> > > FWIW to the discussion about changing the main page, I was reading the 
> > > CUFP
> > > paper and I saw some germane comments (and the writer is apparently one
> > > Noel Welsh, whose name I don't see in the thread); the context is a
> > > discussion (pg 17) of various members or potential members of the Haskell
> > > community and how supported they are:
> > >
> > >  "What are the needs of the potential programmer? People program to solve
> > > prob- lems; so there had better be a clear statement of what kinds of
> > > problem the language is good for. The Python community does a good job of
> > > this on python.org: "Python is a dynamic object-oriented programming
> > > language that can be used for many kinds of software development. It 
> > > offers
> > > strong support for integration with other languages and tools, comes with
> > > extensive standard libraries, and can be learned in a few days."
> > >
> > >  Compare this with the equivalent from haskell.org: "Haskell is a
> > >  general purpose, purely functional programming language featuring static
> > >  typing, higher-order functions, polymorphism, type classes, and monadic
> > >  effects. Haskell compilers are freely available for almost any computer."
> > > If you understand all that, you don't need to be here: you're already a
> > > Haskell programmer."
> >
> > Note however that also the Python slogan isn’t so much about solving 
> > problems.
> > And it also contains technical terms: “dynamic object-oriented programming
> > language” instead of “static typing, higher-order functions, polymorphism,
> > type classes, and monadic effects”.
> >
> > Best wishes,
> > Wolfgang
> 
> The Haskell one is dominated by the technical terms, while the Python one is 
> by more generic features. Let's break them down:
> 
> > Python is a dynamic object-oriented programming language
> > It can be used for many kinds of software development.
> > It offers:
> > > strong support for integration with other languages and tools,
> > > comes with extensive standard libraries
> > > and can be learned in a few days."
> 
> It uses two technical terms, one of which is extremely common and understood 
> (or at least, they think they understand it) by the vast majority of 
> programmers, and another which even if you don't know anything about 
> static/dynamic, still sounds neat. Dynamic! Neato! *power* *bop* Leaping 
> librarians Batman!
> 
> Of the rest of the description, it is all touchy-feely: it reassures you that 
> it'll be able to do what you ask it to do; it'll play nice with your stuff; 
> it's quick and easy to learn; and you won't have to mess around with 
> installing stuff, it's brain-dead simple and 'all there'.
> 
> Now let's look at the Haskell one.
> 
> > "Haskell is a general purpose,
> 
> OK, that's good; it's not as emphatic or clear as "It can be used for many 
> kinds of software development", but it does mean more or less the same thing.
> 
> > purely functional programming language
> 
> Oh dear. It's 'functional', and I've heard that means scary weird 
> mathematical stuff (first technical term). But I wanted to learn something 
> new, so let's look at something else. But Wait, what's this 'purely' 
> business? If it's purely functional, doesn't that mean I won't be able to my 
> usual stuff, which is presumably impure? (Technical term the second; parity 
> achieved with Python description).
> 
> > > featuring:
> 
> Equivalent to "It offers"
> 
> > > static typing
> 
> Technical term the third. Mention of static typing is probably on balance 
> bad: If you are the kind of sort of cutting-edge programmer, then you are 
> more familiar with dynamic languages like Python and Ruby which liberated you 
> from the horrors of languages like Java and C. And these Haskell guys are 
> daring to suggest you might want to go *back*? If you aren't familiar, then 
> static just sounds bad - inert, unbending, rigid and unpleasant. 'I stopped 
> watching that show - its plot was just too static.'
> 
> It's probably too late now, but I think a better name would've been 'securely 
> typed'. :)
> 
> 
> > > higher-order functions,
> 
> Term the fourth. Even more obscure. Lispers might appreciate this entry 
> though.
> 
> > > polymorphism,
> 
> Fifth term. This one is good: polymorphism is used elsewhere, and sounds 
> friendly.
> 
> > > type classes,
> 
> Sixth.
> 
> OK, seriously, what group besides those who already understand Haskell would 
> actually know what type classes are or care? If they have to be mentioned, 
> might as well say something more useful (I dunno what, maybe something such 
> as 'they are like multiple inheritance or interfaces, but more powerful').
> 
> > > and monadic effects.
> 
> This actually sounds even more

[Haskell-cafe] Folding Integrals

[Mattias Bengtsson]

I found myself writing this for an Euler-problem:

> digits :: Int -> [Int]
> digits i | i < 10= [i]
>  | otherwise = i `mod` 10 : digits ( i `div` 10 )

And i realised it was quite some time ago (before this function) i had
actually written any explicitly recursive function. I managed to finish
the Euler problem however and i was happy about that.
However it frustrated me that i couldn't find a nice way to abstract
away that explicit recursion but today i managed to! :)
My first thought was that the solution probably was using some function
like scanr, mapAccum or unfoldr to do it (especially the name of unfoldr
made me think that it would be the solution). 
After abstracting my digits function i realised that it wasn't anything
more than a fold over the Int type (treating the Int as a sequence of
digits). "i `mod` 10" and "i `div` 10" would be nothing more than the
head and tail functions (that corresponds to the (:) pattern matching). 

This is what i came up with finally:
(I'm not 100% sure on the foldr- and foldl names though. Not sure if the
semantics are correct, perhaps the function names should be switched?)

> module FoldIntegral (foldr, foldl) where 
> import Prelude hiding (foldr,foldl,head,tail)
> 
> head, tail :: Integral a => a -> a
> head i = i `mod` 10
> tail i = i `div` 10
> 
> foldr :: Integral a => (a -> b -> b) -> b -> a -> b
> foldr f z i 
> | i == 0= z
> | otherwise = foldr f (h `f` z) t
> where h = head i
>   t = tail i
> 
> foldl :: Integral b => (a -> b -> a) -> a -> b -> a
> foldl f z i 
> | i == 0= z
> | otherwise = (foldl f z t) `f` h
> where h = head i
>   t = tail i

Which would make the digits function a one-liner:

> digits = foldr (:) [] 

I hope someone enjoys this.

Mattias


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] New slogan for haskell.org

[Don Stewart]

stevelihn:
>I have not used Haskell to write large scale program, but I am
>certainly interested to know the answer to these questions.
>
>Can Haskell offer the following as Pythoner boasts?
>1. can be used for many kinds of software development. (some may argue
>yes, but different kinds from what python is good for.)
>2. It offers strong support for integration with other languages and tools
>(FFI? Is the support strong?)
>3. comes with extensive standard libraries (this is a yes, and is getting
>better every day)
>4. and can be learned in a few days (very unlikely, maybe a few months to
>a year)

These are vague conditions we can easily address:

1. General purpose languages -- we write OS kernels and web sites in
   Haskell -- you can clearly use it for anything in between as well.

2. The FFI in Haskell is perhaps the most powerful out there.
   You can import C or export Haskell to C with a single line FFI decl.

3. Libs are in a good state, as you've seen.

4. You can't learn the entire Python language in a few days if all
   you've done is Prolog. So it should be qualified with "if you know
   Perl or Ruby"

Toss in fast native code, debuggers and profilers, built for robustness,
along with powerful concurrency and parallelism, and you've got some
marketing hype for Haskell :)

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

Re: [Haskell-cafe] New slogan for haskell.org

[gwern0]

On 2007.12.12 03:29:13 +0100, Wolfgang Jeltsch <[EMAIL PROTECTED]> scribbled 
1.6K characters:
> Am Mittwoch, 12. Dezember 2007 03:12 schrieb [EMAIL PROTECTED]:
> > FWIW to the discussion about changing the main page, I was reading the CUFP
> > paper and I saw some germane comments (and the writer is apparently one
> > Noel Welsh, whose name I don't see in the thread); the context is a
> > discussion (pg 17) of various members or potential members of the Haskell
> > community and how supported they are:
> >
> >  "What are the needs of the potential programmer? People program to solve
> > prob- lems; so there had better be a clear statement of what kinds of
> > problem the language is good for. The Python community does a good job of
> > this on python.org: "Python is a dynamic object-oriented programming
> > language that can be used for many kinds of software development. It offers
> > strong support for integration with other languages and tools, comes with
> > extensive standard libraries, and can be learned in a few days."
> >
> >  Compare this with the equivalent from haskell.org: "Haskell is a
> >  general purpose, purely functional programming language featuring static
> >  typing, higher-order functions, polymorphism, type classes, and monadic
> >  effects. Haskell compilers are freely available for almost any computer."
> > If you understand all that, you don't need to be here: you're already a
> > Haskell programmer."
>
> Note however that also the Python slogan isn’t so much about solving problems.
> And it also contains technical terms: “dynamic object-oriented programming
> language” instead of “static typing, higher-order functions, polymorphism,
> type classes, and monadic effects”.
>
> Best wishes,
> Wolfgang

The Haskell one is dominated by the technical terms, while the Python one is by 
more generic features. Let's break them down:

> Python is a dynamic object-oriented programming language
> It can be used for many kinds of software development.
> It offers:
> > strong support for integration with other languages and tools,
> > comes with extensive standard libraries
> > and can be learned in a few days."

It uses two technical terms, one of which is extremely common and understood 
(or at least, they think they understand it) by the vast majority of 
programmers, and another which even if you don't know anything about 
static/dynamic, still sounds neat. Dynamic! Neato! *power* *bop* Leaping 
librarians Batman!

Of the rest of the description, it is all touchy-feely: it reassures you that 
it'll be able to do what you ask it to do; it'll play nice with your stuff; 
it's quick and easy to learn; and you won't have to mess around with installing 
stuff, it's brain-dead simple and 'all there'.

Now let's look at the Haskell one.

> "Haskell is a general purpose,

OK, that's good; it's not as emphatic or clear as "It can be used for many 
kinds of software development", but it does mean more or less the same thing.

> purely functional programming language

Oh dear. It's 'functional', and I've heard that means scary weird mathematical 
stuff (first technical term). But I wanted to learn something new, so let's 
look at something else. But Wait, what's this 'purely' business? If it's purely 
functional, doesn't that mean I won't be able to my usual stuff, which is 
presumably impure? (Technical term the second; parity achieved with Python 
description).

> > featuring:

Equivalent to "It offers"

> > static typing

Technical term the third. Mention of static typing is probably on balance bad: 
If you are the kind of sort of cutting-edge programmer, then you are more 
familiar with dynamic languages like Python and Ruby which liberated you from 
the horrors of languages like Java and C. And these Haskell guys are daring to 
suggest you might want to go *back*? If you aren't familiar, then static just 
sounds bad - inert, unbending, rigid and unpleasant. 'I stopped watching that 
show - its plot was just too static.'

It's probably too late now, but I think a better name would've been 'securely 
typed'. :)


> > higher-order functions,

Term the fourth. Even more obscure. Lispers might appreciate this entry though.

> > polymorphism,

Fifth term. This one is good: polymorphism is used elsewhere, and sounds 
friendly.

> > type classes,

Sixth.

OK, seriously, what group besides those who already understand Haskell would 
actually know what type classes are or care? If they have to be mentioned, 
might as well say something more useful (I dunno what, maybe something such as 
'they are like multiple inheritance or interfaces, but more powerful').

> > and monadic effects.

This actually sounds even more obscure and scary than just monads would be, and 
I've seen it oft remarked that monads should just be called soft fluffy 
things...

Seventh.

> > Haskell compilers are freely available for almost any computer."

If the reader is still interested and still takes Haskell seriously after 
puzzling

Re: [Haskell-cafe] New slogan for haskell.org

[Brandon S. Allbery KF8NH]

On Dec 11, 2007, at 22:47 , Steve Lihn wrote:

1. can be used for many kinds of software development. (some may  
argue yes, but different kinds from what python is good for.)


This question is somewhat tied to (3), but really the answer is "it  
can be, but you may have to think differently about the problem to  
formulate a good program".  (See below.)


* Domain Specific Language (who needs it? other than academics and  
Wall Streeter?)


DSELs can be thought of as a programming methodology; as such, it has  
wide applicability, but most programmers don't think that way.  Tcl  
was originally positioned as a "DSEL enabler" (write composable  
functions in C, tie them together in Tcl), but most programmers  
"don't get it" and so don't tend to use it as such.  More recently,  
Lua seems to be using a similar philosophy with a little more success  
--- but mainly by limiting it to something which most programmers can  
deal with.  Also compare how Perl and Python monoliths have replaced  
the original Unix philosophy in which the shell is a DSEL enabler  
(composing single-function programs like "cat" and "sort").


When it comes down to it, Haskell's strengths are only realizeable if  
you approach programming problems in a different way from most common  
languages.  It's a fairly big leap, and arguably Haskell won't  
compete well in the mainstream until more programmers have made that  
leap.


--
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] IO is a bad example for Monads

[Alex Jacobson]

It might help to point out that its easy to end up with memory/space 
leaks in Java/python/ruby/perl too.  Also stack overflow is really easy. 
 Also, you can get into really deep badness if you do anything 
interesting with concurrency because of the global interpreter lock etc.


As far as pickling goes, HAppS-Data makes it trivial to pickle most 
anything into XML or name/value pairs so that is no longer a valid 
complaint.


-Alex-


Dan Weston wrote:

Hans van Thiel wrote:

On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote:
Maybe there are also patient people in the outside world so that we 
can still expose Haskell to the outside world while not trying to 
attract quick-and-dirty hackers. ;-) 

But who are those people? And what harm can they possibly do, assuming
they fit the derogatory description?


I fear those people can do vast amounts of damage. :(

When inept programming yields the wrong result, it is clear (even to the 
inept) that the program is bad.


When the result is correct but there are egregious time or space leaks, 
it is "clear" to everyone but the Haskell guru that it "must" be the 
programming language that is deficient, and will be duly flamed far and 
wide. This perception will be impossible to reverse when it gains 
traction (and nothing ever goes away on the Internet).


Seeming "deus ex machina" code changes (perhaps helpfully offered on 
haskell-cafe) to minimize or correct the undesirable runtime behavior 
appear even to many Haskellites to be black magic, accompanied by the 
runes of profile dumps (like knowing what generation 0 and generation 1 
garbage collection is).


Haskell is not a quick-and-dirty language but quite the opposite.  
Haskell’s unique selling propositions are features like type classes, 
higher order functions and lazy evaluation which make life easier in 
the long term.  The downside of these features is that they might 
make life harder in the short term.

I don't know. In a sense Haskell is easier than, for example, C, because
the concept of a function definition is more natural that that of
assignments and loops. The idea that x = 5; x = x + 7 makes sense
requires a complete new way of thinking. OK, once you've been doing it
for a few years switching back to x = 5 + 7 is hard.


I would limit that to say that *denotational* semantic intuition is easy 
to wield in Haskell. Operational semantic intuition is Haskell is very 
non-obvious to the imperative (and many functional) programmers.


Making matters worse, the first is an advantage well-hyped by 
functionistas, the second hurdle is rarely admitted to.


That said, I definitely think that we should make learning the 
language as easy as possible.  But our ultimate goal should be to 
primarily show newcomers the Haskell way of problem solving, not how 
to emulate Python or Java programming in Haskell.

Again, is there a danger of that happening?


Yes. Those absent the necessary humility to approach haskell-cafe with 
open mind and flame-retardant dialog will fall back on what they know: 
transliterated Java/Python with a morass of do blocks and IO monads, 
then (rightly) bash how "ugly" Haskell syntax is when used in this way.


This type of programmer looking to use Haskell casually should sign a 
"benefit of the doubt" contract whereby they assume that any runtime 
suboptimalities derive from their own coding and not from Haskell's 
defects. This is the innate assumption of the curious, the 
self-motivated, the clever. This is not typically the starting 
assumption of the "I'm an expert at Joe-imperative language" hacker who 
took 10 years to perfect his Java skills and expects thereby to jump to 
at least year 5 of Haskell without effort.


I do strongly believe in stimulating the curiosity of all comers, just 
not in giving the false impression that a quick read-through of a few 
tutorials will let you write lightning-fast code, or know when to 
abandon [Char] for something more clever, or where to insert those bangs 
and fold left instead of right, and how ad hoc and parametric 
polymorphism differ, and what Rank-n and existential means (and why you 
can just pickle any object in Python but need to know a half dozen 
abstract things including who Peano was to do the same in Haskell), and 
what the heck an infinite type is, and on and on.


Haskell has definitely been teaching me some serious humility! Possibly 
it is best that those not ready for that lesson might better stick with 
Python.


___
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] New slogan for haskell.org

[Steve Lihn]

I have not used Haskell to write large scale program, but I am
certainly interested to know the answer to these questions.

Can Haskell offer the following as Pythoner boasts?
1. can be used for many kinds of software development. (some may argue yes,
but different kinds from what python is good for.)
2. It offers strong support for integration with other languages and tools
(FFI? Is the support strong?)
3. comes with extensive standard libraries (this is a yes, and is getting
better every day)
4. and can be learned in a few days (very unlikely, maybe a few months to a
year)

What is Haskell good for?
* Domain Specific Language (who needs it? other than academics and Wall
Streeter?)
* smaller program and much less bugs
* concise program logic
* program that can be reasoned (is that the reason Haskell module comes with
so few comments and documentation?)
* highly reusable code (due to higher order function and type class?)
* clear distinction between functional and imperative (is this really an
advantage? almost everything I deal with is IO, network, and db related,
what is left for purely functional?)

A person/team has to be convinced of these "high-level" questions before he
can decide to bet his project on Haskell. That is the thought process I
am struggling through right now.

steve


On Dec 11, 2007 9:12 PM, <[EMAIL PROTECTED]> wrote:

> FWIW to the discussion about changing the main page, I was reading the
> CUFP paper and I saw some germane comments (and the writer is apparently one
> Noel Welsh, whose name I don't see in the thread); the context is a
> discussion (pg 17) of various members or potential members of the Haskell
> community and how supported they are:
>
>  "What are the needs of the potential programmer? People program to solve
> prob-
>  lems; so there had better be a clear statement of what kinds of problem
> the
>  language is good for. The Python community does a good job of this on
>  python.org: "Python is a dynamic object-oriented programming language
> that can
>  be used for many kinds of software development. It offers strong support
> for
>  integration with other languages and tools, comes with extensive standard
>  libraries, and can be learned in a few days."
>
>  Compare this with the equivalent from haskell.org: "Haskell is a
>  general purpose, purely functional programming language featuring static
>  typing, higher-order functions, polymorphism, type classes, and monadic
>  effects. Haskell compilers are freely available for almost any computer."
> If
>  you understand all that, you don't need to be here: you're already a
> Haskell
>  programmer."
>
> --
> gwern
>
> ___
> 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] New slogan for haskell.org

[Wolfgang Jeltsch]

Am Mittwoch, 12. Dezember 2007 03:12 schrieb [EMAIL PROTECTED]:
> FWIW to the discussion about changing the main page, I was reading the CUFP
> paper and I saw some germane comments (and the writer is apparently one
> Noel Welsh, whose name I don't see in the thread); the context is a
> discussion (pg 17) of various members or potential members of the Haskell
> community and how supported they are:
>
>  "What are the needs of the potential programmer? People program to solve
> prob- lems; so there had better be a clear statement of what kinds of
> problem the language is good for. The Python community does a good job of
> this on python.org: "Python is a dynamic object-oriented programming
> language that can be used for many kinds of software development. It offers
> strong support for integration with other languages and tools, comes with
> extensive standard libraries, and can be learned in a few days."
>
>  Compare this with the equivalent from haskell.org: "Haskell is a
>  general purpose, purely functional programming language featuring static
>  typing, higher-order functions, polymorphism, type classes, and monadic
>  effects. Haskell compilers are freely available for almost any computer."
> If you understand all that, you don't need to be here: you're already a
> Haskell programmer."

Note however that also the Python slogan isn’t so much about solving problems.  
And it also contains technical terms: “dynamic object-oriented programming 
language” instead of “static typing, higher-order functions, polymorphism, 
type classes, and monadic effects”.

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

Re: [Haskell-cafe] IO is a bad example for Monads

[Wolfgang Jeltsch]

Am Dienstag, 11. Dezember 2007 18:34 schrieb Tim Newsham:
> […]

> Why is it that every time the topic of teaching basic concepts in
> an easier way comes up there are always two or three replies that
> say "should we bother?  lets filter out the idiots?"

I think that two different things are mixed in this thread:

(1) teaching monadic I/O in a newbie-friendly way

(2) stressing monadic I/O in teaching and shying away from teaching purely
functional solutions

While I support (1), I don’t support (2).

> […]

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

[Haskell-cafe] New slogan for haskell.org

[gwern0]

FWIW to the discussion about changing the main page, I was reading the CUFP 
paper and I saw some germane comments (and the writer is apparently one Noel 
Welsh, whose name I don't see in the thread); the context is a discussion (pg 
17) of various members or potential members of the Haskell community and how 
supported they are:

 "What are the needs of the potential programmer? People program to solve prob-
 lems; so there had better be a clear statement of what kinds of problem the
 language is good for. The Python community does a good job of this on
 python.org: "Python is a dynamic object-oriented programming language that can
 be used for many kinds of software development. It offers strong support for
 integration with other languages and tools, comes with extensive standard
 libraries, and can be learned in a few days."

 Compare this with the equivalent from haskell.org: "Haskell is a
 general purpose, purely functional programming language featuring static
 typing, higher-order functions, polymorphism, type classes, and monadic
 effects. Haskell compilers are freely available for almost any computer." If
 you understand all that, you don't need to be here: you're already a Haskell
 programmer."

--
gwern


pgpdj4pg2URHo.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] class default method proposal

[ajb]

G'day all.

Quoting David Menendez <[EMAIL PROTECTED]>:


This is pretty much how I define Functor and Applicative instances for my
monads. It is admittedly irritating to have to write out the boilerplate,
but  it doesn't seem irritating enough to require a language extension to
eliminate.


In the case of Functor and Applicative, that's true.  Cases where it's
likely to be more useful involve absurdly fine-grained class hierarchies,
like the numeric prelude.  Getting fanciful for a moment, and not claiming
that this is a good structure:

class Plus a b c | a b -> c where
(+) :: a -> b -> c

class Minus a b c | a b -> c where
(-) :: a -> b -> c

class Times a b c | a b -> c where
(*) :: a -< b -> c

class Zero a where
zero :: a

class One a where
one :: a

class (Zero a, Plus a a a, Minus a a a) => Additive a where
negate :: a -> a

negate a = zero - a
a - b = a + negate b

class (Mul a a a, One a) => Multiplicative a where
(^) :: a -> Integer -> a

class (Multiplicative a, Additive a) => Ring a where
fromInteger :: Integer -> a

zero = fromInteger 0
one = fromInteger 1

class (Ring a, Ord a) => OrderedRing a where
abs :: a -> a
abs x = x `max` negate x

signum :: a -> a
-- etc

class (OrderedRing a, Show a) => Num a

You can imagine how unwieldy this would now get if you just wanted to
declare an instance for Num a.

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

Re: [Haskell-cafe] unsubscribe

[gwern0]

On 2007.12.12 09:33:12 +1100, Tim- tigre11 <[EMAIL PROTECTED]> scribbled 2.2K 
characters:
>Very suspicious extension of attachment
>
>Sender:  "Gwern Branwen" <[EMAIL PROTECTED]>
>Recipient:  [EMAIL PROTECTED]
>Subject:  [Haskell-cafe] Software Tools in Haskell
>
>--
>
>[3]avast! Antivirus: Outbound message clean.
>
>Virus Database (VPS): 071210-0, 10/12/2007
>Tested on: 12/12/2007 9:33:52 AM
>avast! - copyright (c) 1988-2007 ALWIL Software.
>
> References
>
>Visible links
>1. mailto:[EMAIL PROTECTED]
>2. mailto:haskell-cafe@haskell.org
>3. http://www.avast.com/

Not very familiar with cryptographic signatures, are you?



--
gwern


pgpsluYDfQYhA.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] unsubscribe

[Tim- tigre11]

Very suspicious extension of attachment


Sender:  "Gwern Branwen" <[EMAIL PROTECTED]>
Recipient:  haskell-cafe@haskell.org
Subject:  [Haskell-cafe] Software Tools in Haskell


---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 071210-0, 10/12/2007
Tested on: 12/12/2007 9:33:52 AM
avast! - copyright (c) 1988-2007 ALWIL Software.
http://www.avast.com


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

Re: [Haskell-cafe] IO is a bad example for Monads

[Conal Elliott]

It may be helpful to distinguish teaching/preaching (a) programming in
Haskell from (b) *functional* programming (in Haskell or otherwise).  Each
focus is present in the conversation.  Perhaps IO helps the former and
hinders the latter.- Conal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] IO is a bad example for Monads

[Dan Weston]

Hans van Thiel wrote:

On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote:
Maybe there are also patient people in the outside world so that we can still 
expose Haskell to the outside world while not trying to attract 
quick-and-dirty hackers. ;-) 

But who are those people? And what harm can they possibly do, assuming
they fit the derogatory description?


I fear those people can do vast amounts of damage. :(

When inept programming yields the wrong result, it is clear (even to the 
inept) that the program is bad.


When the result is correct but there are egregious time or space leaks, 
it is "clear" to everyone but the Haskell guru that it "must" be the 
programming language that is deficient, and will be duly flamed far and 
wide. This perception will be impossible to reverse when it gains 
traction (and nothing ever goes away on the Internet).


Seeming "deus ex machina" code changes (perhaps helpfully offered on 
haskell-cafe) to minimize or correct the undesirable runtime behavior 
appear even to many Haskellites to be black magic, accompanied by the 
runes of profile dumps (like knowing what generation 0 and generation 1 
garbage collection is).


Haskell is not a quick-and-dirty language but quite the opposite.  Haskell’s 
unique selling propositions are features like type classes, higher order 
functions and lazy evaluation which make life easier in the long term.  The 
downside of these features is that they might make life harder in the short 
term.

I don't know. In a sense Haskell is easier than, for example, C, because
the concept of a function definition is more natural that that of
assignments and loops. The idea that x = 5; x = x + 7 makes sense
requires a complete new way of thinking. OK, once you've been doing it
for a few years switching back to x = 5 + 7 is hard.


I would limit that to say that *denotational* semantic intuition is easy 
to wield in Haskell. Operational semantic intuition is Haskell is very 
non-obvious to the imperative (and many functional) programmers.


Making matters worse, the first is an advantage well-hyped by 
functionistas, the second hurdle is rarely admitted to.


That said, I definitely think that we should make learning the language as 
easy as possible.  But our ultimate goal should be to primarily show 
newcomers the Haskell way of problem solving, not how to emulate Python or 
Java programming in Haskell.

Again, is there a danger of that happening?


Yes. Those absent the necessary humility to approach haskell-cafe with 
open mind and flame-retardant dialog will fall back on what they know: 
transliterated Java/Python with a morass of do blocks and IO monads, 
then (rightly) bash how "ugly" Haskell syntax is when used in this way.


This type of programmer looking to use Haskell casually should sign a 
"benefit of the doubt" contract whereby they assume that any runtime 
suboptimalities derive from their own coding and not from Haskell's 
defects. This is the innate assumption of the curious, the 
self-motivated, the clever. This is not typically the starting 
assumption of the "I'm an expert at Joe-imperative language" hacker who 
took 10 years to perfect his Java skills and expects thereby to jump to 
at least year 5 of Haskell without effort.


I do strongly believe in stimulating the curiosity of all comers, just 
not in giving the false impression that a quick read-through of a few 
tutorials will let you write lightning-fast code, or know when to 
abandon [Char] for something more clever, or where to insert those bangs 
and fold left instead of right, and how ad hoc and parametric 
polymorphism differ, and what Rank-n and existential means (and why you 
can just pickle any object in Python but need to know a half dozen 
abstract things including who Peano was to do the same in Haskell), and 
what the heck an infinite type is, and on and on.


Haskell has definitely been teaching me some serious humility! Possibly 
it is best that those not ready for that lesson might better stick with 
Python.


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

[Haskell-cafe] Re: grammars and generics

[Chung-chieh Shan]

Greg Meredith <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in 
gmane.comp.lang.haskell.cafe:
> Here is an idea so obvious that someone else must have already thought of it
> and worked it all out. Consider the following grammar.

Hello!

If I understand your basic idea correctly, it is to split a recursive
data type into two parts, a non-recursive type constructor and a
knot-tying recursive type.  This idea has been christened "two-level
types" by

Tim Sheard and Emir Pasalic. 2004.  Two-level types and
parameterized modules.  Journal of Functional Programming
14(5):547-587.

The idea dates earlier, to initial-algebra semantics and "functional
programming with bananas and lenses":

Mark P. Jones. 1995.  Functional programming with overloading and
higher-order polymorphism.  In Advanced functional programming:
1st international spring school on advanced functional programming
techniques, ed. Johan Jeuring and Erik Meijer, 97-136.  Lecture
Notes in Computer Science 925.
http://web.cecs.pdx.edu/~mpj/pubs/springschool.html

Erik Meijer, Maarten Fokkinga, and Ross Paterson. 1991.  Functional
programming with bananas, lenses, envelopes and barbed wire.  In
Functional programming languages and computer architecture: 5th
conference, ed. John Hughes, 124-144.  Lecture Notes in Computer
Science 523.
http://research.microsoft.com/~emeijer/Papers/fpca91.pdf

Cheers,
Ken

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
Nevertheless, most cosmologists, including Dr. Guth and Dr. Linde,
agree that the universe ultimately must come from somewhere, and that
nothing is the leading candidate.
Dennis Overbye, New York Times, May 22, 2001.

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

Re: [Haskell-cafe] IO is a bad example for Monads

[Lennart Augustsson]

And more power to those who are pursuing the vision!
But in the mean time I need to read and write files, start up external
programs, call Excel through FFI, etc, etc.
And there's no clever API for that yet, only IO.  And I'd rather do IO in
Haskell than in C++.

I share the vision, though.  I'm just not pursuing it at the moment.

  -- Lennart


On Dec 11, 2007 6:02 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:

>
> > This is at odds with the notion, popular on this list and other haskell
> forums, that pure functional programming is the future.
>
> Perhaps a nit-pick, but I don't think we're talking about *pure*
> functional programming.  I think we're talking about a mixture of functional
> and imperative programming in a functional language.  Haskell offers a
> cleaner separation between the two than, say, Scheme or ML.  The idea of
> pure functional programming (no explicit IO) for getting real things done is
> much more of a lunatic fringe vision, and I'm not sure there are many of us
> left pursuing that vision.
>
>   - Conal
>
>
>
> On Dec 11, 2007 9:34 AM, Tim Newsham <[EMAIL PROTECTED]> wrote:
>
> > I haven't been following this thread closely, but would it be rude to
> > suggest
> > > that someone who doesn't want to put the effort into learning the
> > (admittedly
> > > difficult) concepts that Haskell embodies shouldn't be using the
> > language?
> > > Haskell was never intended to be The Next Big Popular Language.  It
> > was
> > > intended to be a purely functional language for people who want to use
> > purely
> > > functional languages and who are willing to learn new concepts if it
> > enables
> > > them to program in that  style.
> >
> > This is at odds with the notion, popular on this list and other
> > haskell forums, that pure functional programming is the future.
> >
> > Why is it that every time the topic of teaching basic concepts in
> > an easier way comes up there are always two or three replies that
> > say "should we bother?  lets filter out the idiots?"  These are
> > pointless and counterproductive.  Whether or not you like the idea
> > of lesser entities sullying your private, pure, functional programming
> > language, there are going to be a lot more people learning this
> > language, and there will be people trying to make it easier for them
> > to learn it.
> >
> > > whatever.  That said, of course we should strive to have better
> > teaching
> > > materials, but there are a number of good IO/monad tutorials on the
> > web.
> > [...]
> > > because it enables us to write programs more effectively (in many
> > cases, at
> > > least) than we can in other languages, but the learning curve is steep
> > --
> > > there ain't no such thing as a free lunch.
> >
> > Many of the best resources for learning Haskell are still academic
> > papers published by language researchers.   We've still got a long
> > long way to go...  Sure there's no shortcut to learning difficult
> > concepts, but right now its more of a nature hike than a freeway...
> >
> > > Mike
> >
> > 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 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] class default method proposal

[David Menendez]

On Dec 11, 2007 1:29 PM, apfelmus <[EMAIL PROTECTED]> wrote:

> Without the automatic search, this is already possible
>
> class Functor f where
> fmap :: (a -> b) -> f a -> f b
>
> class Functor m => Monad m where
> return :: a -> m a
> (>>=)  :: m a -> (a -> m b) -> m b
>
>-- aka liftM
> fmapDefault :: Monad m => (a -> b) -> m a -> m b
> fmapDefault f m = m >>= (return . f)
>
> instance Monad [] where
> return x = [x]
> (>>=)= flip concatMap
>
> instance Functor [] where
> fmap = fmapDefault
>
>  fmap  is already written for you, the instance declaration is only
> boilerplate. I first saw this in  Data.Traversable .
>

This is pretty much how I define Functor and Applicative instances for my
monads. It is admittedly irritating to have to write out the boilerplate,
but  it doesn't seem irritating enough to require a language extension to
eliminate.

-- 
Dave Menendez <[EMAIL PROTECTED]>

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

Re: [Haskell-cafe] grammars and generics

[Greg Meredith]

Dusan,

Excellent point. To close it off, you need to add an "empty" alternative.
Thus, the corrected form would be

N0 ::= TEmpty | T0 N1 | T1 N1 N0 | T2 N0 N0
N1 ::= T3 N0

In the lambda calculus, this would show up as a constant term, say 0, that
would have to be treated in the operational semantics. See my ltu
postingof a year ago.

Best wishes,

--greg

On Dec 11, 2007 11:33 AM, Dušan Kolář <[EMAIL PROTECTED]> wrote:

> Hello,
>
>  I can't help you with the Haskell question as I'm not really in that
> much. Nevertheless, your grammar is non-generating one - that means, it
> cannot generate any sentence. If the starting non-terminal is N0 then
> there is no production generating a string of terminals, thus, both
> non-terminals (even if reachable from the staring one) are so called
> non-generating ones (they can be freely removed from the grammar and all
> involved productions too).
> Thus, you get empty grammar. Isn't that the problem? Shouldn't the
> grammar be like:
>
> N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0
> N1 ::= T3 T4
>
> ?
>
> Best regards
>
> Dusan
>
>
> Greg Meredith wrote:
> > Haskellians,
> >
> > Here is an idea so obvious that someone else must have already thought
> > of it and worked it all out. Consider the following grammar.
> >
> > N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0
> > N1 ::= T3 N0
> >
> > where Ti (0 <= i < 4) are understood to be terminals.
> >
> > Using generics we can translate each production independently of the
> > others. Like so:
> >
> > [| N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0  |]
> > =
> > data N0 n1 = T0 n1 | T1 n1 (N0 n1) | T2 (N0 n1) (N0 n1) deriving (Eq,
> > Show)
> >
> > [| N1 ::= T3 N0 |]
> > =
> > data N1 n0 = T3 n0 deriving (Eq, Show)
> >
> > Then, we can compose the types to get the recursive grammar.
> >
> > data G = N0 (N1 G) deriving (Eq, Show)
> >
> > This approach has the apparent advantage of treating each production
> > independently and yet being compositional.
> >
> > Now, let me de-obfuscate the grammar above. The first production
> > should be very familiar.
> >
> > Term ::= Var Name | Abstraction Name Term | Application Term Term
> >
> > The generics-based translation of this grammar yields something we
> > already know: we can use lots of different types to work as
> > identifiers. This is something that the nominal of Gabbay, Pitts, et
> > al, have factored out nicely.
> >
> > The second production can be treated independently, but composes well
> > with the first.
> >
> > Name ::= Quote Term
> >
> > This illustrates that a particularly interesting class of names is one
> > that requires we look no further than our original (parametric) data
> > type.
> >
> > So, my question is this. Does anyone have a reference for this
> > approach to translation of grammars?
> >
> > Best wishes,
> >
> > --greg
> >
> >
> > --
> > L.G. Meredith
> > Managing Partner
> > Biosimilarity LLC
> > 505 N 72nd St
> > Seattle, WA 98103
> >
> > +1 206.650.3740
> >
> > http://biosimilarity.blogspot.com
> > 
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> --
>
>  Dusan Kolartel: +420 54 114 1238
>  UIFS FIT VUT Brno  fax: +420 54 114 1270
>  Bozetechova 2   e-mail: [EMAIL PROTECTED]
>  Brno 612 66
>  Czech Republic
>
> --
>
>


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103

+1 206.650.3740

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

Re: [Haskell-cafe] c2hs and cabal

[Duncan Coutts]

On Tue, 2007-12-11 at 19:14 +0100, Stefan Kersten wrote:
> > On 02.12.2007, at 22:34, Eric Sessoms wrote:
> >> Just add
> >>
> >> Build-Tools: c2hs
> >>
> >> And cabal will take it from there.
> 
> thanks eric, that's really pleasingly simple

> (it appears that the Build-Tools: line isn't even needed).

Though note that in future Cabal is going to get stricter about stating
dependencies on build tools, just like it is very strict about
dependencies on libraries.

Duncan

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

Re: [Haskell-cafe] library to read/write audio files

[Jed Brown]

On 11 Dec 2007, [EMAIL PROTECTED] wrote:
> Also, sound data is currently read into a list.  I will probably
> change this at some point in the future, most likely copying the lazy
> bytestring implementation and using a list of CFloat arrays.

Perhaps you are looking for storablevector which is a direct
generalization of bytestring from Word8 to any Storable.  It is not in
hackage yet, but seems stable.  There isn't a `lazy' version, but that
could be changed.

http://code.haskell.org/~sjanssen/storablevector

Jed


pgpRFEMo5caLT.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] FFI: "foreign label" declaration

[Ricardo Herrmann]

Malcolm Wallace wrote:
> 
> Ricardo Herrmann <[EMAIL PROTECTED]> wrote:
> 
>> a .chs file which uses a "foreign label" syntax, which seems
>> deprecated, since the parser can't even recognize it:
>> 
>> foreign label "bdd_reorder_stable_window3"
>>   bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ())
>> 
>> Is there new syntax for this ? Or is it a deprecated functionality ?
> 
> I believe it is now "foreign import" with an ampersand in front of the
> name of the foreign entity, e.g.
> 
>   foreign import "& bdd_reorder_stable_window3"
> bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ())
> 
> 

Changing "foreign label" to "foreign import ccall" (with the ampersand) did
the trick, thanks.

PS: At least it compiled, but I still didn't check if it works ;-)

-- 
View this message in context: 
http://www.nabble.com/FFI%3A-%22foreign-label%22-declaration-tp14279625p14281281.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

[Haskell-cafe] grammars and generics

[Greg Meredith]

Haskellians,

Here is an idea so obvious that someone else must have already thought of it
and worked it all out. Consider the following grammar.

N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0
N1 ::= T3 N0

where Ti (0 <= i < 4) are understood to be terminals.

Using generics we can translate each production independently of the others.
Like so:

[| N0 ::= T0 N1 | T1 N1 N0 | T2 N0 N0  |]
=
data N0 n1 = T0 n1 | T1 n1 (N0 n1) | T2 (N0 n1) (N0 n1) deriving (Eq, Show)

[| N1 ::= T3 N0 |]
=
data N1 n0 = T3 n0 deriving (Eq, Show)

Then, we can compose the types to get the recursive grammar.

data G = N0 (N1 G) deriving (Eq, Show)

This approach has the apparent advantage of treating each production
independently and yet being compositional.

Now, let me de-obfuscate the grammar above. The first production should be
very familiar.

Term ::= Var Name | Abstraction Name Term | Application Term Term

The generics-based translation of this grammar yields something we already
know: we can use lots of different types to work as identifiers. This is
something that the nominal of Gabbay, Pitts, et al, have factored out
nicely.

The second production can be treated independently, but composes well with
the first.

Name ::= Quote Term

This illustrates that a particularly interesting class of names is one that
requires we look no further than our original (parametric) data type.

So, my question is this. Does anyone have a reference for this approach to
translation of grammars?

Best wishes,

--greg


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103

+1 206.650.3740

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

Re: [Haskell-cafe] IO is a bad example for Monads

[Hans van Thiel]

On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote:
> Am Dienstag, 11. Dezember 2007 14:46 schrieb Hans van Thiel:
> > On Mon, 2007-12-10 at 20:00 +0100, Henning Thielemann wrote:
> > [snip]
> >
> > > I raise my question once again: Must Haskell's tutorials be tailored to
> > > impatient programmers? Does Haskell need quick&dirty hackers?
> >
> > IMO yes, because it exposes the language to the outside world and that's
> > a form of testing. In the end, anything that's not usable is useless.
> > Paraphrasing a quote about science in general, "There is nothing about
> > Haskell that cannot be grasped by a second rate mind through
> > persistence." Let's not exaggerate how difficult and special it all is.
> > And the purpose of a tutorial is not to make the writer look smart and
> > important, but to ease things for the reader. I wouldn't want to exclude
> > the scurrilous unwashed from the Haskell experience, this close to
> > Christmas, too. :-)
> >
> > Regards,
> >
> > Hans van Thiel
> 
> Maybe there are also patient people in the outside world so that we can still 
> expose Haskell to the outside world while not trying to attract 
> quick-and-dirty hackers. ;-) 
But who are those people? And what harm can they possibly do, assuming
they fit the derogatory description?
> 
> Haskell is not a quick-and-dirty language but quite the opposite.  Haskell’s 
> unique selling propositions are features like type classes, higher order 
> functions and lazy evaluation which make life easier in the long term.  The 
> downside of these features is that they might make life harder in the short 
> term.
I don't know. In a sense Haskell is easier than, for example, C, because
the concept of a function definition is more natural that that of
assignments and loops. The idea that x = 5; x = x + 7 makes sense
requires a complete new way of thinking. OK, once you've been doing it
for a few years switching back to x = 5 + 7 is hard.
I guess I do agree with you on lazy evaluation..

> That said, I definitely think that we should make learning the language as 
> easy as possible.  But our ultimate goal should be to primarily show 
> newcomers the Haskell way of problem solving, not how to emulate Python or 
> Java programming in Haskell.
Again, is there a danger of that happening?

Regards,

Hans
> 
> Best wishes,
> Wolfgang
> 

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

Re: [Haskell-cafe] FFI: "foreign label" declaration

[Malcolm Wallace]

Ricardo Herrmann <[EMAIL PROTECTED]> wrote:

> a .chs file which uses a "foreign label" syntax, which seems
> deprecated, since the parser can't even recognize it:
> 
> foreign label "bdd_reorder_stable_window3"
>   bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ())
> 
> Is there new syntax for this ? Or is it a deprecated functionality ?

I believe it is now "foreign import" with an ampersand in front of the
name of the foreign entity, e.g.

  foreign import "& bdd_reorder_stable_window3"
bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ())

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

Re: [Haskell-cafe] class default method proposal

[David Roundy]

What about something like

instance Monad MyMonad where
(>>=) = ...
return = ...
  deriving ( Functor, Applicative )

That sounds like a friendlier version of SPJ's proposal, in that you no
longer have to search for the default method, and every instance is
actually manually declared.  (I'm not sure if this is what Sterling meant
by a stand-alone deriving syntax... it's not really stand-alone, and that's
what I like about this idea, it restores locality.)

David

On Tue, Dec 11, 2007 at 12:59:06PM -0500, Sterling Clover wrote:
> Another suggestion, maybe completely off the wall, would be to do  
> something with stand-alone deriving syntax? So instead of "instance  
> Functor T" one might write "deriving Functor for T" ? This might make  
> it more clear that default methods were being brought into play. With  
> this syntax, it would seem appropriate to me that any case of overlap  
> would produce an error (modulo, perhaps, some funny new ghc flag such  
> as -fallow-overlapping-derivations).
> 
> --s.
> 
> instance Monad T
> On Dec 11, 2007, at 12:30 PM, Simon Peyton-Jones wrote:
> 
> >| If it really would work ok we should get it fully specified and
> >| implemented so we can fix the most obvious class hierarchy  
> >problems in a
> >| nice backwards compatible way. Things are only supposed to be  
> >candidates
> >| for Haskell' if they're already implemented.
> >
> >Getting it fully specified is the first thing.
> >
> >Personally I am not keen about
> >
> >a) coupling it to explicit import/export (independently-desirable  
> >though such a change might be)
> >
> >b) having instance declarations silently spring into existence
> >
> >
> >Concerning (b) here's a suggestion.  As now, require that every  
> >instance requires an instance declaration.  So, in the main example  
> >of http://haskell.org/haskellwiki/Class_system_extension_proposal,  
> >for a new data type T you'd write
> >instance Monad T where
> >  return = ...
> >  (>>=)  = ...
> >
> >instance Functor T
> >instance Applicative T
> >
> >The instance declaration for (Functor T) works just as usual (no  
> >explicit method, so use the default method) except for one thing:  
> >how the default method is found.  The change is this:
> >Given "instance C T where ...", for any method 'm' not
> >defined by "...":
> >for every class D of which C is a superclass
> >where there is an instance for (D T)
> >see if the instance gives a binding for 'm'
> >If this search finds exactly one binding, use it,
> >otherwise behave as now
> >
> >This formulation reduces the problem to a more manageable one: a  
> >search for the default method.
> >
> >I'm not sure what is supposed to happen if the instance is for  
> >something more complicated (T a, say, or multi-parameter type  
> >class) but I bet you could work it out.
> >
> >All these instances would need to be in the same module:
> >   - you can't define Functor T without Monad T, because you
> >want to pick up the monad-specific default method
> >   - you can't define Monad T without Functor T, because
> >the latter is a superclass of the former
> >
> >It still sounds a bit complicated.
> >
> >Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] library to read/write audio files

[Stefan Kersten]

hi john,

On 11.12.2007, at 18:14, John Lato wrote:

I've been working on a library to encode/decode audio files (wave,
aiff, etc.) to and from lazy bytestrings, and it's finally in a form
where I'm willing to share.  It's available at
http://mml.music.utexas.edu/jwlato/HSoundFile/, lightly cabalized and
haddock-ified.  The basic item is a Data.SoundFile datatype and a
SndFileCls class.  Each file format (wave, etc.) has a datatype with
instances of SndFileCls and Data.Binary (thanks to Don S. for
suggesting Data.Binary).  At least that's the idea, I've only
implemented the Wave format so far, but I wanted to make it easy to
add new formats.


sounds good!


I originally intended to use Erik de Castro Lopo's excellent
libsndfile (and there are some remnants of that in darcs), but after
realizing I wanted a more functional interface I decided to roll my
own.  It's likely possible to wrap libsndfile in a functional
interface, but that is beyond my current abilities.


incidentally, i've been working on libsndfile bindings the last few  
days; here's the darcs repository:


http://darcs.k-hornz.de/cgi-bin/darcsweb.cgi?r=hsndfile;a=summary

it's not quite finished yet, but if you're interested you could have  
a look at the interface and make suggestions. maybe both projects  
could benefit from each other? i personally don't see much advantages  
in _not_ using libsndfile underneath ...




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

Re: [Haskell-cafe] c2hs and cabal

[Stefan Kersten]

On 02.12.2007, at 22:34, Eric Sessoms wrote:

Just add

Build-Tools: c2hs

And cabal will take it from there.


thanks eric, that's really pleasingly simple (it appears that the  
Build-Tools: line isn't even needed).




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

Re: [Haskell-cafe] IO is a bad example for Monads

[Conal Elliott]

> I'm not sure there are many of us left pursuing that vision.

P.S. I'd love to learn otherwise.

On Dec 11, 2007 10:02 AM, Conal Elliott <[EMAIL PROTECTED]> wrote:

>
> > This is at odds with the notion, popular on this list and other haskell
> forums, that pure functional programming is the future.
>
> Perhaps a nit-pick, but I don't think we're talking about *pure*
> functional programming.  I think we're talking about a mixture of functional
> and imperative programming in a functional language.  Haskell offers a
> cleaner separation between the two than, say, Scheme or ML.  The idea of
> pure functional programming (no explicit IO) for getting real things done is
> much more of a lunatic fringe vision, and I'm not sure there are many of us
> left pursuing that vision.
>
>   - Conal
>
>
>
> On Dec 11, 2007 9:34 AM, Tim Newsham <[EMAIL PROTECTED]> wrote:
>
> > I haven't been following this thread closely, but would it be rude to
> > suggest
> > > that someone who doesn't want to put the effort into learning the
> > (admittedly
> > > difficult) concepts that Haskell embodies shouldn't be using the
> > language?
> > > Haskell was never intended to be The Next Big Popular Language.  It
> > was
> > > intended to be a purely functional language for people who want to use
> > purely
> > > functional languages and who are willing to learn new concepts if it
> > enables
> > > them to program in that  style.
> >
> > This is at odds with the notion, popular on this list and other
> > haskell forums, that pure functional programming is the future.
> >
> > Why is it that every time the topic of teaching basic concepts in
> > an easier way comes up there are always two or three replies that
> > say "should we bother?  lets filter out the idiots?"  These are
> > pointless and counterproductive.  Whether or not you like the idea
> > of lesser entities sullying your private, pure, functional programming
> > language, there are going to be a lot more people learning this
> > language, and there will be people trying to make it easier for them
> > to learn it.
> >
> > > whatever.  That said, of course we should strive to have better
> > teaching
> > > materials, but there are a number of good IO/monad tutorials on the
> > web.
> > [...]
> > > because it enables us to write programs more effectively (in many
> > cases, at
> > > least) than we can in other languages, but the learning curve is steep
> > --
> > > there ain't no such thing as a free lunch.
> >
> > Many of the best resources for learning Haskell are still academic
> > papers published by language researchers.   We've still got a long
> > long way to go...  Sure there's no shortcut to learning difficult
> > concepts, but right now its more of a nature hike than a freeway...
> >
> > > Mike
> >
> > 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] IO is a bad example for Monads

[Conal Elliott]

> This is at odds with the notion, popular on this list and other haskell
forums, that pure functional programming is the future.

Perhaps a nit-pick, but I don't think we're talking about *pure* functional
programming.  I think we're talking about a mixture of functional and
imperative programming in a functional language.  Haskell offers a cleaner
separation between the two than, say, Scheme or ML.  The idea of pure
functional programming (no explicit IO) for getting real things done is much
more of a lunatic fringe vision, and I'm not sure there are many of us left
pursuing that vision.

  - Conal


On Dec 11, 2007 9:34 AM, Tim Newsham <[EMAIL PROTECTED]> wrote:

> I haven't been following this thread closely, but would it be rude to
> suggest
> > that someone who doesn't want to put the effort into learning the
> (admittedly
> > difficult) concepts that Haskell embodies shouldn't be using the
> language?
> > Haskell was never intended to be The Next Big Popular Language.  It was
> > intended to be a purely functional language for people who want to use
> purely
> > functional languages and who are willing to learn new concepts if it
> enables
> > them to program in that  style.
>
> This is at odds with the notion, popular on this list and other
> haskell forums, that pure functional programming is the future.
>
> Why is it that every time the topic of teaching basic concepts in
> an easier way comes up there are always two or three replies that
> say "should we bother?  lets filter out the idiots?"  These are
> pointless and counterproductive.  Whether or not you like the idea
> of lesser entities sullying your private, pure, functional programming
> language, there are going to be a lot more people learning this
> language, and there will be people trying to make it easier for them
> to learn it.
>
> > whatever.  That said, of course we should strive to have better teaching
> > materials, but there are a number of good IO/monad tutorials on the web.
> [...]
> > because it enables us to write programs more effectively (in many cases,
> at
> > least) than we can in other languages, but the learning curve is steep
> --
> > there ain't no such thing as a free lunch.
>
> Many of the best resources for learning Haskell are still academic
> papers published by language researchers.   We've still got a long
> long way to go...  Sure there's no shortcut to learning difficult
> concepts, but right now its more of a nature hike than a freeway...
>
> > Mike
>
> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] FFI: "foreign label" declaration

[Ricardo Herrmann]

Hi everyone,

I'm trying to get HBDD compiled under GHC 6.8.1 and now I'm stuck with a
.chs file which uses a "foreign label" syntax, which seems deprecated, since
the parser can't even recognize it:

foreign label "bdd_reorder_stable_window3"
  bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ())

Is there new syntax for this ? Or is it a deprecated functionality ?

Thanks in advance,

--
Ricardo Guimarães Herrmann
"In a concurrent world, imperative is the wrong default!" -- Tim Sweeney
(Epic Games)
-- 
View this message in context: 
http://www.nabble.com/FFI%3A-%22foreign-label%22-declaration-tp14279625p14279625.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re: [Haskell-cafe] class default method proposal

[Sterling Clover]

Another suggestion, maybe completely off the wall, would be to do  
something with stand-alone deriving syntax? So instead of "instance  
Functor T" one might write "deriving Functor for T" ? This might make  
it more clear that default methods were being brought into play. With  
this syntax, it would seem appropriate to me that any case of overlap  
would produce an error (modulo, perhaps, some funny new ghc flag such  
as -fallow-overlapping-derivations).


--s.

instance Monad T
On Dec 11, 2007, at 12:30 PM, Simon Peyton-Jones wrote:


| If it really would work ok we should get it fully specified and
| implemented so we can fix the most obvious class hierarchy  
problems in a
| nice backwards compatible way. Things are only supposed to be  
candidates

| for Haskell' if they're already implemented.

Getting it fully specified is the first thing.

Personally I am not keen about

a) coupling it to explicit import/export (independently-desirable  
though such a change might be)


b) having instance declarations silently spring into existence


Concerning (b) here's a suggestion.  As now, require that every  
instance requires an instance declaration.  So, in the main example  
of http://haskell.org/haskellwiki/Class_system_extension_proposal,  
for a new data type T you'd write

instance Monad T where
  return = ...
  (>>=)  = ...

instance Functor T
instance Applicative T

The instance declaration for (Functor T) works just as usual (no  
explicit method, so use the default method) except for one thing:  
how the default method is found.  The change is this:

Given "instance C T where ...", for any method 'm' not
defined by "...":
for every class D of which C is a superclass
where there is an instance for (D T)
see if the instance gives a binding for 'm'
If this search finds exactly one binding, use it,
otherwise behave as now

This formulation reduces the problem to a more manageable one: a  
search for the default method.


I'm not sure what is supposed to happen if the instance is for  
something more complicated (T a, say, or multi-parameter type  
class) but I bet you could work it out.


All these instances would need to be in the same module:
   - you can't define Functor T without Monad T, because you
want to pick up the monad-specific default method
   - you can't define Monad T without Functor T, because
the latter is a superclass of the former

It still sounds a bit complicated.

Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


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

[Haskell-cafe] Re: distinguish functions from non-functions in a class/instances

[apfelmus]

jerzy karczmarczuk wrote:

apfelmus:

As Feynman put it: "What do you care what other people think?"


It was not Feynman, but his wife.


Thanks, I should have questioned my claim :)


Regards,
apfelmus

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

[Haskell-cafe] Software Tools in Haskell

[Gwern Branwen]

On 2007.12.10 13:52:41 -0600, Tommy McGuire <[EMAIL PROTECTED]>
scribbled 1.7K characters:

> In the "if anyone is interested,..." department
>
> For reasons that remain unclear, early this fall I started translating
> Brian W. Kernighan and P.J. Plaugher's classic _Software Tools in Pascal_
> into Haskell.  I have completed most of it, up to the second part of
> chapter 8 which presents a proto-m4 preprocessor.  I have the code online
> including notes, comments, descriptions, and a few alternate approaches.
>
> Attractions include:
>
> * A fair gamut of the usual Unix suspects: proto-cat, proto-wc, proto-tr,
> proto-compress, proto-ar, proto-grep, etc.
>
> * A usable editor, if you consider a de-featured ed-alike to be usable.
>
> * A simple monadic regular expression engine.
>
> * Zippers, Parsec, the State monad, the StateT monad transformer, and other
> attempts to sully Computing Science's brightest jewels.
>
> * Lots and lots of really bad Haskell, including a fair bit that is a
> direct translation of 30-year old Pascal (see xindex in translit, Ch. 2, if
> you need to skip lunch).  Programming really has advanced, you know.
>
> Anyway, the URL is:
>   http://www.crsr.net/Programming_Languages/SoftwareTools
>
> Questions and comments would be appreciated, especially suggestions for how
> to make the code cleaner and more understandable.  Flames and mockery are
> welcome, too, but only if they're funny---remember, I've been staring at
> Haskell, Pascal (plus my job-related Perl, CORBA, and C++) for a while;
> there's no telling what my mental state is like.
>
> [I had intended to wait until I had the whole thing done to make this
> announcement, but I recently moved and have not made much forward progress
> since, other than putting what I had done online.]
>
> --
> Tommy M. McGuire

Some of those really look like they could be simpler, like 'copy' -
couldn't that simply be 'main = interact (id)'?

Have you seen ?

For example, 'charcount' could be a lot simpler - 'charcount = showln
. length' would work, wouldn't it, for the core logic, and the whole
thing might look like:

> main = do (print . showln . length) =<< getContents

Similarly wordcount could be a lot shorter, like 'wc_l = showln .
length . lines'

(showln is a convenience function: showln a = show a ++ "\n")

I... I want to provide a one-liner for 'detab', but it looks
impressively monstrous and I'm not sure I understand it.

One final comment: as regards run-length encoding, there's a really
neat way to do it. I wrote a little article on how to do it a while
ago, so I guess I'll just paste it in here. :)

---

Recently I was playing with and working on a clone of the old Gradius
arcade games which was written in Haskell, Monadius
.
Most of my changes were not particularly interesting (cleaning up,
Cabalizing, fixing warnings, switching all Integers to Ints and so
on), but in its Demo.hs, I found an interesting solution to an
interesting problem which seems to be a good example of how Haskell's
abstractions can really shine.

So, suppose we have these data items, which are levels which are
specified by a pair of numbers and then a long list of numbers, often
very repetitious. Perhaps a particular level might be represented this
way:

> level1 = ((Int,Int),[Int])
> level1 = 
> ((2,1),[0,0,0,0,0,0,0,0,0,0,0,0,8,8,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,73,73,73,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,69,69,69,69,69,69,65,17,17,17,17,17,17,17,17,17,17,17,17,17,25,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,9,1,1,1,1,1,1,1,1,1,1,9,9,9,1,1,1,1,1,1,1,1,1,1,1,1,1,65,65,65,65,65,65,1,1,1,1,1,1,1,1,33,33,1,1,1,1,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,49,49,49,49,33,33,33,1,1,1,1,1,1,1,9,9,9,1,1,1,1,1,1,1,1,1,33,33,33,33,1,1,1,1,1,1,1,1,1,9,9,1,1,1,1,1,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,33,1,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,81,81,81,81,81,81,81,81,81,81,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,17,1,1,1,1,1,1,1,17,17,17,17,17,17,17,17,17,17,17,1,1,1,1,1,1,1,1,1,1,1,1,17,17,17,1,1,1,1,1,1,1,1,1,1,1,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,65,97,33,33,33,33,37,5,69,69,65,65,65,65,65,65,67,67,67,67,67,67,67,67,67,75,75,75,75,75,75,75,75,75,75,75,75,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,11,3,3,3,3,3,3,3,3,3,3,3,3,3,11,11,3,3,3,3,3,3,3,3,3,3,11,3,

[Haskell-cafe] Re: class default method proposal

[apfelmus]

Jules Bean wrote:

David Menendez wrote:

Duncan Coutts wrote:
So my suggestion is that we let classes declare default 
implementations of methods from super-classes.


It creates ambiguity if two classes declare defaults for a common 
superclass.


My standard example involves Functor, Monad, and Comonad. Both Monad 
and Comonad could provide a default implementation for fmap. But let's 
say I have a type which is both a Monad and a Comonad: which default 
implementation gets used?


I'm disappointed to see this objection isn't listed on the wiki.


Doesn't sound like a very big problem. That would just be a compile time 
error ("More than one default for fmap possible for Foo, please reslve 
ambiguity").


And how would you resolve that ambiguity?

  module Control.Functor.UsefulStuff (hylo) where
hylo :: Functor f => (a -> f a) -> (f b -> b) -> a -> b
hylo f g = g . fmap (hylo f g) . f

  module BANG where
import Foo (Foo)
import Foo.Is.Monad
import Foo.Is.Comonad

import Control.Functor.UsefulStuff (hylo)

bar :: Bar -> Foo Bar
baz :: Foo Baz -> Baz

bang = hylo bar baz

The problem is that the ambiguity may arise by just importing different 
modules while not having access to the offending call to  fmap .


Also note that as much as I'd like explicit import/export of type class 
instances, the current implicit and global export is no accident, it's 
crucial for well-definedness. See also the second half of


  http://article.gmane.org/gmane.comp.lang.haskell.general/15471


In other words, the main problem of all those superclass/explicit 
import/export proposals is that there are no proofs of the fact that 
they only allow well-defined programs. The homework isn't done yet, 
discussing adoption is too early.



Regards,
apfelmus

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

Re: [Haskell-cafe] IO is a bad example for Monads

[Tim Newsham]

I haven't been following this thread closely, but would it be rude to suggest 
that someone who doesn't want to put the effort into learning the (admittedly 
difficult) concepts that Haskell embodies shouldn't be using the language? 
Haskell was never intended to be The Next Big Popular Language.  It was 
intended to be a purely functional language for people who want to use purely 
functional languages and who are willing to learn new concepts if it enables 
them to program in that  style.


This is at odds with the notion, popular on this list and other
haskell forums, that pure functional programming is the future.

Why is it that every time the topic of teaching basic concepts in
an easier way comes up there are always two or three replies that
say "should we bother?  lets filter out the idiots?"  These are
pointless and counterproductive.  Whether or not you like the idea
of lesser entities sullying your private, pure, functional programming
language, there are going to be a lot more people learning this
language, and there will be people trying to make it easier for them
to learn it.

whatever.  That said, of course we should strive to have better teaching 
materials, but there are a number of good IO/monad tutorials on the web.

[...]
because it enables us to write programs more effectively (in many cases, at 
least) than we can in other languages, but the learning curve is steep -- 
there ain't no such thing as a free lunch.


Many of the best resources for learning Haskell are still academic
papers published by language researchers.   We've still got a long
long way to go...  Sure there's no shortcut to learning difficult
concepts, but right now its more of a nature hike than a freeway...


Mike


Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] class default method proposal

[Simon Peyton-Jones]

| If it really would work ok we should get it fully specified and
| implemented so we can fix the most obvious class hierarchy problems in a
| nice backwards compatible way. Things are only supposed to be candidates
| for Haskell' if they're already implemented.

Getting it fully specified is the first thing.

Personally I am not keen about

a) coupling it to explicit import/export (independently-desirable though such a 
change might be)

b) having instance declarations silently spring into existence


Concerning (b) here's a suggestion.  As now, require that every instance 
requires an instance declaration.  So, in the main example of 
http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data 
type T you'd write
instance Monad T where
  return = ...
  (>>=)  = ...

instance Functor T
instance Applicative T

The instance declaration for (Functor T) works just as usual (no explicit 
method, so use the default method) except for one thing: how the default method 
is found.  The change is this:
Given "instance C T where ...", for any method 'm' not
defined by "...":
for every class D of which C is a superclass
where there is an instance for (D T)
see if the instance gives a binding for 'm'
If this search finds exactly one binding, use it,
otherwise behave as now

This formulation reduces the problem to a more manageable one: a search for the 
default method.

I'm not sure what is supposed to happen if the instance is for something more 
complicated (T a, say, or multi-parameter type class) but I bet you could work 
it out.

All these instances would need to be in the same module:
   - you can't define Functor T without Monad T, because you
want to pick up the monad-specific default method
   - you can't define Monad T without Functor T, because
the latter is a superclass of the former

It still sounds a bit complicated.

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

[Haskell-cafe] library to read/write audio files

[John Lato]

Hello,

I've been working on a library to encode/decode audio files (wave,
aiff, etc.) to and from lazy bytestrings, and it's finally in a form
where I'm willing to share.  It's available at
http://mml.music.utexas.edu/jwlato/HSoundFile/, lightly cabalized and
haddock-ified.  The basic item is a Data.SoundFile datatype and a
SndFileCls class.  Each file format (wave, etc.) has a datatype with
instances of SndFileCls and Data.Binary (thanks to Don S. for
suggesting Data.Binary).  At least that's the idea, I've only
implemented the Wave format so far, but I wanted to make it easy to
add new formats.

I originally intended to use Erik de Castro Lopo's excellent
libsndfile (and there are some remnants of that in darcs), but after
realizing I wanted a more functional interface I decided to roll my
own.  It's likely possible to wrap libsndfile in a functional
interface, but that is beyond my current abilities.

This library is far from complete.  Firstly, only the wave format is
implemented (and incompletely).  There are also only minimal HUnit
tests; I plan to add QuickCheck tests when I have some more time.
Secondly there are performance issues.  For relatively short clips
it's fine, but there seems to be a space leak.  Attempting to copy
large files while just decoding and encoding the data will quickly
exhaust available memory.  Other than the space leak; performance is
good.  Profiling indicates that reading is extremely fast, and the
slowest operations during write are the multiple calls to
Data.Binary.Put.putWord16le (for 16-bit files).  Also, sound data is
currently read into a list.  I will probably change this at some point
in the future, most likely copying the lazy bytestring implementation
and using a list of CFloat arrays.

If anyone would care to offer suggestions (or patches), they would be
greatly appreciated.  This is my first real project in Haskell, so
please be kind.  I've successfully build it on ubuntu linux with GHC
6.6.1 and 6.8.1, and I don't see any reason it won't work on other
platforms.

Thank you,
John Lato

PS  I'd appreciate knowing if this project is reinventing the wheel.
I didn't see anything similar in hoogle or google, but you never know.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] class default method proposal

[Duncan Coutts]

On Tue, 2007-12-11 at 16:38 +, Ross Paterson wrote:
> On Tue, Dec 11, 2007 at 04:26:52PM +, Simon Marlow wrote:
> > Duncan Coutts wrote:
> >> On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote:
> >>> This is almost exactly the
> >>> http://haskell.org/haskellwiki/Class_system_extension_proposal; that
> >>> page has some discussion of implementation issues.
> >>
> >> Oh yes, so it is. Did this proposal get discussed on any mailing list?
> >> I'd like to see what people thought. Was there any conclusion about
> >> feasibility?
> >
> > Ross proposed this on the libraries list in 2005:
> >
> > http://www.haskell.org//pipermail/libraries/2005-March/003494.html
> 
> and again in 2003:
> 
> http://www.haskell.org/pipermail/haskell-cafe/2003-July/004654.html


Ross, you need to shout louder! :-)

If it really would work ok we should get it fully specified and
implemented so we can fix the most obvious class hierarchy problems in a
nice backwards compatible way. Things are only supposed to be candidates
for Haskell' if they're already implemented.

So how about the objection that two sub classes could try and define
conflicting defaults for a superclass method? David Menendez had the
example of Monad and CoMonad defining Functor's fmap. Can that easily be
rejected? I suppose it gives rise to duplicate instance declarations so
it'd be an error in the same way that defining clashing instances in two
different modules and importing both into a third module.

Another error case would be:

module A where
data Foo

module B where
instance Functor Foo

module C where
instance Monad Foo

module D
import Bar
import Baz

Now we get slashing instances for Functor, since both Bar and Baz export
Functor instances for Foo. Since the instance for Functor Foo was not
visible in module C, so we get the default instance defined in C.

So the one slightly surprising thing about this suggestion is that we
get an instance defined or not depending on whether there is already an
instance in scope. In the Functor, Applicative, Monad case I don't see
that causing a problem in practise but is it worse more generally?

Duncan

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

[Haskell-cafe] Re: Waiting for thread to finish

[Simon Marlow]

ChrisK wrote:


That is new. Ah, I see GHC.Conc.forkIO now has a note:

GHC note: the new thread inherits the /blocked/ state of the parent 
(see 'Control.Exception.block').


BUT...doesn't this change some of the semantics of old code that used forkIO ?


Yes, it is a change to the semantics.  I assumed (naively) that virtually 
nobody would be using forkIO inside block, and so the change would be 
benign.  It is (another) departure from the semantics in the Asynchronous 
Exceptions paper.  Still, I think this is the right thing.



I wanted a way to control the blocked status of new threads, since this makes it
 easier to be _sure_ some race conditions will never happen.

And so my new preferred way of writing this is now:


-- we are in parent's blocked state, so make the ticker explicit:
  res <- bracket (forkIO (unblock ticker))
 killThread
 const act  -- act runs in parent's blocked state





In this case the unblock isn't strictly necessary, because the ticker 
thread spends most of its time in threadDelay, which is interruptible anyway.


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

Re: [Haskell-cafe] class default method proposal

[Ross Paterson]

On Tue, Dec 11, 2007 at 04:26:52PM +, Simon Marlow wrote:
> Duncan Coutts wrote:
>> On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote:
>>> This is almost exactly the
>>> http://haskell.org/haskellwiki/Class_system_extension_proposal; that
>>> page has some discussion of implementation issues.
>>
>> Oh yes, so it is. Did this proposal get discussed on any mailing list?
>> I'd like to see what people thought. Was there any conclusion about
>> feasibility?
>
> Ross proposed this on the libraries list in 2005:
>
> http://www.haskell.org//pipermail/libraries/2005-March/003494.html

and again in 2003:

http://www.haskell.org/pipermail/haskell-cafe/2003-July/004654.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] class default method proposal

[Simon Marlow]

Duncan Coutts wrote:

On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote:


This is almost exactly the
http://haskell.org/haskellwiki/Class_system_extension_proposal; that
page has some discussion of implementation issues.


Oh yes, so it is. Did this proposal get discussed on any mailing list?
I'd like to see what people thought. Was there any conclusion about
feasibility?


Ross proposed this on the libraries list in 2005:

http://www.haskell.org//pipermail/libraries/2005-March/003494.html

and I brought it up for Haskell':

http://www.haskell.org//pipermail/haskell-prime/2006-April/001344.html

see also this:

http://www.haskell.org//pipermail/haskell-prime/2006-August/001582.html

Unfortunately the Haskell' wiki doesn't have a good summary of the issues; 
it should.  I'll add these links at least.


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

Re: [Haskell-cafe] IO is a bad example for Monads

[Wolfgang Jeltsch]

Am Dienstag, 11. Dezember 2007 14:46 schrieb Hans van Thiel:
> On Mon, 2007-12-10 at 20:00 +0100, Henning Thielemann wrote:
> [snip]
>
> > I raise my question once again: Must Haskell's tutorials be tailored to
> > impatient programmers? Does Haskell need quick&dirty hackers?
>
> IMO yes, because it exposes the language to the outside world and that's
> a form of testing. In the end, anything that's not usable is useless.
> Paraphrasing a quote about science in general, "There is nothing about
> Haskell that cannot be grasped by a second rate mind through
> persistence." Let's not exaggerate how difficult and special it all is.
> And the purpose of a tutorial is not to make the writer look smart and
> important, but to ease things for the reader. I wouldn't want to exclude
> the scurrilous unwashed from the Haskell experience, this close to
> Christmas, too. :-)
>
> Regards,
>
> Hans van Thiel

Maybe there are also patient people in the outside world so that we can still 
expose Haskell to the outside world while not trying to attract 
quick-and-dirty hackers. ;-) 

Haskell is not a quick-and-dirty language but quite the opposite.  Haskell’s 
unique selling propositions are features like type classes, higher order 
functions and lazy evaluation which make life easier in the long term.  The 
downside of these features is that they might make life harder in the short 
term.

That said, I definitely think that we should make learning the language as 
easy as possible.  But our ultimate goal should be to primarily show 
newcomers the Haskell way of problem solving, not how to emulate Python or 
Java programming in Haskell.

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

Re: [Haskell-cafe] Need help please.

[Thomas Hartman]

I second that emotion.

That is the perfect paper to read if you've never done a parser and need 
one. There is also source code corresponding to the paper if you google 
around.

t.



Paul Johnson <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
12/11/2007 03:02 AM

To
Ryan Bloor <[EMAIL PROTECTED]>
cc
haskell-cafe@haskell.org
Subject
Re: [Haskell-cafe] Need help please.






Ryan Bloor wrote:
> hi
> 
> I am writing a basic Parser from scratch. So far I have functions;
>
I think you need to read http://www.cs.nott.ac.uk/~gmh/pearl.pdf

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



---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] class default method proposal

[Duncan Coutts]

On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote:

> This is almost exactly the
> http://haskell.org/haskellwiki/Class_system_extension_proposal; that
> page has some discussion of implementation issues.

Oh yes, so it is. Did this proposal get discussed on any mailing list?
I'd like to see what people thought. Was there any conclusion about
feasibility?

Duncan

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

Re: [Haskell-cafe] class default method proposal

[Jules Bean]

David Menendez wrote:
On Dec 11, 2007 9:20 AM, Duncan Coutts <[EMAIL PROTECTED] 
> wrote:


So my suggestion is that we let classes declare default implementations
of methods from super-classes.

It creates ambiguity if two classes declare defaults for a common 
superclass.


My standard example involves Functor, Monad, and Comonad. Both Monad and 
Comonad could provide a default implementation for fmap. But let's say I 
have a type which is both a Monad and a Comonad: which default 
implementation gets used?


I'm disappointed to see this objection isn't listed on the wiki.


Doesn't sound like a very big problem. That would just be a compile time 
error ("More than one default for fmap possible for Foo, please reslve 
ambiguity").


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

Re: [Haskell-cafe] class default method proposal

[David Menendez]

On Dec 11, 2007 9:20 AM, Duncan Coutts <[EMAIL PROTECTED]> wrote:

> So my suggestion is that we let classes declare default implementations
> of methods from super-classes.

 Does this proposal have any unintended consequences? I'm not sure.
> Please discuss :-)


It creates ambiguity if two classes declare defaults for a common
superclass.

My standard example involves Functor, Monad, and Comonad. Both Monad and
Comonad could provide a default implementation for fmap. But let's say I
have a type which is both a Monad and a Comonad: which default
implementation gets used?

I'm disappointed to see this objection isn't listed on the wiki.

-- 
Dave Menendez <[EMAIL PROTECTED]>

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

Re: [Haskell-cafe] class default method proposal

[Stefan O'Rear]

On Tue, Dec 11, 2007 at 02:20:52PM +, Duncan Coutts wrote:
> I'd just like to float an idea that's related to the Class Alias
> proposal[1] but is perhaps somewhat simpler.
> 
> We all know that Functor should have been a superclass of Monad, and
> indeed we now know that Applicative should be too. Making such a change
> would break lots of things however so the change does not happen.
> 
> However in this case the Monad operations can be used to implement the
> Functor and Applicative class methods. So it would be nice if we could
> get them for free if the author did not choose to write the Functor and
> Applicative instances.
> 
> So my suggestion is that we let classes declare default implementations
> of methods from super-classes.
> 
> class Functor m => Monad m where
>   {- the ordinary bits -}
> 
>   fmap f m= m >>= return . f
> 
> So if there already is a Functor instance for m then the default
> implementation of fmap is not used.
> 
> 
> Does this proposal have any unintended consequences? I'm not sure.
> Please discuss :-)
> 
> Duncan
> 
> [1] http://repetae.net/recent/out/classalias.html

This is almost exactly the
http://haskell.org/haskellwiki/Class_system_extension_proposal; that
page has some discussion of implementation issues.

Stefan


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

[Haskell-cafe] class default method proposal

[Duncan Coutts]

I'd just like to float an idea that's related to the Class Alias
proposal[1] but is perhaps somewhat simpler.

We all know that Functor should have been a superclass of Monad, and
indeed we now know that Applicative should be too. Making such a change
would break lots of things however so the change does not happen.

However in this case the Monad operations can be used to implement the
Functor and Applicative class methods. So it would be nice if we could
get them for free if the author did not choose to write the Functor and
Applicative instances.

So my suggestion is that we let classes declare default implementations
of methods from super-classes.

class Functor m => Monad m where
  {- the ordinary bits -}

  fmap f m= m >>= return . f

So if there already is a Functor instance for m then the default
implementation of fmap is not used.


Does this proposal have any unintended consequences? I'm not sure.
Please discuss :-)

Duncan

[1] http://repetae.net/recent/out/classalias.html

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

[Haskell-cafe] Re: distinguish functions from non-functions in a class/instances

[jerzy . karczmarczuk]

apfelmus: 


As Feynman put it: "What do you care what other people think?"


It was not Feynman, but his wife. 

Jerzy Karczmarczuk 


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

Re: [Haskell-cafe] Re: IO is a bad example for Monads

[Henning Thielemann]

On Tue, 11 Dec 2007, ChrisK wrote:

> I look at it this way:  Every person who adds Haskell, however shallowly, to
> their repertoire acts as an example that may spur others to learn Haskell,
> perhaps deeply.   And that is a win not because of language chauvinism, but
> because of concept chauvinism.  I hope that a future "Next Big Popular 
> Language"
> has most of the concepts that make Haskell interesting.

I'm sure this will happen, I even suspect, this already happened, but a
language can become popular only if enough legacy of several languages and
the problematic parts of Haskell 98 are included. :-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Quickcheck generator for arrays of integers

[Paulo J. Matos]

Hello all,

I using an IArray to represent a matrix. I'm trying to write some
properties checks with Quickcheck.
Quickcheck lacks instance generators for arrays of ints for example,
is there anything I can use out there or should I define it myself?
(I'm asking because it seems to be something that other people already did)


Cheers,

-- 
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] IO is a bad example for Monads

[Hans van Thiel]

On Mon, 2007-12-10 at 20:00 +0100, Henning Thielemann wrote:
[snip]
> 
> I raise my question once again: Must Haskell's tutorials be tailored to
> impatient programmers? Does Haskell need quick&dirty hackers?
IMO yes, because it exposes the language to the outside world and that's
a form of testing. In the end, anything that's not usable is useless.
Paraphrasing a quote about science in general, "There is nothing about
Haskell that cannot be grasped by a second rate mind through
persistence." Let's not exaggerate how difficult and special it all is.
And the purpose of a tutorial is not to make the writer look smart and
important, but to ease things for the reader. I wouldn't want to exclude
the scurrilous unwashed from the Haskell experience, this close to
Christmas, too. :-)

Regards,

Hans van Thiel
> 

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

Re: [Haskell-cafe] Literate HTML

[Valery V. Vorotyntsev]

On 12/11/07, Neil Mitchell <[EMAIL PROTECTED]> wrote:
> I couldn't get it working either, so have raised a feature request bug.

Which has been merged into #1232:
  http://hackage.haskell.org/trac/ghc/ticket/1967#comment:1

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

[Haskell-cafe] ANNOUNCE: A ReadP style parser for ByteStrings

[Gracjan Polak]

I'm happy to announce a ReadP style parser for ByteStrings,
Text.ParserCombinators.ReadP.ByteString.

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestringreadp

Text.ParserCombinators.ReadP.ByteString is an adaptation of
Text.ParserCombinators.ReadP to work over Data.ByteString as input
stream representation. This gives enormous improvements in terms of
parsing speed but most significantly in memory usage.

Features:

 * ReadP style parser over ByteString input
 * Drop-in replacement for Text.ParserCombinators.ReadP
 * Fast
 * Good memory usage

The algorithm is slightly modified to exploit ByteString as random access
data input structure. Unlike original ReadP, that stressed garbage collection 
very much by creating a lot of conses (:), this parser has very good memory
allocation behaviour.

Package works out of the box with GHC 6.8.1, with slight (cabal) modifications
also with GHC 6.6.1.

Thanks to everyone for their support! Happy hacking!

--
Gracjan


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

[Haskell-cafe] Re: distinguish functions from non-functions in a class/instances

[apfelmus]

Dan Weston wrote:

Questioning apfelmus definitely gives me pause, but...


Don't hesitate! :) Personally, I question everyone and everything, 
including myself. This is a marvelous protection against unintentionally 
believing things just because I've heard them several times like "Monads 
are hard" or "Haskell code is easier to understand", but has many more 
uses. As Feynman put it: "What do you care what other people think?"



id :: a -> a-- "arity" 1
  id = ($) :: (a -> b) -> (a -> b)  -- "arity" 2


I agree with the arities given above (but without quotes) and see no 
ill-definedness to arity.


But these are two different classes of functions. There are arguments of 
the first function that cannot be applied to the second (e.g. 5).


The fact that the two have different type signatures shows that Haskell can 
distinguish them (e.g. in the instantiation of a type class).


No, I think not. Having different type signatures is not enough for 
being distinguishable by type classes. The second type


  ∀a,b. (a -> b) -> a -> b

is an instance of the first one

  ∀a. a -> a

"Instance" not in the sense of class instance but in the sense of type 
instance, i.e. that we can obtain the former by substituting type 
variables in the latter, here a := (a -> b). Formally, we can write this 
as an "inequality"


  ∀a. (a -> a) < (a -> b) -> a -> b

with "x < y" meaning "x less specific than y" or "x more general than y".

Now, the property I meant with

I don't like this behavior of  wrap  since it violates the
nice property of polymorphic expressions that it's unimportant
when a type variable is instantiated
is that the class instance predicate is monotonic with respect to the 
type instance relation: from  x < y  and  Num x , we can always conclude 
 Num y . In particular, let's examine a type class


  class Nat a => Arity a f | f -> a

describing that the function type  f  has a certain arity  a  which is 
expressed with Peano numbers in the type system:


  data Zero   = Zero
  data Succ a = Succ a

  type One = Succ Zero
  type Two = Succ One

  class Nat n

  instance Nat Zero
  instance Nat n => Nat (Succ n)

Now, if

  Arity One (∀a . a -> a)

is true then due to monotonicity,

  Arity One ((a -> b) -> a -> b)

must be true, too! The only possible solution to this dilemma is to drop 
the class instance for (∀a. a -> a). It's no problem to have many 
special instances


  Arity One (Int  -> Int)
  Arity One (Char -> Char)
  etc.

but we can't have the polymorphic one. In other words, not every 
(potentially polymorphic) function type has a well-defined arity! Oleg's 
hack basically supplies all those possible particular instances while 
avoiding the polymorphic one.



Concerning the ill-definedness of

  wrap id


  > :type wrap id
  wrap id :: (FunWrap (a -> a) y) => [String] -> y

but trying to use it like in

  > let x = wrap id ["1"] :: Int

yields lots of type errors. We have to specialize the type of  id 
before supplying it to  wrap . For example,


  wrap (id :: Int -> Int)

works just fine.


which I don't like, it seems that I have to life with it. That's because 
the toy implementation


class FunWrap f x | f -> x where
   wrap :: f -> [String] -> x

instance FunWrap (Int -> Int) Int where
   wrap f [x] = f (read x)

instance FunWrap ((Int -> Int) -> Int -> Int) Int where
   wrap f [g,x] = f id (read x)

already shows the same behavior. When trying something like

  > wrap id ["1"] :: Int

, GHCi complains that there's no polymorphic instance

  FunWrap (a -> a) Int

There can't be, since that would disallow the special instances and 
moreover conflict with the functional dependency. So,


  wrap id

is an example of an essentially ill-typed expression that the type 
checker does not reject early (namely when asking for its type).



Regards,
apfelmus

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

Re: [Haskell-cafe] Re: regex package for yhc?

[Neil Mitchell]

Hi

> I cannot quickly find on http://www.haskell.org/haskellwiki/Yhc what YHC 
> supports.

>From the (just modified) FAQ:
http://www.haskell.org/haskellwiki/Yhc/FAQ#Language_Support

Q) What extensions does it support?

A) Very few. Existentials and pattern guards are supported. Rank-2
types, multiparameter type classes and most other extensions are not.

Thanks

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

Re: [Haskell-cafe] Literate HTML

[Neil Mitchell]

Hi All,

Thanks for the general help on literate HTML. It seems that using
bird-tick style literate works better than \begin{code} style. I tried
it with my document, but quickly gave up - mainly because I decided
literateness did not fit with what I was doing.

> You can compile a .html file with:
>ghc --make -x lhs index.html

You can also load it in GHCi with:
> ghci -x lhs index.html

> The -x flag doesn't seem to work for runhaskell

I couldn't get it working either, so have raised a feature request bug.

Thanks for everyone's help,

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

[Haskell-cafe] Re: IO is a bad example for Monads

[ChrisK]

Michael Vanier wrote:
> I haven't been following this thread closely, but would it be rude to
> suggest that someone who doesn't want to put the effort into learning
> the (admittedly difficult) concepts that Haskell embodies shouldn't be
> using the language? 

Sorry Michael, but I will take your post as a point for me to jump into this big
thread.  And let me say here at the top, that I don't like pigeonholing or
classifying or labeling people by a programming tool/language/style.

I think it would be rude to suggest that.  You are interested Haskell, and you
want to tell other people to be less interested in Haskell.  There is no person
who has "decide who _should_ learn Haskell" as their job description.

Specifically, if a new person does not know the concepts Haskell, then they also
cannot know whether they will eventually want to learn those concepts and how to
employ them.   And no one else should pretend that they can predict that either.
Imagine pile of fanciful "what if?" examples, if that helps.

> Haskell was never intended to be The Next Big
> Popular Language.  It was intended to be a purely functional language
> for people who want to use purely functional languages and who are
> willing to learn new concepts if it enables them to program in that
> style.

Authors do not control how people interpret their books. Haskell is free
software, and people may do _anything_ with it.  If they use Haskell as it is,
then they are using a purely functional language.  If they change the compiler,
then they are using it as a basis for experimentation.  Both are interesting,
because they interest the person doing them.

> That now includes IO and monads, so if people aren't willing to
> learn that, they should go on using python or whatever. 

If they are willing to learn to use Haskell and are willing to work around IO,
then I might be interested in what other solution they have come up with.  The
use of an IO monad in Haskell was not the original solution, and there are
various proposals to move beyond the IO monad.

> That said, of
> course we should strive to have better teaching materials, but there are
> a number of good IO/monad tutorials on the web.

I sometimes feel I am one of the handful of people who have not tried to write a
tutorial for IO/monad/warm-fuzzy-thing.

> I used to love programming in python, but then I learned Scheme, then
> Ocaml, and then Haskell and at each stage I absorbed a few new
> concepts.  Now programming in python feels very primitive to me. Haskell
> is interesting because it enables us to write programs more effectively
> (in many cases, at least) than we can in other languages, but the
> learning curve is steep -- there ain't no such thing as a free lunch.
> 
> Mike

I look at it this way:  Every person who adds Haskell, however shallowly, to
their repertoire acts as an example that may spur others to learn Haskell,
perhaps deeply.   And that is a win not because of language chauvinism, but
because of concept chauvinism.  I hope that a future "Next Big Popular Language"
has most of the concepts that make Haskell interesting.

-- 
Chris

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

Re: [Haskell-cafe] Need help please.

[Paul Johnson]

Ryan Bloor wrote:

hi
 
I am writing a basic Parser from scratch. So far I have functions;



I think you need to read http://www.cs.nott.ac.uk/~gmh/pearl.pdf

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