[Haskell-cafe] Fwd: [BostonHaskell] Next meeting: December 17th at MIT (32-G882)

[Ravi Nanavati]

-- Forwarded message --
From: Ravi Nanavati 
Date: Sat, Dec 12, 2009 at 1:44 AM
Subject: Next meeting: December 17th at MIT (32-G882)
To: bostonhask...@googlegroups.com


I'm pleased to announce the December meeting of the Boston Area
Haskell Users' Group.

The meeting has been scheduled for Thursday, December 17th from 7pm to
9pm. Like recent meetings, it will be held in the MIT CSAIL Reading
Room (32-G882, i.e. a room on the 8th floor of the Gates Tower of the
MIT's Stata Center at 32 Vassar St in Cambridge, MA).

Based on the responses to my previous message, our featured presenter
will be Ryan Newton who will talk about the Intel Concurrent
Collections for Haskell. Following his presentation, we will have our
traditional break. After the break, we're going to try a joint
programming exercise involving the collections. If anyone has a
suggestion for an interesting programming exercise that would take
advantage of the collections, please speak up (since otherwise Ryan
and I will see what we can come up with next week).

The December attendance poll is at: http://doodle.com/p2zcnca6k39iptb4

As always, responding to this poll will help with two things:
1. Getting an idea of what fraction of the Boston-area Haskell
community can and can't attend this meeting (to help with future
scheduling).
2. Giving me an estimated count of attendees, since I have talked my
wife into baking some more goodies and bringing drinks again.

Helping with BostonHaskell (besides volunteering to speak at future meetings):
1. Sponsorship of refreshments is still being eagerly solicited
(especially as, for personal reasons, the Cupcake Fund is running
low).
2. Please let me know if you're willing to arrive early (6:30pm) to
stand by the door and let people into the 8th floor. I'm guessing 1 or
2 volunteers is enough here.
3. If someone is willing to edit the HaskellWiki page, post to reddit
or otherwise publicize the meeting please just go ahead and do that
(especially as I'm sending this out on the later side).

If you have any questions about the meeting please send them to them
BostonHaskell mailing list: bostonhask...@googlegroups.com or contact
me directly.

I look forward to seeing many Boston-area Haskellers at the December meeting!

Thank you,

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

Re: [Haskell-cafe] Why?

[Janis Voigtländer]

Andrew Coppin wrote:
> On the other hand, turn up the optimisation settings on a C compiler
> high enough and the program breaks. Somewhere the compiler elides a
> second call to a function which actually happens to have some
> side-effect that the compiler isn't aware of, and your stream is now one
> byte out of alignment, or whatever. Fiddling with optimisation settings
> in GHC may make your program slow to a crawl rather than go faster, but
> it *never* makes it segfault on startup.

Note, though, that "slow to crawl" may go as far as "not terminate". 
GHC's optimizer can make a terminating program nonterminating. For some 
discussion, see:


http://www.haskell.org/haskellwiki/Correctness_of_short_cut_fusion#Discussion

In fact, one can also make up examples where turning on optimization 
lets GHC transform a "good" program into one halting with an arbitrary 
error (division by zero, say).


The recipe for (artificial) such examples can be found in footnote 2 of:

http://www.iai.uni-bonn.de/~jv/TUD-FI09-06.pdf

The error "in the wild" that is mentioned on the wiki page occurred in 
the context of the stream fusion library development.


Best regards,
Janis.

--
Jun.-Prof. Dr. Janis Voigtländer
http://www.iai.uni-bonn.de/~jv/
mailto:j...@iai.uni-bonn.de
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] consulting and contracting

[Tim Newsham]

I was wondering how many haskell consultants and contractors
(ie. freelance programmers) there are and how much demand there
is for their work.  Also what kind of work do most haskell
consultants and contractors get?  Is it primarily focused
around developing and maintaining haskell compilers and tools?
Mostly related to academia?  Spread out around several areas?

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

Re: [Haskell-cafe] "--" comments

[michael rice]

I'd seen Haddock occasionally mentioned in posts but hadn't gotten to it yet. 
Looks interesting.

Thanks,

Michael 

--- On Fri, 12/11/09, Brandon S. Allbery KF8NH  wrote:

From: Brandon S. Allbery KF8NH 
Subject: Re: [Haskell-cafe] "--" comments
To: "michael rice" 
Cc: "Brandon S. Allbery KF8NH" , haskell-cafe@haskell.org
Date: Friday, December 11, 2009, 11:34 PM

On Dec 11, 2009, at 23:30 , michael rice wrote:I'm just noticing that "--" 
comments don't seem to work properly when the first character following them is 
a '*'.

I believe the spec only treats "-- " as a comment leader; this is why Haddock 
markup has a space between the "--" and the markup.
 -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] 
allb...@kf8nh.comsystem administrator [openafs,heimdal,too many hats] 
allb...@ece.cmu.eduelectrical and computer engineering, carnegie mellon 
university    KF8NH
 



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

Re: [Haskell-cafe] "--" comments

[michael rice]

Cool! Didn't know that, and the Haskell syntax I looked up made no mention of 
it.

Thanks,

Michael

--- On Fri, 12/11/09, Daniel Peebles  wrote:

From: Daniel Peebles 
Subject: Re: [Haskell-cafe] "--" comments
To: "michael rice" 
Cc: haskell-cafe@haskell.org
Date: Friday, December 11, 2009, 11:33 PM

let (--*) = (+) in 5 --* 6===> 11

The comment is introduced by -- followed by a non-symbol (because if followed 
by a symbol, it might be an operator)

Hope this helps!

Dan


On Fri, Dec 11, 2009 at 11:30 PM, michael rice  wrote:

I'm just noticing that "--" comments don't seem to work properly when the first 
character following them is a '*'.


Michael


--*I like asterisks
--*I like asterisks
--*I like asterisks
--*I like asterisks

double x = x+x


Prelude> :l double

[1 of 1] Compiling Main ( double.hs, interpreted )

double.hs:1:0: parse error on input `--*'
Failed, modules loaded: none.
Prelude> 




  
___

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] "--" comments

[Brandon S. Allbery KF8NH]

On Dec 11, 2009, at 23:30 , michael rice wrote:
I'm just noticing that "--" comments don't seem to work properly  
when the first character following them is a '*'.



I believe the spec only treats "-- " as a comment leader; this is why  
Haddock markup has a space between the "--" and the markup.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] "--" comments

[Daniel Peebles]

let (--*) = (+) in 5 --* 6
===> 11

The comment is introduced by -- followed by a non-symbol (because if
followed by a symbol, it might be an operator)

Hope this helps!

Dan

On Fri, Dec 11, 2009 at 11:30 PM, michael rice  wrote:

> I'm just noticing that "--" comments don't seem to work properly when the
> first character following them is a '*'.
>
> Michael
>
>
> --*I like asterisks
> --*I like asterisks
> --*I like asterisks
> --*I like asterisks
>
> double x = x+x
>
>
> Prelude> :l double
> [1 of 1] Compiling Main ( double.hs, interpreted )
>
> double.hs:1:0: parse error on input `--*'
> Failed, modules loaded: none.
> Prelude>
>
>
>
> ___
> 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] "--" comments

[michael rice]

I'm just noticing that "--" comments don't seem to work properly when the first 
character following them is a '*'.

Michael


--*I like asterisks
--*I like asterisks
--*I like asterisks
--*I like asterisks

double x = x+x


Prelude> :l double
[1 of 1] Compiling Main ( double.hs, interpreted )

double.hs:1:0: parse error on input `--*'
Failed, modules loaded: none.
Prelude> 




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

Re: [Haskell-cafe] (semi OT) Fwd: Old math reveals new thinking in children's cognitive development

[Tom Tobin]

On Fri, Dec 11, 2009 at 9:21 PM, Brandon S. Allbery KF8NH
 wrote:
> Unexpected applications of category theory for $500, Alex

Before you know it, they're going to be modeling mental processes as monads.  :p
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: ANN: hakyll-0.1

[Tom Tobin]

On Tue, Dec 8, 2009 at 6:31 PM, Tom Tobin  wrote:
> Question 2 can be "If the answer to 1 is no, is there *any*
> circumstance under which the author of Y can distribute the source of
> Y under a non-GPL license?"

I'd like to get these questions out to the SFLC so we can satisfy our
curiosity; at the moment, here's what I'd be asking:

Background: X is a library distributed under the terms of the GPL. Y
is another library which calls external functions in the API of X, and
requires X to compile.  X and Y have different authors.

1) Can the author of Y legally distribute the *source* of Y under a
non-GPL license, such as the 3-clause BSD license or the MIT license?

2) If the answer to 1 is "no", is there *any* circumstance under which
the author of Y can distribute the source of Y under a non-GPL
license?

3) If the answer to 1 is "yes", what specifically would trigger the
redistribution of a work in this scenario under the GPL?  Is it the
distribution of X+Y *together* (whether in source or binary form)?

4) If the answer to 1 is "yes", does this mean that a "BSD-licensed"
library does not necessarily mean that closed-source software can be
distributed which is based upon such a library (if it so happens that
the library in turn depends on a copylefted library)?

By the way, apologies to the author of Hakyll — I'm sure this isn't
what you had in mind when you announced your library!  I'm just hoping
that we can figure out what our obligations are based upon the GPL,
since I'm not so sure myself anymore.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Using Atom's task scheduler for existing C code.

[Tom Hawkins]

Today we were working on integrating Atom code with some hand-written
C, and one of my colleagues posed the question: Is it possible to use
Atom just for its task scheduler for existing C code?  This turns out
to be very simple.  It just requires a few combinators built on top of
'action'.

-- Call a C function with type 'void f(void)'.
call :: Name -> Atom ()
call n = action (\ _ -> n ++ "()") []

-- Call a C function in its own rule, atomically.
callAtomic :: Name -> Atom ()
callAtomic n = atom n $ call n

-- Call a C function atomically with a guard condition.
callGuardedAtomic :: E Bool -> Name -> Atom ()
callGuardedAtomic g n = atom n (cond g >> call n)


Then scheduling a collection of tasks becomes easy:

-- 20 millisecond tasks.
period 20 $ do
  callAtomic "task1"
  callAtomic "task2"

-- 5 millisecond tasks.
period 5 $ do
  callAtomic "task3"
  callAtomic "task4"

-- 1 millisecond tasks.
period 1 $ do
  callGuardedAtomic task5Ready "task5"
  callGuardedAtomic task6Ready "task6"


I'll added these 'call' combinators in the next release of Atom.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: PCLT-0.1 and PCLT-DB-0.1

[Andrey Sisoyev]

Hello, cafe!

It's an honor for me to announce my first two packages, I developed in
Haskell:
** http://hackage.haskell.org/package/PCLT
** http://hackage.haskell.org/package/PCLT-DB

"PCLT" is an abbreviation for "Parametric Composable Localizable Templates"
- in fact it should also hold Detalizable. Term "Detailizable content
(message)" in this package has a following meaning: some content,
representing which it is possible to regulate, in how much details it is
represented.
"Localizable" means "localizable in languages", which is "a message is
available in multiple languages".
"Composable" - it is possible to compose multiple templates into one.

Conceptually, this package is a powerful extension to the well known Show
class. Whenever you feel, that common Show is not enough for your needs,
please consider using my PCLT. The extension is thought to be embedded in
any Haskell program, which requires multilingual support, and/or where
messages should be detailizable.

PCLT-DB is an addon to PCLT, which enhances catalog with PostgreSQL powers.
ER diagram:
http://i1.fastpic.ru/big/2009/1212/f0/5b9845716e5a6984e9bc9d62a61928f0.png

Both packages are well documented, has "Hello World" examples, and are
selfexamples - the PCLT errors representations are available in two
languages: English and Russian. Used license: LGPL.

Regards,
Andrey Sisoyev
-- 
View this message in context: 
http://old.nabble.com/ANNOUNCE%3A-PCLT-0.1-and-PCLT-DB-0.1-tp26754004p26754004.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] (semi OT) Fwd: Old math reveals new thinking in children's cognitive development

[Brandon S. Allbery KF8NH]

Begin forwarded message:

Date: December 11, 2009 8:00:00 PM EST
Subject: Old math reveals new thinking in children's cognitive  
development

Source: ScienceDaily: Latest Science News

Five-year-olds can reason about the world from multiple perspectives  
simultaneously, according to a new theory by researchers in Japan  
and Australia. Using an established branch of mathematics called  
Category Theory, the researchers explain why specific reasoning  
skills develop in children at certain ages, particularly at age  
five. The new theory shows that these reasoning skills have similar  
profiles of development because they involve related sorts of  
processes.

Read more…



Unexpected applications of category theory for $500, Alex

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
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] Parallel foldl doesn't work correctly

[Philip Beadling]

Hi,

Can anyone put me right here.  I am trying to use a setup similar to
parMap to spark each valuation in a list in parallel, where the
resulting (evaluated) list is folded to produce a final single result.

Having done the obligatory google, I modified a few common examples to
give:

pfoldl f acc xs =  foldl' f acc (xs `using` parList rwhnf)


This compiles and if I monitor my CPUs it starts to use both cores, but
after approx 10 seconds, one core drops to low rate (I'm using a 2 core
machine).

The end result is that -N2 is actually a bit slower than -N1!

I'm guessing I haven't grasped the concept properly - although as map is
just 'foldl (+) 0' I'm at a loss to see why this approach wouldn't work
given it is pretty similar to parMap - could anyone point out what I'm
missing?

If it's any use the context of the code is below.

Many thanks!


Phil.


mc :: MonteCarloUserData -> [[Double]] -> Double
mc userData rndss = 
  existentialResult (pfoldl f existenAvg rndss) $ numOfSims userData
where f   = flip $ existentialCombine . payOff' .
expiryValue 
  payOff' = existentialPayOff userData
  expiryValue = foldl' (existentialEvolve userData) (stock
userData)
  existenAvg  = averager userData

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

[Haskell-cafe] Re: What about adding a wiki for each haskell project?

[Duncan Coutts]

On Sat, 2009-12-12 at 01:00 +0100, Marc Weber wrote:
> hackage is success because:
> a) many (most) people do use it (by uploading packages)
> b) it is a comprehensive list of availible packages if not the most
> comprehensive one
> 
> Duncan, can you write about your concerns briefly why some maintainers may 
> dislike
> this idea ?

I added a section to the wiki page you created.

> Hackage is missing one feature:

It's missing lots of features! :-)


Duncan

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

Re: [Haskell-cafe] What about adding a wiki for each haskell project?

[Gwern Branwen]

On Fri, Dec 11, 2009 at 7:00 PM, Marc Weber  wrote:
> hackage is success because:
> a) many (most) people do use it (by uploading packages)
> b) it is a comprehensive list of availible packages if not the most
>    comprehensive one
>
> Duncan, can you write about your concerns briefly why some maintainers may 
> dislike
> this idea ?
>
> Hackage is missing one feature:
> It is very static. I mean if you have a patch or a question or a comment
> you have to lookup the darcs repository, write the patch then contact
> the author and wait.. If the author replies everything is fine.
> If he doesn't you don't know what to do. And if he does your commitment
> still doesn't show up on hackage.
>
> Using a wiki page for each project enables anybody to add comments.
> I'm thinking about this kind of comments:
>
>  "Interlude doesn't work for me. It looks like the interlude.h file
>  passes a tuple to the reportError function which doesn't expect a tuple.
>  You can fix it by removing the "," in the .h file.
>  Try this patch:
>  http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch
>  "
>
>  Of course I mailed the author. Looking at the package again I noticed
>  that it was uploaded by someone else: GwernBranwen.
>  gwern on #haskell told me that the author is responsive so I'll just
>  wait some days, but others will try and fail as well.
>  If the other person is new to haskell he may not find the fix
>  fast. He just wants to know which of the heads is causing trouble..
>
> Another use case would be users adding
> "If you're interested in this topic also have a look at XXX"
>
> Yet another use case is someone figuring out that function X was removed
> in version Y. He could than add a note
>
> x vanished since v.10 and everybody who wants to update cabal dependency
> constraints doesn't have to download the darcs repo to figure out that
> he should use package <= v.10 .
>
> Of course contents of wiki pages may be totally wrong because the
> contents were written by people knowing the package less than the
> maintainers and authors. But everyone knows this and will take care.
>
> This wiki can server as fail over if the maintainer is on holiday.
>
> This wiki page will prevent people blogging about packages and benchmark
> results anywhere on the internet. So it's much more likely that this
> information is read and maintained.
> If you use google to look for bug fixes or such you may have success.
> But very often you end up reading pages dated 3 years ago which are
> outdated.
>
> This wiki page would be I simple effective way letting users annotate
> packages.
>
> Costs: Make hackage add one link.
> It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg
> This link should point to the existing haskell wiki on haskell.org:
> http://haskell.org/haskellwiki/project-name-without-version

Would the link check for the article actually existing? Not much good
to point people to a wiki page that doesn't exist, unless they know
and intend to contribute something.
Also, even if the article existed, how many people will feel like
clicking on it to see what may be there?
I'd suggest the code would check for an existing page, be colored red
(or omitted?) if it doesn't, and if it does exist, then add a
hyperlinks - and also load the page in a small frame.

(I have some custom JavaScript on Wikipedia that loads in a frame talk
pages beneath/at the bottom of an article; I can attest from personal
experience that the quick glance-ability this adds is very valuable
and makes me much more likely to see what a talk page has to add,
takes up minimal screen real estate, and since it loads after
everything else does, has a minimal performance penalty.)

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

Re: [Haskell-cafe] Why?

[Jason Dusek]

2009/12/11 Luke Palmer :
> The idea being that any code that is pure could be evaluated
> anywhere with a very simple interpreter. If you have pure
> code, you can trace it back and evaluate it in a sandbox where
> you don't need a C runtime, a linker, or really anything but
> the simplest substitution engine. *All* effects bubble their
> way up to the top level, so that we know from the type
> signature of a value the machinery we will need to run it.

  This sounds good but there is something puzzling about it.
  Where do we draw the line between "machinery" and "packages"?
  The types don't tell us what libraries we need. They don't
  tell us how much RAM/CPU we need, either.

> Pure functional code as the minimal essence of pure
> computation -- everything else an EDSL.

  Partial or total code?

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

Re: [Haskell-cafe] Why?

[Dan Weston]

Luke Palmer wrote:

The idea being that any code that is pure could be evaluated anywhere
with a very simple interpreter.  If you have pure code, you can trace
it back and evaluate it in a sandbox where you don't need a C runtime,
a linker, or really anything but the simplest substitution engine.
*All* effects bubble their way up to the top level, so that we know
from the type signature of a value the machinery we will need to run


The alternative is not much better: syntactic sugar (say a "wrapping" 
keyword similar to "deriving") that wraps up a pure type in a State, ST, 
or IO. The inevitable result is that *every* type from the lazy 
programmer will be so wrapped. Many programmers overdo the IO monad as 
it is. With suitable sugar, they will become addicted!


Dan


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

Re: [Haskell-cafe] Why?

[Donn Cave]

Quoth Luke Palmer ,
...
> This is not the sort of resistance I expected :-).  Naturally my
> unrealistic argument applies to FFI as well; sin, if imported from C,
> would have to return in an appropriate structure.  Not necessarily IO
> (I don't like the idea of a universal sin-bin -- I'd rather introduce
> a family of structures with well-defined meanings), but the same idea.
> Support for commutative monads (once we understand them) may relieve
> some of the pain of this approach.

Yes!  I mean, I have no idea, but it seems like it's worth a look at
anything that promises to replace some of the unsafePerformIO hacking
with more functionally transparent ways to do the same thing.

I love talking about the questionable purity of sin!  but as it happens,
since I don't do that much geometry I am without sin anyway.

Donn

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

Re: [Haskell-cafe] Why?

[Luke Palmer]

On Fri, Dec 11, 2009 at 4:55 PM, Jason Dusek  wrote:
> 2009/12/10 Luke Palmer :
>> I always meet with armies of resistance when I say this...
>
>  The troops arrive.
>
>> ...but unsafePerformIO should die a horrible, unforgiven
>> death. "Well what if you want blah blah blah with a pure
>> interface?" My response: too fscking bad!
>
>  Wouldn't removing `unsafePerformIO` just force us, in many
>  cases, to write the same thing in C and then import it? Or
>  would you amend the FFI so "math.h sin" could not be imported
>  pure?

This is not the sort of resistance I expected :-).  Naturally my
unrealistic argument applies to FFI as well; sin, if imported from C,
would have to return in an appropriate structure.  Not necessarily IO
(I don't like the idea of a universal sin-bin -- I'd rather introduce
a family of structures with well-defined meanings), but the same idea.
Support for commutative monads (once we understand them) may relieve
some of the pain of this approach.

The idea being that any code that is pure could be evaluated anywhere
with a very simple interpreter.  If you have pure code, you can trace
it back and evaluate it in a sandbox where you don't need a C runtime,
a linker, or really anything but the simplest substitution engine.
*All* effects bubble their way up to the top level, so that we know
from the type signature of a value the machinery we will need to run
it.

Pure functional code as the minimal essence of pure computation --
everything else an EDSL.

Of course I am not talking about Haskell anymore.  Haskell is a firm,
maturing language and has no room for such radical changes.  This
argument applies to an eventual spiritual successor of Haskell (it is
probably too liberal for Haskell' even).

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

[Haskell-cafe] GHC 6.12 status and features

[Rafael Gustavo da Cunha Pereira Pinto]

Hi folks, and specially Simon Marlow,


I know I should probably be asking to the GHC list, but is there any update
on 6.12 since October? Any probable release date?

BTW, is there any feature list for the release?


Thank all of you involved in bringing this new version to life. GHC rocks!


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

Re: [Haskell-cafe] Why?

[Gregory Crosswhite]

On Dec 11, 2009, at 3:55 PM, Jason Dusek wrote:

>  There are plenty of bad ways to use `unsafePerformIO`, this is
>  true; but as we already have a tool for binding to native code
>  in a way that trusts it to be pure, I don't see how having a
>  way to bind to nominally side-effecting Haskell code in a way
>  that trusts it to be pure adds anything to our troubles.


Indeed, and I would add that we even trust that our Haskell implementation 
itself is pure, even though it does all sorts of side-effectful things 
underneath the hood.

Cheers,
Greg

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

[Haskell-cafe] What about adding a wiki for each haskell project?

[Marc Weber]

hackage is success because:
a) many (most) people do use it (by uploading packages)
b) it is a comprehensive list of availible packages if not the most
comprehensive one

Duncan, can you write about your concerns briefly why some maintainers may 
dislike
this idea ?

Hackage is missing one feature:
It is very static. I mean if you have a patch or a question or a comment
you have to lookup the darcs repository, write the patch then contact
the author and wait.. If the author replies everything is fine.
If he doesn't you don't know what to do. And if he does your commitment
still doesn't show up on hackage.

Using a wiki page for each project enables anybody to add comments.
I'm thinking about this kind of comments:

  "Interlude doesn't work for me. It looks like the interlude.h file
  passes a tuple to the reportError function which doesn't expect a tuple.
  You can fix it by removing the "," in the .h file.
  Try this patch:
  
http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch
  "

  Of course I mailed the author. Looking at the package again I noticed
  that it was uploaded by someone else: GwernBranwen.
  gwern on #haskell told me that the author is responsive so I'll just
  wait some days, but others will try and fail as well.
  If the other person is new to haskell he may not find the fix
  fast. He just wants to know which of the heads is causing trouble..

Another use case would be users adding
"If you're interested in this topic also have a look at XXX"

Yet another use case is someone figuring out that function X was removed
in version Y. He could than add a note

x vanished since v.10 and everybody who wants to update cabal dependency
constraints doesn't have to download the darcs repo to figure out that
he should use package <= v.10 .

Of course contents of wiki pages may be totally wrong because the
contents were written by people knowing the package less than the
maintainers and authors. But everyone knows this and will take care.

This wiki can server as fail over if the maintainer is on holiday.

This wiki page will prevent people blogging about packages and benchmark
results anywhere on the internet. So it's much more likely that this
information is read and maintained.
If you use google to look for bug fixes or such you may have success.
But very often you end up reading pages dated 3 years ago which are
outdated.

This wiki page would be I simple effective way letting users annotate
packages.

Costs: Make hackage add one link.
It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg
This link should point to the existing haskell wiki on haskell.org:
http://haskell.org/haskellwiki/project-name-without-version


Even if the maintainer is availible 24/h a day he won't upload a new
minor version to hackage for each change. But maybe he'll paste a small
note that the darcs repo is more up to date fixing issue x/y.
You don't want to upload a new version because you added some
documentation.
Why don't you want to do that ?
It's because hackage will keep every version which was uploaded once by
design. Having 50 versions of one package just causes much more work for
tools such as cabal install or hack-nix. Figuring out a solution to
install all packages is hard enough.

Maintainers can create the wiki page and subscribe to change
notifications. So I don't think it'll be that much work for them to keep
an eye on those wiki pages.

How do you think about it?
It's about centralizing information and saving your and my time.
Many packages aready do have a wiki page. So why not make it easier for
all to add one?

Thoughts ?

Currently my goal is updating some common packages so that they use
extensible exceptions and base4.
But when working on some patches I'd like to tell people that I'm doing
so. I can't in an easy way. That's why I'm starting this thread.

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

Re: [Haskell-cafe] Why?

[Jason Dusek]

2009/12/10 Luke Palmer :
> I always meet with armies of resistance when I say this...

  The troops arrive.

> ...but unsafePerformIO should die a horrible, unforgiven
> death. "Well what if you want blah blah blah with a pure
> interface?" My response: too fscking bad!

  Wouldn't removing `unsafePerformIO` just force us, in many
  cases, to write the same thing in C and then import it? Or
  would you amend the FFI so "math.h sin" could not be imported
  pure?

  There are plenty of bad ways to use `unsafePerformIO`, this is
  true; but as we already have a tool for binding to native code
  in a way that trusts it to be pure, I don't see how having a
  way to bind to nominally side-effecting Haskell code in a way
  that trusts it to be pure adds anything to our troubles.

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

Re: [Haskell-cafe] Why?

[Dan Piponi]

On Fri, Dec 11, 2009 at 11:46 AM, Andrew Coppin
 wrote:

> On the other hand, turn up the optimisation settings on a C compiler high
> enough and the program breaks.

Not if you write actual C as specified by the standard.

In fact, these days gcc internally converts your program to SSA form,
which is essentially pure functional code. (See here for an
explanation: http://www.cs.princeton.edu/~appel/papers/ssafun.ps) The
reason is exactly as you say: the purer the code, the easier it is to
reason about it.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why?

[Andrew Coppin]

Stephen Tetley wrote:

C'mon Andrew - how about some facts, references?
  


Facts I can do. References? Not so much...


1. Code optimisation becomes radically easier. The compiler can make very
drastic alterations to your program, and not chance its meaning. (For that
matter, the programmer can more easily chop the code around too...)



Which code optimizations?
  


In a pure language, substituting a function call with the corresponding 
RHS is guaranteed to not alter the program. Eliminating common 
subexpressions is guaranteed not to alter the meaning of the program. 
Something like stream fusion which replaces a data structure in memory 
with a loop in the program code is guaranteed not to alter the meaning 
of the program. Should I continue?


On the other hand, turn up the optimisation settings on a C compiler 
high enough and the program breaks. Somewhere the compiler elides a 
second call to a function which actually happens to have some 
side-effect that the compiler isn't aware of, and your stream is now one 
byte out of alignment, or whatever. Fiddling with optimisation settings 
in GHC may make your program slow to a crawl rather than go faster, but 
it *never* makes it segfault on startup.



>From a different point of view, whole program compilation gives plenty
of opportunity for re-ordering transformations / optimization - Stalin
(now Stalinvlad) and MLton often generated the fastest code for their
respective (strict, impure) languages Scheme and Standard ML.
  


I didn't say it's impossible to optimise impure languages. I said it's 
much harder.



2. Purity leads more or less directly to laziness, which has several
benefits:



Other way round, no?
  


A philosopher once asked: Do we gaze at the stars because we are human? 
Or are we human because we gaze at the stars? Pointless, really.


Is Haskell pure because it's lazy, and being impure in a lazy language 
would be a hellish nightmare? Or is it lazy because in a pure language, 
there's no reason to be strict?



2a. Unecessary work can potentially be avoided. (E.g., instead of a function
for getting the first solution to an equation and a seperate function to
generate *all* the solutions, you can just write the latter and laziness
gives you the former by magic.


Didn't someone quote Heinrich Apfelmus in this list in the last week or so:

http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html

"Well, it's highly unlikely that algorithms get faster by introducing
laziness. I mean, lazy evaluation means to evaluate only those things
that are really needed and any good algorithm will be formulated in a
way such that the unnecessary things have already been stripped off."
  


Writing an algorithm custom-optimised to every possible use-case is 
probably more efficient than using laziness. On the other hand, using 
laziness is probably radically less typing, and arguably not that much 
slower. (And then you can invoke the notion of the Sufficiently 
Sophisticated Compiler...)



2b. You can define brand new flow control constructs *inside* the language
itself. (E.g., in Java, a "for" loop is a built-in language construct. In
Haskell, "for" is a function in Control.Monad. Just a plain ordinary
function that anybody could write.)




Psst, heard about Scheme & call/cc?
  


No. Should I have?


2c. The algorithms for generating data, selecting data and processing data
can be seperated.



Granted. But some people have gone quite some way in the strict world, e.g.:

http://users.info.unicaen.fr/~karczma/arpap/FDPE05/f20-karczmarczuk.pdf


  

2d. Parallel computation. This turns out to be more tricky than you'd think,
but it's leaps and bounds easier than in most imperative languages.



Plenty of lazy and strict, pure and impure languages in this survey:
http://www.risc.uni-linz.ac.at/people/schreine/papers/pfpbib.ps.gz
  


All of these seem to be of the form "you can do this in an impure 
language". I didn't say you can't. I said it's easier.



3. It's much harder to accidentally screw things up by modifying a piece of
data from one part of the program which another part is still actually
using. (This is somewhat similar to how garbage collection makes it harder
to free data that's still in use.)



In a pure language I'd like to think its impossible...
  


Agreed. But - unless your program involves no I/O at all - you would be 
wrong... :-(


Haskell programs can and sometimes do involve mutable state internally 
as well. And in that case, it's up to you to not accidentally do 
something dumb.


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

Re: [Haskell-cafe] Why?

[Paul Johnson]

On 10/12/09 12:07, Magnus Therning wrote:


As I understand it it all started with laziness.  I don't know if
laziness is impossible without purity, but talks and papers tend to
say something like "laziness has kept Haskell pure".
This is true, but laziness has its own advantages.  Suppose I have two 
modules, Foo and Bar.  Foo generates a data structure which is then 
consumed by Bar (possibly with some other component calling both of 
them).  In a strict language I have to choose between one of these three 
options:


  1. Foo generates the structure all at once, and some kind of
 reference is then passed to Bar.  This is nice, simple and
 modular, but it only works for small structures.  There can also
 be a problem if the structure is slow to generate but is only
 consumed a bit at a time (e.g. by the user interface) because Bar
 can only start work once Foo has finished the whole thing.  You
 may also find the Foo is doing lots of unnecessary work building
 bits of the structure that Bar uses only rarely.
  2. Foo and Bar are built together in a single module with their
 functionality interleaved.  This means that Foo can build a bit of
 the structure, have Bar process it, and so on.  However it also
 destroys any modularity the system might have had.  If Bar is part
 of the user interface, for instance, it means that core
 functionality gets mixed up.
  3. Implement some kind of generator object.  This takes a lot of code
 and makes the logic of Foo and Bar harder to follow.  For instance
 the version of Foo from option 1 might have had a loop of the form
 "foreach i in xs".  Now "i" has to be turned into some kind of
 member variable with logic to move to the next instance.  Of
 course what you are really doing is creating an ad-hoc hand-coded
 version of lazy evaluation.

Different applications are going to require different choices.  Worse 
yet, the right answer can change.  For instance you may start with 
option 1, then discover that the program runs too slowly.  Or marketing 
decide that the maximum size of the data structure has to be increased.  
So at that point you have to rewrite a big chunk of code.  Or else you 
go with option 2 or 3 because the designer thought it was necessary for 
efficiency when in fact option 1 would have done nicely.


Of course with lazy evaluation you get option 3 all the time 
automatically.  So its just not a problem.  This makes the design much 
simpler because things that previously had to be decided by a human are 
now decided by the compiler.


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

Re: [Haskell-cafe] Re: Why?

[pbrowne]

Luke Palmer wrote:
> I admit that I don't fully know what you are talking about.  What do
> you mean by logical meaning -- as opposed to what other sort of
> meaning?


Consider Maude's rewrite logic RWL[1] which has similar inference rules
as equational logic(EL), but without the symmetry rule. From [1], the
*logical* meaning in RWL regards the rules of rewriting logic as
meta-rules for correct deduction in a logical system. Logically, each
rewriting step is a logical entailment in a formal system.
Note that the particular logic may vary (e.g. EL,FOPL, RWL).

[1]http://maude.cs.uiuc.edu/maude1/manual/maude-manual-html/maude-manual_62.html

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

Re: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009?

[Gregory Collins]

Johann Höchtl  writes:

> I might be wrong, but it's EPoll.hsc where you define the call to the Linux
> kernel function. This would be unneccessary, when poll (and kqueue and Windows
> equivalents) are already in the core. Ok, a bit more than EPoll.hsc would be
> unneccessary ;)

Not sure what you mean by "core"; see for instance the code for GHC's
current I/O manager:

http://darcs.haskell.org/libraries/base/GHC/Conc.lhs

There's no special magic going on there, select() and friends are bound
using the normal FFI mechanism.


> What I mean is that applications like web servers should benefit immediately
> from a change in the exisiting core and not require a (new) library. So a
> change is likely neccessary in Network.Socket and
> Network.Socket.Internal
> and in the IO monad when it comes to
> files. 
> 
> If someone want's to benefit from more functionality, like overlapping IO on
> Windows, the extension may be platform dependent
> available. 
> 
> However, in order to produce portable code which uses non blocking IO "the new
> way", a programer should never have to think about the target
> platform. 
> 

Yes, of course. The idea would (or might) be to fold the event library
into GHC directly and rewrite the I/O manager in terms of it. Many (if
not all) of the library I/O functions may have to be adapted to work
with a new I/O manager. By writing it as a library first we can

  a) write programs that use I/O multiplexing before support gets into
 GHC core proper

  b) ensure that the mechanisms are well tested and benchmarked before
 they are integrated into GHC

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

Re: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009?

[Johann Höchtl]

Gregory Collins wrote:

Johann Höchtl  writes:

  

I think the overall goal should be to get rid of
http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hsc,
as it's in the core.



I don't follow, could you explain?


  
I might be wrong, but it's EPoll.hsc where you define the call to the 
Linux kernel function. This would be unneccessary, when poll (and kqueue 
and Windows equivalents) are already in the core. Ok, a bit more than 
EPoll.hsc would be unneccessary ;)


What I mean is that applications like web servers should benefit 
immediately from a change in the exisiting core and not require a (new) 
library. So a change is likely neccessary in Network.Socket and 
Network.Socket.Internal 
and in the IO monad when it comes to files. 

If someone want's to benefit from more functionality, like overlapping 
IO on Windows, the extension may be platform dependent available. 

However, in order to produce portable code which uses non blocking IO 
"the new way", a programer should never have to think about the target 
platform. 



BTW: Here are also some names and ideas mentioned:
http://www.haskell.org/pipermail/cvs-ghc/2008-February/041236.html

I actually had web applications in mind when I asked my first question 
as many tiny and lightweight requests to the web server will become more 
and more the rule with techniques as comet or Bayeux protocoll or HTML5 
web sockets. I speculate  this will be even more true with per thread 
garbage collection in GHC 6.12.x

Any non-blocking call to select should be save to replace by epoll, as the
semantics are the same.



Not exactly the same; but keep in mind we also need to support kqueue &
Windows I/O completion ports (and select() as a fallback). In an ideal
world you can provide a unified API that will work across all of the
platforms, with the I/O multiplexer hidden behind the interface.


  

Absolutely right, I forgot to mention. I am aware of

epoll - Linux
kqueue - the BSD's and MacOS; does the interface differ, on MacOS, I 
dont't know
IO Completion Port 
 - 
Windows 
(http://stackoverflow.com/questions/67082/what-is-the-best-epoll-kqueue-select-equvalient-on-windows)

poll - Solaris


As epoll is considerably more fine grained than non-blocking select,
the architecture must support a run loop which effectively retrieves
events faster than non-blocking select would do. Otherwise the effort
would be futile.



It'd be hard to be slower, with select() you have to do O(n) "fdIsSet"
tests.

G
  


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

Re: [Haskell-cafe] Re: Why?

[Dan Doel]

On Friday 11 December 2009 1:06:39 pm Luke Palmer wrote:
> That's how I see it as a user of the language.  At the most abstract
> level, omitting some of the practical details of the language (such as
> the built-in numeric types), Haskell's reduction follows beta
> reduction with sharing, and so at that level I think the answer to (2)
> is "nothing".

Yes, that's probably the answer, but a related question is how useful the 
logic is for various applications.

For one, the logic that corresponds to Haskell via Curry-Howard is 
inconsistent, because general recursion/fix/error/negative types/etc. let you 
prove

  forall a. a

But that isn't a very desirable property from a logical standpoint, because it 
calls into question whether any proofs you do really prove what they allege.

Second, again via Curry-Howard, Haskell's (GHC's) type system corresponds to a 
higher-order logic without first-order quantification, because it doesn't have 
real dependent types. This is why you need things like Haskabelle: because the 
propositions (types) in Haskell *can't* talk about value-level terms, and 
those are generally what you want to prove things about.

With enough GADT/type family fanciness, you can reconstruct (roughly) every 
value-level entity in the type level, and establish a correspondence between 
any value-level term 't' and its associated type-level term 'T', such that if 
you prove something about T, you know (by construction) that a related 
property holds for t. And then you can use the fact that Haskell is a higher-
order logic to prove the things you want about T. But this is convoluted and 
difficult (and you still have to worry that your proof is accidentally bottom 
:)).

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

Re: [Haskell-cafe] Re: Why?

[Luke Palmer]

On Fri, Dec 11, 2009 at 10:04 AM, pbrowne  wrote:
> Two questions
> 1) Is this correspondence between operational and logical semantics a
> desirable property of *purity* in the Haskell world?
>
> 2) What, if anything, prevents the execution of a Haskell term from
> being a proof in equational logic?
>
>
> It seems that Haskells type system has this logical purity[4]
>
>
> My motivation for such questions is that I am researching various
> *algebraic styles* such as Haskell, OCAML, Maude, and CafeOBJ.
> My current general research question is; how closely do executable terms
> in these languages match their *logical* meaning. For example, languages
> like Java need additional logical scaffolding (like JML[3]) to give them
> logical machine readable meaning.

I admit that I don't fully know what you are talking about.  What do
you mean by logical meaning -- as opposed to what other sort of
meaning?

The equational reasoning in Haskell comes from its denotational
semantics (which, mind, is not completely formally specified -- but
once you expand typeclasses to dictionary passing style, you get a
standard DCPO semantics).  If terms are equal in denotation, then they
are equal by observation (modulo efficiency).

So it is not equations that directly define the semantics of Haskell,
but rather mapping the syntax to mathematical objects.  We derive
Haskell's equational reasoning from the equational reasoning in the
semantic domain.

That's how I see it as a user of the language.  At the most abstract
level, omitting some of the practical details of the language (such as
the built-in numeric types), Haskell's reduction follows beta
reduction with sharing, and so at that level I think the answer to (2)
is "nothing".

Luke

> I *guess* that the gap between operational and logical semantics is
> rather less in Haskell that in Java, and I further *guess* that the gap
> less again in Maude or CafeOBJ. I think a good answer to question 2)
> would remove the *guess* from the Haskell case.
>
> Pat
> [1] http://rewriting.loria.fr/documents/plaisted.ps.gz
> [2]http://www.forsoft.de/~rumpe/icse98-ws/tr/0202Diaconescu.ps
> [3] http://www.eecs.ucf.edu/~leavens/JML/
> [4]http://www.haskell.org/haskellwiki/Type_arithmetic
>
>
> Dan Doel wrote:
>> The use of equational reasoning in a language like Haskell (as advocated by,
>> say, Richard Bird) is that of writing down naive programs, and transforming
>> them by equational laws into more efficient programs. Simple examples of this
>> are fusion laws for maps and folds, so if we have:
>>
>>     foo = foldr f z . map g . map h
>>
>> we can deforest it like so:
>>
>>     foldr f z . map g . map h
>>       = (map f . map g = map (f . g))
>>     foldr f z . map (g . h)
>>       = (foldr f z . map g = foldr (f . g) z)
>>     foldr (f . g . h) z
>>
>> now, this example is so simple that GHC can do it automatically, and that's a
>> side benefit: a sufficiently smart compiler can use arbitrarily complex
>> equational rules to optimize your program. But, for instance, Bird (I think)
>> has a functional pearl paper on incrementally optimizing a sudoku solver*
>> using equational reasoning such as this.
>>
>> Now, you can still do this process in an impure language, but impurity ruins
>> most of these equations. It is not true that:
>>
>>     map f . map g = map (f . g)
>>
>> if f and g are not pure, because if f has side effects represented by S, and 
>> g
>> has side effects represented by T, then the left hand side has side effects
>> like:
>>
>>     T T T ... S S S ...
>>
>> while the right hand side has side effects like:
>>
>>     T S T S T S ...
>>
>> so the equation does not hold.
>>
>> This is all, of course, tweaking programs using equational rules you've
>> checked by hand. Theorem provers are for getting machines to check your
>> proofs.
>>
>> Hope that helps.
>> -- Dan
>>
>> * If you check the haskell wiki page on sudoku solvers, there's an entry
>> something like 'sudoku ala Bird', written by someone else (Graham Hutton,
>> comes to mind), that demonstrates using Bird's method.
>
>
> ___
> 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] Re: Type system speculation

[Peter Verswyvelen]

How are things like this handled in say - Morrow - using extensible
records? I guess when one defines functions operating on extensible
records you get a lot of reuse for free (in Andrew's example, you
would just extend the record with either a Checked or Unchecked label)

On Fri, Dec 11, 2009 at 12:02 AM, Luke Palmer  wrote:
> On Thu, Dec 10, 2009 at 1:46 PM, Andrew Coppin
>  wrote:
>> o...@okmij.org wrote:
>>>
>>> Andrew Coppin wrote:
>>>

 What we're really trying to do here is attach additional information to a
 value - information which exists only in the type checker's head, but has
 no
 effect on runtime behaviour.

>>>
>>> Haskell has had the ability to attach arbitrary many pieces of
>>> (type-level) data to arbitrary types for a long time -- ever since
>>> multi-parameter type classes and functional dependencies have been
>>> introduced. Nowadays, type families accomplish the same with fewer
>>> keystrokes. One merely needs to define a type family
>>>        type family Attrib n index :: *
>>> which maps the existing type n and the index to an arbitrary type.
>>>
>>
>> Ah, good point. I hadn't thought of that!
>>
>> So it seems you can indeed attach arbitrary attributes to any type, any
>> time. However, I don't immediately see a way to construct a "safe" string
>> type and an "unsafe" string type, so that you can write code which
>> distinguishes between them, but that existing code that just expects a plain
>> ordinary string still works.
>
> Well, what does existing code which just returns a plain ordinary
> string return?  Presumably unsafe, so there would have to be a way to
> bias.
>
>> You could newtype string as two new types and
>> attach whatever attributes you want to these types, but then normal string
>> functions wouldn't work. Any ideas?
>
> That is the way I do it, with explicit conversion functions to
> indicate what I think is going on.  As I pointed out, while passing a
> specialized version to ordinary functions might work (a common
> technique in OO), getting them back is another matter.
>
> module SafeString (String, fromSafe, safe)
> import Prelude hiding (String)
>
> newtype String = String { fromSafe :: Prelude.String }
>
> safe :: Prelude.String -> Maybe String
> safe s | verify s = Just (String s)
>       | otherwise = Nothing
>
> And put in calls to safe and fromSafe explicitly.  You might see this
> as a pain, but half of them (the safe calls) are adding value by
> forcing you to deal with it if your transformations are not
> safety-preserving.  The fromSafe calls could technically be omitted,
> though you could argue that they are providing a nice abstraction
> barrier too:  SafeStrings, being a subtype, might have a better
> representation[1] than ordinary Strings, which you may later decide,
> so fromSafe is providing you with the opportunity to change that later
> without affecting the client code.
>
> [1] For example (1) a bit-packed representation to save a little
> space, or (2) allowing the SafeString module to be reproduced in a
> proof assistant where the String type contains proof of its safety, so
> that you can verify the client code verbatim  (This is currently not
> possible, but it is something I imagine being possible :-).
>
> Luke
> ___
> 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] Fwd: Will GHC finally support epoll in 2009?

[Gregory Collins]

Johann Höchtl  writes:

> I think the overall goal should be to get rid of
> http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hsc,
> as it's in the core.

I don't follow, could you explain?


> Any non-blocking call to select should be save to replace by epoll, as the
> semantics are the same.

Not exactly the same; but keep in mind we also need to support kqueue &
Windows I/O completion ports (and select() as a fallback). In an ideal
world you can provide a unified API that will work across all of the
platforms, with the I/O multiplexer hidden behind the interface.


> As epoll is considerably more fine grained than non-blocking select,
> the architecture must support a run loop which effectively retrieves
> events faster than non-blocking select would do. Otherwise the effort
> would be futile.

It'd be hard to be slower, with select() you have to do O(n) "fdIsSet"
tests.

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

[Haskell-cafe] Re: killer app, again

[Johann Höchtl]

On Dec 10, 2:38 pm, Bulat Ziganshin  wrote:
> Hello Sebastian,
>
> Thursday, December 10, 2009, 4:27:49 PM, you wrote:
>
> > The killer app for that, IMO, is parallelism these days
>
> btw, are you seen Google App Engine? it's python/java ATM, but i think
> that haskell will be ideal fit there. it's all about
> computations-in-cloud, or more precisely hosting-in-a-cloud, like
> Amazon EC2
>
I think the first language which would come to mind, is acutally
Erlang. As a cloud server process and cloud database backend might be
physically distributed, it's more logical to send messages between
them asynchronously, than share state in parallel. But yes, Haskell
fit's this pattern well, through the Control.Concurrent library.

> so, both individual cpus and largest servers now are multi-threaded,
> it just need some time so EC2/GAP developers will realize Haskell
> potential
>
> --
> Best regards,
>  Bulat                            mailto:bulat.zigans...@gmail.com
>
> ___
> Haskell-Cafe mailing list
> haskell-c...@haskell.orghttp://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] Re: Why?

[pbrowne]

Dan,
>From your example, I can appreciate the value of purity. But I am still
unsure how close Haskell terms are to pure *equational logic*[1]. The
operational semantics of languages like CafeOBJ[1] are very close to
their intended logical semantics. CafeOBJ modules contain theories in
equational logic and evaluations can be considered as proof of these
theories.
>From your point-free example, it seems that the Haskell compiler can
perform *equational reasoning* to transform higher level (point) terms
into more efficient basic Haskell code. But my questions concerns the
precise semantics of this *basic* Haskell code.

Two questions
1) Is this correspondence between operational and logical semantics a
desirable property of *purity* in the Haskell world?

2) What, if anything, prevents the execution of a Haskell term from
being a proof in equational logic?


It seems that Haskells type system has this logical purity[4]


My motivation for such questions is that I am researching various
*algebraic styles* such as Haskell, OCAML, Maude, and CafeOBJ.
My current general research question is; how closely do executable terms
in these languages match their *logical* meaning. For example, languages
like Java need additional logical scaffolding (like JML[3]) to give them
logical machine readable meaning.
I *guess* that the gap between operational and logical semantics is
rather less in Haskell that in Java, and I further *guess* that the gap
less again in Maude or CafeOBJ. I think a good answer to question 2)
would remove the *guess* from the Haskell case.

Pat
[1] http://rewriting.loria.fr/documents/plaisted.ps.gz
[2]http://www.forsoft.de/~rumpe/icse98-ws/tr/0202Diaconescu.ps
[3] http://www.eecs.ucf.edu/~leavens/JML/
[4]http://www.haskell.org/haskellwiki/Type_arithmetic


Dan Doel wrote:
> The use of equational reasoning in a language like Haskell (as advocated by, 
> say, Richard Bird) is that of writing down naive programs, and transforming 
> them by equational laws into more efficient programs. Simple examples of this 
> are fusion laws for maps and folds, so if we have:
> 
> foo = foldr f z . map g . map h
> 
> we can deforest it like so:
> 
> foldr f z . map g . map h
>   = (map f . map g = map (f . g))
> foldr f z . map (g . h)
>   = (foldr f z . map g = foldr (f . g) z)
> foldr (f . g . h) z
> 
> now, this example is so simple that GHC can do it automatically, and that's a 
> side benefit: a sufficiently smart compiler can use arbitrarily complex 
> equational rules to optimize your program. But, for instance, Bird (I think) 
> has a functional pearl paper on incrementally optimizing a sudoku solver* 
> using equational reasoning such as this.
> 
> Now, you can still do this process in an impure language, but impurity ruins 
> most of these equations. It is not true that:
> 
> map f . map g = map (f . g)
> 
> if f and g are not pure, because if f has side effects represented by S, and 
> g 
> has side effects represented by T, then the left hand side has side effects 
> like:
> 
> T T T ... S S S ...
> 
> while the right hand side has side effects like:
> 
> T S T S T S ...
> 
> so the equation does not hold.
> 
> This is all, of course, tweaking programs using equational rules you've 
> checked by hand. Theorem provers are for getting machines to check your 
> proofs.
> 
> Hope that helps.
> -- Dan
> 
> * If you check the haskell wiki page on sudoku solvers, there's an entry 
> something like 'sudoku ala Bird', written by someone else (Graham Hutton, 
> comes to mind), that demonstrates using Bird's method.


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

Re: [Haskell-cafe] SmallCheck design question

[Johannes Waldmann]

>> 2. why depth and not size (= total number of constructors)?

> That seems harder to generate terms compositionally. To create all
> terms of depth n+1 you just glue together all terms of depth n, but to
> create terms of size n+1 you need to glue 1 with n, 2 with n-1 etc.

So?

One would fear that this is inefficient
because then these series (of smaller sizes)
would have to be generated several times.

But no, instead of class Serial a where series :: Int -> [a]
one could "cache" these into  series' :: [[a]]
such that  series k == series' !! k

actually, series k == [ 0 .. k ] >>= ( series' !! )
because I'd want series' do be disjoint
(each object has only one size).

That should be doable by a simple rewrite of (some parts)
of the library. I'm going to find a clever student
to whom I could assign this ...

Are there any standard test cases
(i.e., they work nicely with the original Smallcheck
and must continue to work with any modified version)?

Best - Johannes.



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

Re: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009?

[Johann Höchtl]

Gregory Collins wrote:

"Bryan O'Sullivan"  writes:

  

If I develop the time and energy to take a serious crack at it, I will
post here to let people know. This would be an effort where having
multiple people work on different implementations concurrently would
be a shame.



I'm interested in this topic as well and have recently starting hacking
timeout support into Johan's event library:

http://github.com/tibbe/event
http://github.com/gregorycollins/event

  
I think the overall goal should be to get rid of 
http://github.com/gregorycollins/event/blob/master/src/System/Event/EPoll.hsc, 
as it's in the core.
Any non-blocking call to select should be save to replace by epoll, as 
the semantics are the same. As epoll is considerably more fine grained 
than non-blocking select, the architecture must support a run loop which 
effectively retrieves events faster than non-blocking select would do. 
Otherwise the effort would be futile.

Maybe we should form a working group?

G
  


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

Re: [Haskell-cafe] Fwd: Will GHC finally support epoll in 2009?

[Gregory Collins]

"Bryan O'Sullivan"  writes:

> If I develop the time and energy to take a serious crack at it, I will
> post here to let people know. This would be an effort where having
> multiple people work on different implementations concurrently would
> be a shame.

I'm interested in this topic as well and have recently starting hacking
timeout support into Johan's event library:

http://github.com/tibbe/event
http://github.com/gregorycollins/event

Maybe we should form a working group?

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

Re: [Haskell-cafe] Re: Why?

[Dan Doel]

On Friday 11 December 2009 3:24:03 am pbrowne wrote:
> The issue of *purity* in Haskell and this thread has confused me.
> 
> At value level (not type level) is this linked with *equational reasoning*?
> Are the operational semantics of Haskell similar but not the same as
> equational logic?
> 
> Why are theorem provers such as Haskabelle need?
> http://www.mail-archive.com/haskell-cafe@haskell.org/msg64843.html

The use of equational reasoning in a language like Haskell (as advocated by, 
say, Richard Bird) is that of writing down naive programs, and transforming 
them by equational laws into more efficient programs. Simple examples of this 
are fusion laws for maps and folds, so if we have:

foo = foldr f z . map g . map h

we can deforest it like so:

foldr f z . map g . map h
  = (map f . map g = map (f . g))
foldr f z . map (g . h)
  = (foldr f z . map g = foldr (f . g) z)
foldr (f . g . h) z

now, this example is so simple that GHC can do it automatically, and that's a 
side benefit: a sufficiently smart compiler can use arbitrarily complex 
equational rules to optimize your program. But, for instance, Bird (I think) 
has a functional pearl paper on incrementally optimizing a sudoku solver* 
using equational reasoning such as this.

Now, you can still do this process in an impure language, but impurity ruins 
most of these equations. It is not true that:

map f . map g = map (f . g)

if f and g are not pure, because if f has side effects represented by S, and g 
has side effects represented by T, then the left hand side has side effects 
like:

T T T ... S S S ...

while the right hand side has side effects like:

T S T S T S ...

so the equation does not hold.

This is all, of course, tweaking programs using equational rules you've 
checked by hand. Theorem provers are for getting machines to check your 
proofs.

Hope that helps.
-- Dan

* If you check the haskell wiki page on sudoku solvers, there's an entry 
something like 'sudoku ala Bird', written by someone else (Graham Hutton, 
comes to mind), that demonstrates using Bird's method.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Fwd: Will GHC finally support epoll in 2009?

[Simon Marlow]

On 10/12/2009 17:48, Bryan O'Sullivan wrote:

On Thu, Dec 10, 2009 at 5:01 AM, Johann Höchtl mailto:johann.hoec...@gmail.com>> wrote:


 > Yes. I'm working on a patch at the moment.

Is there something planed to happen in 2010?


Retooling the I/O manager isn't a huge job, but it requires the
equivalent of several weeks of work. I tossed out my initial attempt at
a patch because I didn't have time to work on it, so I'm back to square
one. Johan Tibell and I have had occasional discussions about picking up
the thread again, but we've had a busy year and it's moderately
demanding work, so nothing has actually happened.

If I develop the time and energy to take a serious crack at it, I will
post here to let people know. This would be an effort where having
multiple people work on different implementations concurrently would be
a shame.


Bryan, if you have time could you give a brief outline of the main 
sticking points?  My gut feeling is that it shouldn't be "several weeks 
of work", but admittedly I've never worked with epoll().  Perhaps we 
need to take a step back and think about the architecture at a higher level?


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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

[minh thu]

2009/12/11 Johannes Laire :
> On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe  wrote:
>> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
>> went into Haskell forNoApparentReasonThatIHaveEverHeardOf
>
> Compare:
>
> someCoolFunc fstParam sndParam fooBarBazQuux
> some_cool_func fst_param snd_param foo_bar_baz_quux

Before even reading your paragraph below, I thought the second one was
easier to read :)

> In the first one, it's easy to see that there are 4 identifiers. But,
> at least for me, the second one is significantly harder to read;
> spaces and underscored are too similar. So, while underscores more
> clearly separate words in a single *identifier* and make it easier to
> read, in some cases I think they make *code* with many identifiers
> harder to read for exactly the same reason.
>
> In languages where function application looks like "f(x,y,z)" instead
> of "f x y z" this isn't a problem and I often use underscores.

Your example should be seen with a monospaced font to be fair thought,
as programming is usually done with such a font. (But both lines are
easier with a monospaced font.)

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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

[Johannes Laire]

On Thu, Dec 10, 2009 at 12:54 AM, Richard O'Keefe  wrote:
> Given the amazinglyUglyAndUnreadably baStudlyCaps namingStyle that
> went into Haskell forNoApparentReasonThatIHaveEverHeardOf

Compare:

someCoolFunc fstParam sndParam fooBarBazQuux
some_cool_func fst_param snd_param foo_bar_baz_quux

In the first one, it's easy to see that there are 4 identifiers. But,
at least for me, the second one is significantly harder to read;
spaces and underscored are too similar. So, while underscores more
clearly separate words in a single *identifier* and make it easier to
read, in some cases I think they make *code* with many identifiers
harder to read for exactly the same reason.

In languages where function application looks like "f(x,y,z)" instead
of "f x y z" this isn't a problem and I often use underscores.

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

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

[Colin Paul Adams]

> "Malcolm" == Malcolm Wallace  writes:

>> there is enough experimentally determined about reading in
>> general to be certain that visible gaps between words
>> materially improves readability, and internal capital letters
>> harm it.

Malcolm> Here is a (slightly mischievous) proposal.

Malcolm> Allow the Unicode non-breaking space character (  in
Malcolm> HTML) as a valid character in a varid or conid.

Malcolm> :-)

I thought of that one too (seriously). It has the disadvantage that
the syntax is ambiguous to the human eye without tool support
(e.g. highlighting). On the other hand humans are good at coping with
such ambiguity (we do it all the time in spoken language - and delight
in puns. And in written language, set is indistinguishable from set,
which is indistinguishable from set, which ... - to however many
distinct meanings for the word set are currently recognized).
-- 
Colin Adams
Preston Lancashire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Allowing hyphens in identifiers

[Malcolm Wallace]

there is enough experimentally determined about reading in general to
be certain that visible gaps between words materially improves
readability, and internal capital letters harm it.


Here is a (slightly mischievous) proposal.

Allow the Unicode non-breaking space character (  in HTML) as a  
valid character in a varid or conid.


:-)

Regards,
Malcolm

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

[Haskell-cafe] Hint causes GHCi linker error under Windows

[Martin Hofmann]

The following hint code causes GHCi to crash under Windows:

>  runInterpreter $ loadModules ["SomeModule.hs"]

The error message is: 

GHCi runtime linker: fatal error: I found a duplicate definition for
symbol _hs_gtWord64 whilst processing object file
   C:\Programme\Haskell Platform\2009.2.0.2\ghc-prim-0.1.0.0
HSghc-prim-0.1.0.o
This could be caused by:
   * Loading two different object files which export the same symbol
   * Specifying the same object file twice on the GHCi command line
   * An incorrect `package.conf' entry, causing some object to be
 loaded twice.
GHCi cannot safely continue in this situation.  Exiting now.  Sorry.

The problem does not occur under Unix or with a compiled program. IMHO
hint tries to start a second instance of GHCi which is not
allowed/possible under Windows. If this is the case a more telling error
message would be helpful.

I used the Haskell Platform, version 2009.2.0.2 under Windows XP. My
package.conf is:

C:/Programme/Haskell Platform/2009.2.0.2\package.conf:
Cabal-1.6.0.3, GHood-0.0.3, GLUT-2.1.1.2, HTTP-4000.0.6,
HUnit-1.2.0.3, MonadCatchIO-mtl-0.2.0.0, OpenGL-2.2.1.1,
QuickCheck-1.2.0.0, Win32-2.2.0.0, ansi-terminal-0.5.0,
ansi-wl-pprint-0.5.1, array-0.2.0.0, base-3.0.3.1, base-4.1.0.0,
bimap-0.2.4, bytestring-0.9.1.4, cgi-3001.1.7.1,
containers-0.2.0.1, cpphs-1.9, directory-1.0.0.3, (dph-base-0.3),
(dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3),
(dph-prim-seq-0.3), (dph-seq-0.3), extensible-exceptions-0.1.1.0,
fgl-5.4.2.2, filepath-1.1.0.2, (ghc-6.10.4), ghc-mtl-1.0.1.0,
ghc-paths-0.1.0.6, ghc-prim-0.1.0.0, haddock-2.4.2,
haskeline-0.6.2.2, haskell-src-1.0.1.3, haskell-src-exts-1.3.4,
haskell98-1.0.1.0, hint-0.3.2.1, hpc-0.5.0.3, html-1.0.1.2,
integer-0.1.0.1, mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1,
old-time-1.0.0.2, packedstring-0.1.0.1, parallel-1.1.0.1,
parsec-2.1.0.1, pointless-haskell-0.0.1, pretty-1.0.1.0,
process-1.0.1.1, random-1.0.0.1, regex-base-0.72.0.2,
regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, stm-2.1.1.2,
syb-0.1.0.1, template-haskell-2.3.0.1, time-1.1.2.4,
utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0

Thanks,

Martin

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

Re: [Haskell-cafe] Re: Why?

[pbrowne]

The issue of *purity* in Haskell and this thread has confused me.

At value level (not type level) is this linked with *equational reasoning*?
Are the operational semantics of Haskell similar but not the same as
equational logic?

Why are theorem provers such as Haskabelle need?
http://www.mail-archive.com/haskell-cafe@haskell.org/msg64843.html


Pat

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