Re: [Haskell-cafe] Playing with ATs again

2010-08-04 Thread Ivan Lazar Miljenovic
On 5 August 2010 16:48, Gregory Crosswhite  wrote:
>  On 8/4/10 11:40 PM, Andrew Coppin wrote:
>>
>> Ivan Lazar Miljenovic wrote:
>>>
>>> Don't forget, GHC is open source: if this lack really was "dumb" and
>>> annoying you, there was nothing stopping you from rectifying this
>>> situation up until now.
>>
>> Except that, in the real world, this is actually completely infeasible.
>> Yes, I know it's the basic tenant of OSS that you can modify the program to
>> do whatever you want. But in reality, something like GHC is far too large
>> and complex for this to be a realistic possibility. And this holds for most
>> other nontrivial software too.
>
> Fair enough, but if one can't do better one's self then one should be
> careful about calling the work of others "dumb", which was the original
> point.

Exactly.  Either do it yourself or be grateful that someone has done
_something_, even if it isn't as good as you like.  It's not like
you're paying for it...

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Playing with ATs again

2010-08-04 Thread Gregory Crosswhite

 On 8/4/10 11:40 PM, Andrew Coppin wrote:

Ivan Lazar Miljenovic wrote:

Don't forget, GHC is open source: if this lack really was "dumb" and
annoying you, there was nothing stopping you from rectifying this
situation up until now.


Except that, in the real world, this is actually completely 
infeasible. Yes, I know it's the basic tenant of OSS that you can 
modify the program to do whatever you want. But in reality, something 
like GHC is far too large and complex for this to be a realistic 
possibility. And this holds for most other nontrivial software too.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Fair enough, but if one can't do better one's self then one should be 
careful about calling the work of others "dumb", which was the original 
point.


Cheers,
Greg

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


Re: [Haskell-cafe] Playing with ATs again

2010-08-04 Thread Andrew Coppin

Victor Nazarov wrote:

I think it is more simple like:

class Bijection a b where
  ...

type LeftToRight a = (Bijection a b) => b
type RightToLeft b = (Bijection a b) => a
  


Hmm, yes... That looks like it could work.

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


Re: [Haskell-cafe] Playing with ATs again

2010-08-04 Thread Andrew Coppin

Ivan Lazar Miljenovic wrote:

Don't forget, GHC is open source: if this lack really was "dumb" and
annoying you, there was nothing stopping you from rectifying this
situation up until now.
  


Except that, in the real world, this is actually completely infeasible. 
Yes, I know it's the basic tenant of OSS that you can modify the program 
to do whatever you want. But in reality, something like GHC is far too 
large and complex for this to be a realistic possibility. And this holds 
for most other nontrivial software too.


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


[Haskell-cafe] Problem with System.Timeout in Windows

2010-08-04 Thread Adolfo Builes
Hi All:

I have been trying to use System.timeout in windows, but for some
reason it doesn't work, a concrete example is:

import Network.HTTP
import System.Timeout

main = do
  rsp <- timeout 1000  $ simpleHTTP $ getRequest "http://10.1.2.3";
  case rsp of
Just rsp -> print $ show  rsp
Nothing  -> error "Nothing"

In this case I would expect to receive "Nothing" after 10 seconds, but
it ignores the timeout function.

I'm compiling with -threaded, but it does not work either, I'm using ghc 6.12.2.

Does someone know what could be going wrong ?

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


Re: [Haskell-cafe] Playing with ATs again

2010-08-04 Thread Ivan Lazar Miljenovic
On 4 August 2010 03:45, Ryan Ingram  wrote:
> So I believe the "final" way to do this, which is not yet implemented,
> works something like this:
>
> type family LeftToRight a
> type family RightToLeft b
>
> class (LeftToRight a ~ b, RightToLeft b ~ a) => Bijection a b where
>   ...
>
> I agree, the fact that this doesn't work is really dumb.

The reason Manuel Chakravarty gave me (if I recall correctly) that
this doesn't work is as follows:

Type classes are stored in dictionaries.  To be able to have
superclass constraints like this requires that type information also
be stored in those dictionaries, which currently isn't done.  They
could have added this functionality in, but SPJ was going to be
working on a new type-checker anyway (which I believe is now done) so
this was postponed until after the new type-checker was finished.  As
we should hopefully be seeing 6.14 out in a few months time, there
isn't time to be able to get superclass constraints in for it, so we
probably won't have them until 6.16 next year.

So, I wouldn't say that it's "dumb".  Unfortunate, a pity, etc., but not "dumb".

Don't forget, GHC is open source: if this lack really was "dumb" and
annoying you, there was nothing stopping you from rectifying this
situation up until now.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Playing with ATs again

2010-08-04 Thread Victor Nazarov
On Tue, Aug 3, 2010 at 9:45 PM, Ryan Ingram  wrote:
> So I believe the "final" way to do this, which is not yet implemented,
> works something like this:
>
> type family LeftToRight a
> type family RightToLeft b
>
> class (LeftToRight a ~ b, RightToLeft b ~ a) => Bijection a b where
>   ...
>
> I agree, the fact that this doesn't work is really dumb.
>

I think it is more simple like:

class Bijection a b where
  ...

type LeftToRight a = (Bijection a b) => b
type RightToLeft b = (Bijection a b) => a


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


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Gregory Crosswhite
 The documentation is a little confusing on this issue.  It sounded to 
me when I read the documentation that all of the *OS* threads were 
blocked by the FFI, when what was meant was that all of the *IO* threads 
assigned to the calling OS thread are what is blocked, because the docs 
just say that "threads" are blocked without being clear that they are 
only referring to a particular subset of the threads.


Cheers,
Greg

On 8/4/10 8:31 PM, Brandon S Allbery KF8NH wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/4/10 17:16 , Andrew Coppin wrote:

I have a vague recollection of there being a situation to do with calling
foreign code that makes all Haskell threads block in the non-threaded RTS,
but not in the threaded one. Depending on how big your send and receive

Well, yes.  This should be obvious; code invoked via the FFI can't be
cooperatively multitasked by the Haskell runtime (how would you accomplish
this?  Think about it), and preemptive multitasking is only possible via OS
threads.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com

system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxaMJ0ACgkQIn7hlCsL25VqHwCgl3z84LQIpr6RfA2rGOmevU2x
miYAnjnpwVR+yEQiynXfk3JGQZv32YfY
=uEjB
-END PGP SIGNATURE-
___
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: Handling absent maintainers

2010-08-04 Thread Erik de Castro Lopo
Ivan Lazar Miljenovic wrote:

> On 5 August 2010 13:32, Mark Wotton  wrote:
> > On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic
> >  wrote:
> >> On 5 August 2010 13:23, Mark Wotton  wrote:
> >>> Might it be possible to enable multiple maintainers on packages, each
> >>> of whom can upload new versions? As far as I can tell, that's not
> >>> currently possible with Cabal.
> >>
> >> Huh?  Cabal doesn't care who the maintainers are: it just has a text
> >> field where you list a maintainer[s].  See for example
> >> http://hackage.haskell.org/package/fgl-5.4.2.3
> >>
> >> Currently, AFAIK Hackage allows anyone with an account to upload anything.
> >
> > Can you have two people uploading versions of the same package,
> > though? Presumably it's not possible for me to upload a version of
> > bytestring which makes monkeys fly out of your ethernet port when you
> > try to concatenate strings.
> 
> Well, I'd like to see the code required to spontaneously create
> monkeys at an ethernet port, but from what I've read Hackage has no
> constraints in place in terms of who uploads what and when.  You just
> can't upload something with a version that's already on Hackage.

The permissiveness of hackage uploads suggests that Hackage needs 
to start using something like GPG signing and GPG webs of trust.

The Debian project has stuff like this in place and I'm sure this
community could learn a lot from what Debian is currently using.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Handling absent maintainers

2010-08-04 Thread Ivan Lazar Miljenovic
On 5 August 2010 13:32, Mark Wotton  wrote:
> On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic
>  wrote:
>> On 5 August 2010 13:23, Mark Wotton  wrote:
>>> Might it be possible to enable multiple maintainers on packages, each
>>> of whom can upload new versions? As far as I can tell, that's not
>>> currently possible with Cabal.
>>
>> Huh?  Cabal doesn't care who the maintainers are: it just has a text
>> field where you list a maintainer[s].  See for example
>> http://hackage.haskell.org/package/fgl-5.4.2.3
>>
>> Currently, AFAIK Hackage allows anyone with an account to upload anything.
>
> Can you have two people uploading versions of the same package,
> though? Presumably it's not possible for me to upload a version of
> bytestring which makes monkeys fly out of your ethernet port when you
> try to concatenate strings.

Well, I'd like to see the code required to spontaneously create
monkeys at an ethernet port, but from what I've read Hackage has no
constraints in place in terms of who uploads what and when.  You just
can't upload something with a version that's already on Hackage.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Handling absent maintainers

2010-08-04 Thread Mark Wotton
On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic
 wrote:
> On 5 August 2010 13:23, Mark Wotton  wrote:
>> Might it be possible to enable multiple maintainers on packages, each
>> of whom can upload new versions? As far as I can tell, that's not
>> currently possible with Cabal.
>
> Huh?  Cabal doesn't care who the maintainers are: it just has a text
> field where you list a maintainer[s].  See for example
> http://hackage.haskell.org/package/fgl-5.4.2.3
>
> Currently, AFAIK Hackage allows anyone with an account to upload anything.

Can you have two people uploading versions of the same package,
though? Presumably it's not possible for me to upload a version of
bytestring which makes monkeys fly out of your ethernet port when you
try to concatenate strings.

mark

-- 
A UNIX signature isn't a return address, it's the ASCII equivalent of a
black velvet clown painting. It's a rectangle of carets surrounding a
quote from a literary giant of weeniedom like Heinlein or Dr. Who.
        -- Chris Maeda
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Brandon S Allbery KF8NH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/4/10 17:16 , Andrew Coppin wrote:
> I have a vague recollection of there being a situation to do with calling
> foreign code that makes all Haskell threads block in the non-threaded RTS,
> but not in the threaded one. Depending on how big your send and receive

Well, yes.  This should be obvious; code invoked via the FFI can't be
cooperatively multitasked by the Haskell runtime (how would you accomplish
this?  Think about it), and preemptive multitasking is only possible via OS
threads.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxaMJ0ACgkQIn7hlCsL25VqHwCgl3z84LQIpr6RfA2rGOmevU2x
miYAnjnpwVR+yEQiynXfk3JGQZv32YfY
=uEjB
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Handling absent maintainers

2010-08-04 Thread Ivan Lazar Miljenovic
On 5 August 2010 13:23, Mark Wotton  wrote:
> Might it be possible to enable multiple maintainers on packages, each
> of whom can upload new versions? As far as I can tell, that's not
> currently possible with Cabal.

Huh?  Cabal doesn't care who the maintainers are: it just has a text
field where you list a maintainer[s].  See for example
http://hackage.haskell.org/package/fgl-5.4.2.3

Currently, AFAIK Hackage allows anyone with an account to upload anything.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Brandon S Allbery KF8NH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/4/10 08:04 , Frank Kupke wrote:
> After chatting with Chris privately it turned out that the confusion within 
> the Chat example is partly because I did not find a good and simple solution 
> for mixing user input and chat output asynchronously in one terminal stream. 
> One can possibly do better, here. 

http://hackage.haskell.org/package/hscurses is the best you're going to do
without moving to a GUI.

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxaL4IACgkQIn7hlCsL25WTxwCeJ3Tif9ikRtA9ns0YqTB3FGjA
QfIAn2AbaZqXLBxMO6EQlSpMPgvtWjkW
=r/zf
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Handling absent maintainers

2010-08-04 Thread Mark Wotton
On Wed, Aug 4, 2010 at 1:36 AM, Ben Millwood  wrote:
> On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton  wrote:
>>
>> I've uploaded haskell-src-meta-mwotton, using the development version.
>> It seems to work fine for my applications. It's a bit of a hack, but I
>> can't think of a better way to do it for now.
>>
>> mark
>>
>>
>> --
>> A UNIX signature isn't a return address, it's the ASCII equivalent of a
>> black velvet clown painting. It's a rectangle of carets surrounding a
>> quote from a literary giant of weeniedom like Heinlein or Dr. Who.
>>         -- Chris Maeda
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> I've just come up against one of the drawbacks of this approach -
> having needed haskell-src-meta for a personal project, I downloaded
> the source and updated it to work with GHC 6.12, fixed various bits
> and bobs, and only now found out that much of that work had already
> been done elsewhere :)
>
> Matt Morrow has been missing for a long time and I think it's
> reasonable to suppose he won't suddenly spring out of the darkness to
> fix things for us. I propose that someone just take up maintainership
> of the package. I am quite willing to do this with my version, or Mark
> if you think you'd like to keep a closer eye on your dependencies you
> could do it instead.
>
> I further propose that we should write up a haskellwiki page about
> absent maintainers and what the community thinks is reasonable in
> terms of attempting contact before assuming them missing, presumed
> gone. This kind of depends also on how big an indignity we consider it
> to be if someone updates a package while the maintainer is just on
> holiday or something.
>
> So we need to decide on: first, who will take haskell-src-meta, and
> second, what we think is good as a more general policy. I would think
> the process would go something like:
> 1. email maintainer, wait 2 weeks for reply
> 2. email cafe and maintainers of reverse dependencies with proposed
> changes, wait a week or so for people who know the maintainer to show
> up or other people to object to your changes
> 3. chomp package

I'm happy to let you do it, I don't understand much of the actual
source. Not sure who's the grand gatekeeper of Hackage, though.

Might it be possible to enable multiple maintainers on packages, each
of whom can upload new versions? As far as I can tell, that's not
currently possible with Cabal.

mark

-- 
A UNIX signature isn't a return address, it's the ASCII equivalent of a
black velvet clown painting. It's a rectangle of carets surrounding a
quote from a literary giant of weeniedom like Heinlein or Dr. Who.
        -- Chris Maeda
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Brandon S Allbery KF8NH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/4/10 05:11 , Magnus Therning wrote:
> Also very good looking.  Does the current stable version of Haddock really
> create a frame version?
> I've never seen one before...

http://www.haskell.org/ghc/docs/current/html/libraries/frames.html

- -- 
brandon s. allbery [linux,solaris,freebsd,perl]  allb...@kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon university  KF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxaLBUACgkQIn7hlCsL25XhhQCgs9SZ2kGZNLl76Pu4qQnGjkkw
rqwAn3pVaRj5+eTwW4W3LU+n2Jnc1Meq
=JfAa
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why is toRational a method of Real?

2010-08-04 Thread Ivan Lazar Miljenovic
On 5 August 2010 10:15, Lennart Augustsson  wrote:
> You're right.  It's bad to have toRational in Real.  It's also bad to
> have Show and Eq as superclasses to Num.

I understand why it's bad to have Show as a superclass, but why Eq?
Because it stops you from using functions as numbers, etc. ?


-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why is toRational a method of Real?

2010-08-04 Thread ok
> Why is toRational a method of Real? I thought that real numbers need not
> be rational, such as the square root of two. Wouldn't it make more sense
> to have some sort of Rational typeclass with this method?

I think everyone has problems with the Haskell numeric typeclasses.
The answer in this case is that
  - toRational DOES make sense for every instance of Real in the
Haskell98 Report and Libraries, because that basically means
floating point numbers, and floating point numbers are rationals
(if you allow 1/0, -1/0, and 0/0 you've covered infinities and NaNs)
  - the designers don't seem to have included any layers that weren't
needed for the tasks immediately at hand, after all, Haskell was
supposed to avoid success, and the language went through several
revisions quite quickly.
  - but then the wind changed and her face WAS frozen like that...

http://www.haskell.org/haskellwiki/Numeric_Prelude
shows what _can_ be done in Haskell.  Making it possible to work
with alternatives to parts of the standard Prelude was a very
far-sighted design decision.

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


Re: [Haskell-cafe] Why is toRational a method of Real?

2010-08-04 Thread John Meacham
On Wed, Aug 04, 2010 at 02:30:10PM -0400, Omari Norman wrote:
> Why is toRational a method of Real? I thought that real numbers need not
> be rational, such as the square root of two. Wouldn't it make more sense
> to have some sort of Rational typeclass with this method? Thanks.

The numeric classes are sort of messed up when it comes to non integral
values.  (not that they are perfect for other things) for instance,
realToFrac doesn't preserve NaN or Infinity, except on ghc when
optimization is turned on. and the rounding functions discard
information too by trying to convert a floating point value to an
integral one... 

I was probably going to introduce a 'FloatMax' type in jhc that is
guarenteed to be able to represent all values representable by native
floating point types, then replace the use of Rational as an
intermediate type with it.. not that that helps things right now really.


John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why is toRational a method of Real?

2010-08-04 Thread Lennart Augustsson
You're right.  It's bad to have toRational in Real.  It's also bad to
have Show and Eq as superclasses to Num.

On Wed, Aug 4, 2010 at 8:30 PM, Omari Norman  wrote:
> Why is toRational a method of Real? I thought that real numbers need not
> be rational, such as the square root of two. Wouldn't it make more sense
> to have some sort of Rational typeclass with this method? Thanks.
> --Omari
>
> ___
> 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] Suggestions For An Intro To Monads Talk.

2010-08-04 Thread Daniel van den Eijkel




For me, the following two things did the magic, so I'll suggest them:

1.
Writing a recursive function that takes a binary tree and returns the
same tree, but with its leaves enumerated. Each function call takes the
tree and the counter and returns the resulting tree and the new counter
value. The pattern that emerges is similar to the state monad. The
pattern shows that the order of the recursive calls is not ambiguous,
unlike in a function that just counts the leaves, for example. Changing
the order of the recursive calls changes the result.
(code below)

2. 
Putting the above pattern into a datatype and rewriting the
apply-funtion for this datatype (>>=) allows only to apply
funtions in a non-ambiguous way. Not giving a deconstructor for the IO
monad forces the programmer to
decide in which order calls to IO functions have to be done.

I hope this is clear enough; I was able to use the IO monad at the
moment I realized that Haskell uses this kind of "trick" to ensure that
the order of execution of function arguments is always well-defined and
never ambiguous. Of course, there is much more about monads, but this
was my entry point.

Best regards
Daniel


code (tree enumeration):

data Tree a = Leaf a | Node (Tree a) (Tree a) deriving Show

enumTree n (Node a b) =
 let (n', a')  = enumTree n a in
 let (n'', b') = enumTree n' b in 
 (n'', Node a' b')

enumTree n (Leaf x) = (n+1, Leaf n)





aditya siram schrieb:
Hi all,
I am doing an "Intro To Monads" talk in September [1]. The audience
consists of experienced non-Haskell developers but they will be
familiar with basic functional concepts (closures, first-class
functions etc.). 
  
I am looking for suggestions on how to introduce the concept and its
implications. I'd also like to include a section on why monads exist
and why we don't really see them outside of Haskell.
  
Has anyone here done a talk like this? And if so what parts of your
presentation were successful and what would you stay away from.
  
Thanks for the feedback.
-deech
  
[1] It's in St.Louis, Missouri at the St.Louis Perl
Mongers meeting so come on by if you're around!
  

___
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] Suggestions For An Intro To Monads Talk.

2010-08-04 Thread Hans Aberg

On 3 Aug 2010, at 23:51, aditya siram wrote:

I am doing an "Intro To Monads" talk in September [1]. The audience  
consists of experienced non-Haskell developers but they will be  
familiar with basic functional concepts (closures, first-class  
functions etc.).


I am looking for suggestions on how to introduce the concept and its  
implications. I'd also like to include a section on why monads exist  
and why we don't really see them outside of Haskell.


Probably because one does not bother writing them out in the type  
system. I wrote on a C++ wrap for Guile, and they showed up when  
typing expressions, though C++ templates are too limited to make this  
efficiently.


The monad has a code lifting property. If one has code which has both  
non-monadic and monadic components, it can be lifted up to the monadic  
level without having iterates (can be taken away with the monad  
projection).


So if one has code which has both non-IO and IO components, it can be  
lifted to the becoming all IO. Since IO and other imperative  
structures are incompatible with the lazy evaluation default, the type  
system can be used to describe them using monads.


Then one can use syntactic sugar like "do" and >>= to make the code  
look like ordinary imperative code.


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


Re: [Haskell-cafe] real-time audio processing [Was: can Haskell doeryting as we want?]

2010-08-04 Thread Henning Thielemann


On Wed, 4 Aug 2010, Don Stewart wrote:


job.vranish:


Hmm, it looks like the HASP project is working on some of this, though I'm not
sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/



Or look at EDSLs, like Atom:

   http://hackage.haskell.org/package/atom


Maybe Feldspar, too ...
  http://hackage.haskell.org/package/feldspar-compiler
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]

2010-08-04 Thread Don Stewart
job.vranish:
> + 1
> 
> 
> This is probably the biggest obstacle to using Haskell where I work. (Aviation
> industry, software for flight management systems for airplanes)
> 
> We often need to perform some computations with hard deadlines, say every 
> 20ms,
> with very little jitter.
> Major GC's spoil the fun; It's quite easy to have a major GC take longer than
> 20ms, and currently they are not "pauseable" (nor is it trivial to make them
> so).
> 
> It would be very nice to have some annotation/DSL/compiler-flag that would let
> me run a small block of mostly regular haskell code under hard, real-time
> constraints.
> 
> Hmm, it looks like the HASP project is working on some of this, though I'm not
> sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/
> 

Or look at EDSLs, like Atom:

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


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Ivan Lazar Miljenovic
Christopher Done  writes:

> On 4 August 2010 10:43, Chris Eidhof  wrote:
>> This looks very cool! It would be nice to put the pdf online somewhere, and 
>> add a link from the package documentation
>
> Regarding that, it would be nice if Hackage let you access the files
> in the package instead of having to extract the .tar.gz, as in this
> case the PDF is in the package; it makes sense to make it clickable
> somewhere on the package page.

Yeah, I'm beginning more and more to wish for a "documentation" section
in .cabal so that you can specify such things (would also help with
automated package generation for Linux distributions).

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Andrew Coppin

Frank Kupke wrote:

Andrew,

Thanks for pointing your finger at it
Am 04.08.2010 um 17:48 schrieb Andrew Coppin:
  


In that case, is there a way to determine whether or not the rest of the 
transaction completed? Because it looks like you can the same exception either 
way, regardless of whether a commit happened or not.


Ah, now I see. Excellent point. I was always focussing the commit case which is 
well designed, I am certain.
  


OK, so there's design work to do here. (Or at least, things to think 
about.) But that's OK. It's new and exciting. :-)





What impact (if any) does threaded vs non-threaded RTS have?


I have done a few tests with threads and could not find a significant 
difference. But I really did not look deep and thorough enough into it to give 
a qualified answer.
  


I have a vague recollection of there being a situation to do with 
calling foreign code that makes all Haskell threads block in the 
non-threaded RTS, but not in the threaded one. Depending on how big your 
send and receive buffers are and how long everything is blocked for, it 
might not matter. I just thought I'd ask about it...


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


Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]

2010-08-04 Thread Job Vranish
+ 1


This is probably the biggest obstacle to using Haskell where I work.
(Aviation industry, software for flight management systems for airplanes)

We often need to perform some computations with hard deadlines, say every
20ms, with very little jitter.
Major GC's spoil the fun; It's quite easy to have a major GC take longer
than 20ms, and currently they are not "pauseable" (nor is it trivial to make
them so).

It would be very nice to have some annotation/DSL/compiler-flag that would
let me run a small block of mostly regular haskell code under hard,
real-time constraints.

Hmm, it looks like the HASP project is working on some of this, though I'm
not sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/

- Job


On Wed, Aug 4, 2010 at 4:24 PM, Stephen Sinclair wrote:

> On Aug 3, 8:31 pm, Jeremy Shaw  wrote:
> >  The only area I have had any trouble with Haskell is doing realtime
> > music synthesis. And only because the garbage collector is not
> > realtime friendly. That is not unfixable though. However, I am
> > thinking that the best way to do realtime synthesis with Haskell is to
> > use it to create a DSL that uses LLVM to create code at runtime so
> > that the realtime code is outside the scope of the normal RTS and
> > garbage collector.
>
> I'm also very interested in this topic---how to apply a general-
> purpose functional language to real-time needs, even if it is in a
> domain-specific way.
>
> Indeed, it mostly comes down to memory management and the fact that
> functional concepts like closures and laziness require a lot of
> dynamic allocation and garbage collection.  Certainly, one solution is
> to provide a real-time-friendly memory manager.
>
> However, it's interesting to notice that, as proven by FAUST [1], a
> huge amount of DSP algorithms can be expressed functionally in a real-
> time-compatible way by describing them as static diagrams of connected
> blocks.  These can be efficiently compiled to imperative code with no
> dynamic memory allocation required.
>
> So yes, if such a language were available as an embedded DSL in
> Haskell (one effort can be found here [2]), it could be generated at
> run-time using LLVM and called out to.  Alternatively, it would be
> very cool if it were possible to generate code statically at compile
> time, just like in FAUST.  I can imagine this being very useful,
> especially if it could be generalized to operate on datatypes other
> than floating points, and had easy access to data structures provided
> by non-RT portions of the code.  If there are mutability requirements,
> it could be made to run in the ST monad with a pre-allocated
> workspace.
>
> Of course _modifying_ such structures at run-time is always a dynamic
> thing by definition, although there is the possibility of dynamically
> generating a replacement block diagram while an one existing one runs,
> and using an atomic pointer swap to switch them without causing
> interruptions.
>
> In any case, as far as I know the only thing in the way is that it's
> impossible to tell GHC to compile a section of code in such as way as
> to guarantee avoidance of memory management.  Compilers and runtime-
> systems always seem to be either RT- or non-RT-friendly, but never
> seem to support the idea of code *portions* that have differing
> requirements.  My point is, RT code _can_ be expressed functionally,
> even if the RT-ness imposes certain expressivity restrictions.  It
> would be very cool to be able to mark sections of code as following
> such a "sub-language" and be guaranteed that the compiler will
> generate GC-free code for a particular function, if possible, or
> otherwise fail.
>
> Even if such a sub-language were no more expressive than C, it would
> be nice to be able to write it in Haskell instead of dropping down to
> C, so that data can be easily shared with non-RT parts, and Haskell's
> type checker could be exploited.  It seems strange to me that with
> technology like Haskell and GHC we still depend on using C to express
> these last remaining droplets of real-time determinism requirements---
> strange, since I think of higher-level languages like Haskell to be
> supersets of the capabilities of C---and annoying, because it means
> having to deal with the complexities of language interoperability,
> just for a few low-level components of an application.
>
> I realize some of this has probably been discussed in conjunction with
> FRP.  I'm aware of one paper on RT-FRP that talks about requiring an
> RT-friendly sub-language [3], but I don't pretend to follow it
> completely.  I'm almost sure it also has something to do with arrows,
> but I have very little idea what they are, since I'm still just
> "getting" monads at this point in my personal Haskell understanding.
> I hope someone more knowledgeable about these things on this list
> might be able to comment on their relation to real-time determinism.
>
> [1] http://faust.grame.fr/
> [2]
> http://claudiusmaxim

Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Bryan O'Sullivan
On Wed, Aug 4, 2010 at 2:11 AM, Magnus Therning  wrote:

> On Wed, Aug 4, 2010 at 06:00, Mark Lentczner  wrote:
> > The Haddock team has spent the last few months revamping the look of the
> generated output. We're pretty close to done, but we'd like to get the
> community's input before we put it in the main release.
> >
> > Please take a look, and then give us your feedback through a short survey
> >
> > Sample pages:  http://www.ozonehouse.com/mark/snap-xhtml/index.html
>
> I really like it, especially the synopsis tab on the right.


Likewise, although I notice that the synopsis tab closes if I click on a
link inside it, which seems unfortunate.

Mark, thanks for the great work!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] real-time audio processing

2010-08-04 Thread Henning Thielemann


On Wed, 4 Aug 2010, Stephen Sinclair wrote:


On Aug 3, 8:31 pm, Jeremy Shaw  wrote:

 The only area I have had any trouble with Haskell is doing realtime
music synthesis. And only because the garbage collector is not
realtime friendly. That is not unfixable though. However, I am
thinking that the best way to do realtime synthesis with Haskell is to
use it to create a DSL that uses LLVM to create code at runtime so
that the realtime code is outside the scope of the normal RTS and
garbage collector.


I'm also very interested in this topic---how to apply a general-
purpose functional language to real-time needs, even if it is in a
domain-specific way.


If you like to see real-time audio synthesis in action ...
   http://code.haskell.org/hal/05-2010/unsafe-performance/MOV09560.MPG

and for the background:
   http://arxiv.org/abs/1004.4796
   http://dafx04.na.infn.it/WebProc/Proc/P_201.pdf

Unfortunately the package is not yet available on Hackage, because there 
are some patches to the llvm interface that I could not push to the main 
branch so far.



Regarding garbage collection: My experience is that the garbage collector 
is quite friendly, but you run easily into a memory leak, and this memory 
leak will make the garbage collector busy, because it has to check 
reachability of more chunks. Nonetheless you can consider the memory leaks 
being bugs of the garbage collector or the compiler.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Frank Kupke
Andrew,

Thanks for pointing your finger at it
Am 04.08.2010 um 17:48 schrieb Andrew Coppin:

> Frank Kupke wrote:
>> Good questions. I am about to write a paper explaining the design of the 
>> DSTM library in more detail which I will link when available. Please bear 
>> with me, here. In the meantime please find some shorter answers below.
>>  
> 
> Well, that was pretty comprehensive. A few questions remain...
> 
>> - If the failure comes up *before* the transaction has been validated ok, it 
>> is aborted.
> 
> Right. So the transaction rolls back and the application gets an exception?
Yes, the transaction aborts and the application gets an exception (see remarks 
below).
> 
>> - If the failure comes up *after* the transaction has been validated ok, it 
>> is committed.
>>  
> 
> So if a TVar goes walkabout in the split second between validate and commit, 
> the others commit anyway, and then the application gets an exception?
Yes.
> 
> In that case, is there a way to determine whether or not the rest of the 
> transaction completed? Because it looks like you can the same exception 
> either way, regardless of whether a commit happened or not.
Ah, now I see. Excellent point. I was always focussing the commit case which is 
well designed, I am certain. But, maybe, the abort case above is not. It would 
probably be better to not only abort but also restart the transaction even in 
presence of a failure (that is what's being done when there is no failure). I 
am not quite clear yet about a possible implementation of such a behavior. 
Currently I'm thinking: Restarting a transaction containing broken TVars will 
definitely fail again. To avoid that, the validation vote of a broken TVar 
(i.e. not able to vote any more) should be taken as a valid vote and no 
exception should be thrown. Eventually every transaction comes to a commit and 
probably that's the only place where an exception should be thrown. Then the 
answer to your question is clear, also. Any opinions?
> 
>>> 4. What network transport does this thing use? TCP? UDP? What port numbers?
>>>
>> DSTM uses TCP communication. It searches dynamically for available ports 
>> starting at port 60001, using 6 for the name server. If two nodes are 
>> running each on a separate machine with a different IP address, chances are 
>> that both use the same port 60001. If they run on the same machine, most 
>> likely one will use port 60001 and the other 60002.
>>  
> 
> Right. So both the nameserver and any clients run on random port numbers? 
> (Begs the question of how the clients figure out which port a remote 
> nameserver is on...)
Well, not quite. The name server gets a fixed 6 to make it accessible 
statically, the others may vary. Their dynamic address is used to label the 
TVars which then always carry their correct address.
> 
>>> 5. How does it work? Does it spawn a Haskell thread for each machine 
>>> connection or something?
>>>
>> Each node spawns a Haskell thread listening to its designated port and 
>> spawning itself a thread for each accepted TCP communication, i.e. one for 
>> each foreign node talking to it. Each such thread implements a communication 
>> line between two threads. I have tried several communication line schemas 
>> which I will describe in more detail in the paper yet to come...
>>  
> 
> What impact (if any) does threaded vs non-threaded RTS have?
I have done a few tests with threads and could not find a significant 
difference. But I really did not look deep and thorough enough into it to give 
a qualified answer.
> 
> ___
> 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] real-time audio processing [Was: can Haskell do everyting as we want?]

2010-08-04 Thread Stephen Sinclair
On Aug 3, 8:31 pm, Jeremy Shaw  wrote:
>  The only area I have had any trouble with Haskell is doing realtime
> music synthesis. And only because the garbage collector is not
> realtime friendly. That is not unfixable though. However, I am
> thinking that the best way to do realtime synthesis with Haskell is to
> use it to create a DSL that uses LLVM to create code at runtime so
> that the realtime code is outside the scope of the normal RTS and
> garbage collector.

I'm also very interested in this topic---how to apply a general-
purpose functional language to real-time needs, even if it is in a
domain-specific way.

Indeed, it mostly comes down to memory management and the fact that
functional concepts like closures and laziness require a lot of
dynamic allocation and garbage collection.  Certainly, one solution is
to provide a real-time-friendly memory manager.

However, it's interesting to notice that, as proven by FAUST [1], a
huge amount of DSP algorithms can be expressed functionally in a real-
time-compatible way by describing them as static diagrams of connected
blocks.  These can be efficiently compiled to imperative code with no
dynamic memory allocation required.

So yes, if such a language were available as an embedded DSL in
Haskell (one effort can be found here [2]), it could be generated at
run-time using LLVM and called out to.  Alternatively, it would be
very cool if it were possible to generate code statically at compile
time, just like in FAUST.  I can imagine this being very useful,
especially if it could be generalized to operate on datatypes other
than floating points, and had easy access to data structures provided
by non-RT portions of the code.  If there are mutability requirements,
it could be made to run in the ST monad with a pre-allocated
workspace.

Of course _modifying_ such structures at run-time is always a dynamic
thing by definition, although there is the possibility of dynamically
generating a replacement block diagram while an one existing one runs,
and using an atomic pointer swap to switch them without causing
interruptions.

In any case, as far as I know the only thing in the way is that it's
impossible to tell GHC to compile a section of code in such as way as
to guarantee avoidance of memory management.  Compilers and runtime-
systems always seem to be either RT- or non-RT-friendly, but never
seem to support the idea of code *portions* that have differing
requirements.  My point is, RT code _can_ be expressed functionally,
even if the RT-ness imposes certain expressivity restrictions.  It
would be very cool to be able to mark sections of code as following
such a "sub-language" and be guaranteed that the compiler will
generate GC-free code for a particular function, if possible, or
otherwise fail.

Even if such a sub-language were no more expressive than C, it would
be nice to be able to write it in Haskell instead of dropping down to
C, so that data can be easily shared with non-RT parts, and Haskell's
type checker could be exploited.  It seems strange to me that with
technology like Haskell and GHC we still depend on using C to express
these last remaining droplets of real-time determinism requirements---
strange, since I think of higher-level languages like Haskell to be
supersets of the capabilities of C---and annoying, because it means
having to deal with the complexities of language interoperability,
just for a few low-level components of an application.

I realize some of this has probably been discussed in conjunction with
FRP.  I'm aware of one paper on RT-FRP that talks about requiring an
RT-friendly sub-language [3], but I don't pretend to follow it
completely.  I'm almost sure it also has something to do with arrows,
but I have very little idea what they are, since I'm still just
"getting" monads at this point in my personal Haskell understanding.
I hope someone more knowledgeable about these things on this list
might be able to comment on their relation to real-time determinism.

[1] http://faust.grame.fr/
[2] http://claudiusmaximus.goto10.org/cm/2009-12-04_heist_dataflow_algebra.html
[3] http://www.haskell.org/frp/rt-frp.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] can Haskell do everyting as we want?

2010-08-04 Thread Jason Dagit
On Wed, Aug 4, 2010 at 3:37 AM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> Marc Weber  writes:
>
> > Hi Qi,
> >
> > have a look at brainfuck language. Its turing complete as Python,
> Haskell, etc
> > are. Then you'll learn that the quesntion "Can I do everything possible"
> > is not at all important. You have to ask instead:  Can I complete my
> > task in reasonable time and with reasonable runtime performance etc.
>
> And in a way that makes the code maintainable.
>
> >   For most use cases Haskell is a good choice - the only real things
> > I'm missing are
> > - nice stack traces
> > - completion support - because I find it relaxing not having to looking
> >   all names. This could be fixed to some extend though..
>
> If you mean whilst writing your code, this is an editor issue (I believe
> scion aims to help writing cross-editor utilities for things like
> this).  ghci also has tab-completion, and ghc-mod provides such
> functionality in Emacs.
>

Is scion still being developed?  I have the impression it's dead now. Really
a shame, I think it has a good solid design and just needs work/polish.

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


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Job Vranish
Both Git and GitHub are fantastic. (and very convenient for contributors)

Also if you're the kind of person who's into GUI's, SmartGit is quite good
as well.

- Job

On Wed, Aug 4, 2010 at 3:28 PM, Frank Kupke wrote:

> John,
>
> a very nice idea. I have not worked with git yet but used an svn repository
> on our institute server. I will look into it though and eventually set
> something up. In the meantime you are welcome to send patches to me for
> merging them into the project.
>
> Frank
>
> Am 04.08.2010 um 18:54 schrieb John Van Enk:
>
> Is there a Git/Darcs dev repo hiding anywhere we could submit patches to?
>
> On Tue, Aug 3, 2010 at 4:35 AM, Frank Kupke 
> wrote:
>
>> Hi,
>>
>> DSTM is an implementation of a robust distributed Software Transactional 
>> Memory (STM) library for Haskell. Many real-life applications are 
>> distributed by nature. Concurrent applications may profit from robustness 
>> added by re-implementation as distributed applications. DSTM extends the STM 
>> abstraction to distributed systems and presents an implementation efficient 
>> enough to be used in soft real-time applications. Further, the implemented 
>> library is robust in itself, offering the application developer a high 
>> abstraction level to realize robustness, hence, significantly simplifying 
>> this, in general, complex task.
>>
>> The DSTM package consists of the DSTM library, a name server application, 
>> and three sample distributed programs using the library. Provided are a 
>> simple Dining Philosophers, a Chat, and a soft real-time Bomberman game 
>> application. Distributed communication is transparent to the application 
>> programmer. The application designer uses a very simple name server 
>> mechanism to set up the system. The DSTM library includes the management of 
>> unavailable process nodes and provides the application with abstract error 
>> information thus facilitating the implementation of robust distributed 
>> application programs.
>>
>> For usage please look into the documentation file: DSTMManual.pdf.
>>
>> The package including the documentation can be found 
>> on:http://hackage.haskell.org/package/DSTM-0.1.1
>>
>>
>> Best regards,
>> Frank Kupke
>>
>>
>>
>> ___
>> 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] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Frank Kupke
John,

a very nice idea. I have not worked with git yet but used an svn repository on 
our institute server. I will look into it though and eventually set something 
up. In the meantime you are welcome to send patches to me for merging them into 
the project.

Frank

Am 04.08.2010 um 18:54 schrieb John Van Enk:

> Is there a Git/Darcs dev repo hiding anywhere we could submit patches to?
> 
> On Tue, Aug 3, 2010 at 4:35 AM, Frank Kupke  
> wrote:
> Hi,
> DSTM is an implementation of a robust distributed Software Transactional 
> Memory (STM) library for Haskell. Many real-life applications are distributed 
> by nature. Concurrent applications may profit from robustness added by 
> re-implementation as distributed applications. DSTM extends the STM 
> abstraction to distributed systems and presents an implementation efficient 
> enough to be used in soft real-time applications. Further, the implemented 
> library is robust in itself, offering the application developer a high 
> abstraction level to realize robustness, hence, significantly simplifying 
> this, in general, complex task.
> The DSTM package consists of the DSTM library, a name server application, and 
> three sample distributed programs using the library. Provided are a simple 
> Dining Philosophers, a Chat, and a soft real-time Bomberman game application. 
> Distributed communication is transparent to the application programmer. The 
> application designer uses a very simple name server mechanism to set up the 
> system. The DSTM library includes the management of unavailable process nodes 
> and provides the application with abstract error information thus 
> facilitating the implementation of robust distributed application programs.
> For usage please look into the documentation file: DSTMManual.pdf.
> 
> The package including the documentation can be found on:
> http://hackage.haskell.org/package/DSTM-0.1.1
> 
> Best regards,
> Frank Kupke
> 
> 
> ___
> 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] Preview the new haddock look and take a short survey

2010-08-04 Thread Albert Y. C. Lai

On 10-08-04 01:00 AM, Mark Lentczner wrote:

Sample pages:  http://www.ozonehouse.com/mark/snap-xhtml/index.html


On the Contents page, among the collapsable trees: when I click on a 
link that is also a parent, such as Snap.Http.Server and 
Text.Templating.Heist, it has the undesirable side effect of collapsing 
the subtree (or expanding the subtree). (Firefox 3.6.8 as provided by 
current Ubuntu 32-bit.)


When I click on a link, my intention --- and I'm sure most people's 
intention too --- is to jump to the linked page only. No side effects 
unrelated to the jump. No messing with the tree state.


Another thing. In Safari in iOS 4 in iPod Touch 2nd generation, when a 
tree is collapsed, the [+] doesn't show.


(Haha I'm an impossible reviewer. iPod Touch?!)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why is toRational a method of Real?

2010-08-04 Thread Alexander Solla


On Aug 4, 2010, at 11:30 AM, Omari Norman wrote:

Why is toRational a method of Real? I thought that real numbers need  
not
be rational, such as the square root of two. Wouldn't it make more  
sense

to have some sort of Rational typeclass with this method? Thanks.


You can't build the real number field using a computer.  So you have  
to turn what "should" be a real into something you can express on a  
computer.  You can either choose to use the field of "computable real  
numbers", which is slow, or you can just go with a "near enough"  
rational approximation.

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


[Haskell-cafe] Why is toRational a method of Real?

2010-08-04 Thread Omari Norman
Why is toRational a method of Real? I thought that real numbers need not
be rational, such as the square root of two. Wouldn't it make more sense
to have some sort of Rational typeclass with this method? Thanks.
--Omari

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


Re: [Haskell-cafe] ANNOUNCE: hierarchical-clustering and gsc-weighting

2010-08-04 Thread Felipe Lessa
On Tue, Aug 3, 2010 at 8:23 AM, Felipe Lessa  wrote:
> On Tue, Aug 3, 2010 at 8:01 AM, Ivan Lazar Miljenovic
>  wrote:
>> Felipe Lessa  writes:
>>> 'hierarchical-clustering' provides a function to create a dendrogram
>>> from a list of items and a distance function between them.  The most
>>> common linkage types are available: single linkage, complete linkage
>>> and UPGMA.  An item can be anything, for example a DNA sequence, so
>>> this may used to create a phylogenetic tree.
>>
>> What actual clustering algorithm are you using here?
>
> A naïve O(n^2) algorithm using a distance matrix.  This can be
> improved without changing the API, however.

What a blunder!  I mean, an O(n^3) algorithm -- each step takes
O(n^2), and you need 'n' steps to create the whole dendrogram.

I'll fix the documentation on the next release.

Cheers! =)

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


Re: [Haskell-cafe] what's the best environment for haskell work?

2010-08-04 Thread Hamish Mackenzie
On 5 Aug 2010, at 06:10, aditya siram wrote:

> This is slightly OT, but is there a way of getting some Emacs keybindings in 
> Leksah?

You can add them to the keymap.lkshk, but you will be limited to adding things 
leksah has commands for.  If you do make some bindings please share them.

We are working on integrating Yi as our editor instead of GtkSourceView and it 
has emacs keybindings.  This integration is still in the early stages and I 
would not recommend trying to use it yet (unless you happen to have time to 
help out).

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


Re: [Haskell-cafe] what's the best environment for haskell work?

2010-08-04 Thread aditya siram
This is slightly OT, but is there a way of getting some Emacs keybindings in
Leksah?

-deech

On Wed, Aug 4, 2010 at 1:01 PM, Hamish Mackenzie <
hamish.k.macken...@googlemail.com> wrote:

> I use Leksah and have done since I started contributing to it.  The best
> way to make it work for you is to use Leksah to fix what you don't like
> about Leksah ;-)  Failing that giving good feedback about bugs and missing
> features is the next best thing.
>
> On 3 Aug 2010, at 18:48, David Virebayre wrote:
> > Trying code completion in comments on string constants, for example.
> > Code completion makes the text jump if you're editing near the bottom
> > of the editor area.
>
> You could turn on Edit Prefs -> GUI Options -> Complete only on Hotkey
>
> Default hotkey is Ctrl+Space
>
> > I like the "tocandy" feature but then it breaks alignment if you open
> > the file in another editor. Something probably fixable by editing the
> > candy file.
>
> Just out of interest which of the candy replacements caused problems.  Some
> of them (such as ->) already are set to include spaces to pad out
> differences.
>
> You can turn candy off by unchecking Configuration -> To Candy
>
> Does your existing editor handle candy better? If so how?
>
> > I'am a bit lost between Workspace and Package, especially when all I
> > want is write a quick single-source haskell program.
>
> We are planning to improve this by adding a default workspace and/or adding
> messages to prompt users if they have not got a workspace or package open.
>
> Basically to get started on a app
>  Workspace -> New Workspace (this file contains a list of packages to open)
>
> I think most users probably only ever need one workspace file.
>
> Next if you have a .cabal file already...
>  Panes -> Workspace (to show the workspace pane)
>  Right click in the workspace Pane and select Add Package
>
> Or if you want to create a new package...
>  Package -> New Package
>  Select a folder whose name matches the desired project name
>  If you just click Save down the bottom you will get a very
>basic executable package with a Main module (but no main function)
>
> To switch between packages in your workspace just double click on it in the
> Workspace pane.
>
> > That's all I can think of right now, I've exagerated a bit when I said
> > "unusable". Leksah is going to be an awesome editor, it's just not
> > ready yet for me.
>
> Thanks for the feedback, please let us know if you think of anything else.
>
> As well as the google forum we now also have #leksah on IRC.
>
> Hamish___
> 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] what's the best environment for haskell work?

2010-08-04 Thread Hamish Mackenzie
I use Leksah and have done since I started contributing to it.  The best way to 
make it work for you is to use Leksah to fix what you don't like about Leksah 
;-)  Failing that giving good feedback about bugs and missing features is the 
next best thing. 

On 3 Aug 2010, at 18:48, David Virebayre wrote:
> Trying code completion in comments on string constants, for example.
> Code completion makes the text jump if you're editing near the bottom
> of the editor area.

You could turn on Edit Prefs -> GUI Options -> Complete only on Hotkey 

Default hotkey is Ctrl+Space

> I like the "tocandy" feature but then it breaks alignment if you open
> the file in another editor. Something probably fixable by editing the
> candy file.

Just out of interest which of the candy replacements caused problems.  Some of 
them (such as ->) already are set to include spaces to pad out differences.

You can turn candy off by unchecking Configuration -> To Candy

Does your existing editor handle candy better? If so how?

> I'am a bit lost between Workspace and Package, especially when all I
> want is write a quick single-source haskell program.

We are planning to improve this by adding a default workspace and/or adding 
messages to prompt users if they have not got a workspace or package open.

Basically to get started on a app
  Workspace -> New Workspace (this file contains a list of packages to open)

I think most users probably only ever need one workspace file.

Next if you have a .cabal file already...
  Panes -> Workspace (to show the workspace pane)
  Right click in the workspace Pane and select Add Package

Or if you want to create a new package...
  Package -> New Package
  Select a folder whose name matches the desired project name
  If you just click Save down the bottom you will get a very
basic executable package with a Main module (but no main function)

To switch between packages in your workspace just double click on it in the 
Workspace pane.

> That's all I can think of right now, I've exagerated a bit when I said
> "unusable". Leksah is going to be an awesome editor, it's just not
> ready yet for me.

Thanks for the feedback, please let us know if you think of anything else.

As well as the google forum we now also have #leksah on IRC.

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


Re: [Haskell-cafe] Maybe to Either -- is there a better way?

2010-08-04 Thread Christopher Done
On 4 August 2010 18:40, Alexander Dunlap  wrote:
> It's also nice for people reading code if common functions are
> functions from common libraries. This allows readers' "vocabulary" of
> common functions to increase, so they don't have to trawl through
> someone's personal "utility" library to figure out what each utility
> function does.
>

Agreed. That's why I like readMay. There are many ways to write a reads wrapper:

case reads str of [(x,_)] -> Just x; _ -> Nothing

vs

case reads str of [(x,"")] -> Just x; _ -> Nothing -- stricter

Etc. It seems everyone defines their one, where as Safe.readMay is
common. There could be others defined in Safe that encompass most
cases.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Janis Voigtländer

Nicolas Pouillard schrieb:

Right let's make it more explicit, I actually just wrote a Control.Seq
module and a test file:

module Control.Seq where
  genericSeq :: Typeable a => a -> b -> b
  genericSeq = Prelude.seq

  class Seq a where

seq :: a -> b -> b

  instance (Typeable a, Typeable b) => Seq (a -> b) where
seq = genericSeq

  ... Other seq instances ...

$ cat test.hs
import Prelude hiding (seq)
import Data.Function (fix)
import Control.Seq (Seq(seq))
import Data.Typeable

...

foldl''' :: (Typeable a, Typeable b) => (a -> b -> a) -> a -> [b] -> a
-- GHC infer this one
-- foldl''' :: Seq (a -> b -> a) => (a -> b -> a) -> a -> [b] -> a
-- however this one require FlexibleContext, and the first one is accepted.
foldl''' c = seq c (fix (\h n ys -> case ys of
  [] -> n
  x : xs -> let n' = c n x in h n' xs))


Well, in this example you were lucky that the function type on which you
use seq involves some type variables. But consider this example:

f :: (Int -> Int) -> a -> a
f h x = seq h x

I think with your definitions that function will really have that type,
without any type class constraints on anything.

So let us derive the free theorem for that type. It is:

forall t1,t2 in TYPES, g :: t1 -> t2, g strict.
 forall p :: Int -> Int.
  forall q :: Int -> Int.
   (forall x :: Int. p x = q x)
   ==> (forall y :: t1. g (f p y) = f q (g y))

Now, set

p :: Int -> Int
p = undefined

q :: Int -> Int
q _ = undefined

Clearly, forall x :: Int. p x = q x holds.

So it should be the case that for every strict function g and
type-appropriate input y it holds:

  g (f p y) = f q (g y)

But clearly the left-hand side is undefined (due to strictness of g and
f p y = f undefined y = seq undefined y), while the right-hand side is
not necessarily so (due to f q (g y) = f (\_ -> undefined) (g y) = seq
(\_ -> undefined) (g y) = g y).

So you have claimed that by using seq via genericSeq in the above
definition of f you are guaranteed that any free theorem you derive from
its type is correct. But as you see above it is not!

I think you have to face it: if you want a solution that both gives
meaningful free theorems and still allows to write all programs
involving seq that you can currently write in Haskell, then using type
classes is not the answer.

Ciao,
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


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Christopher Done
On 4 August 2010 10:43, Chris Eidhof  wrote:
> This looks very cool! It would be nice to put the pdf online somewhere, and 
> add a link from the package documentation

Regarding that, it would be nice if Hackage let you access the files
in the package instead of having to extract the .tar.gz, as in this
case the PDF is in the package; it makes sense to make it clickable
somewhere on the package page.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Software architecture

2010-08-04 Thread Christopher Done
This came up a month or so ago, Don Stewart and others overviewed this
topic in detail:

http://www.haskell.org/pipermail/haskell-cafe/2010-May/077154.html

On 4 August 2010 13:07, Charles-Pierre Astolfi  wrote:
> Hey there,
>
> I'm searching for software designs in Haskell ; for example, I have a
> pretty good ideo of how I would arrange my modules/classes (in
> ocaml/(java/c++)) and how they would all fit together to create, say,
> a website aspirator. But I don't have any clue of the right way to do
> it with Haskell.
>
> I don't need a solution for this example, I'd just like to see how to
> manage non-trivial code. I haven't found any pointers on the
> interwebs.
>
> On an unrelated note, what is the simplest way to get the llvm
> bitcode? I understand I can compile myself ghc but it there an easier
> way?
>
> Thanks a lot!
> --
> Cp
> ___
> 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: Laziness question

2010-08-04 Thread Nicolas Pouillard
On Wed, 04 Aug 2010 18:04:13 +0200, Janis Voigtländer 
 wrote:
> Nicolas Pouillard schrieb:
> > On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer 
> >  wrote:
> >> Nicolas Pouillard schrieb:
> >>> On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer 
> >>>  wrote:
>  Nicolas Pouillard schrieb:
> > However the rule is still the same when using an unsafe function you 
> > are on
> > your own.
> >
> > Clearer?
>  Almost. What I am missing is whether or not you would then consider your
>  genericSeq (which is applicable to functions) one of those "unsafe
>  functions" or not.
> >>> I would consider it as a safe function.
> >> Well, then I fear you have come full-circle back to a non-solution. It
> >> is not safe:
> > 
> > I feared a bit... but no
> > 
> >> Consider the example foldl''' from our paper, and replace seq therein by
> >> your genericSeq. Then the function will have the same type as the
> >> original foldl, but the standard free theorem for foldl does not hold
> >> for foldl''' (as also shown in the paper).
> > 
> > So foldl''' now has some Typeable constraints.
> 
> No, I don't see how it has that. Or maybe you should make explicit under
> what conditions a type (a -> b) is in Typeable. What exactly will the
> type of foldl''' be, and why?

Right let's make it more explicit, I actually just wrote a Control.Seq
module and a test file:

module Control.Seq where
  genericSeq :: Typeable a => a -> b -> b
  genericSeq = Prelude.seq

  class Seq a where
seq :: a -> b -> b

  instance (Typeable a, Typeable b) => Seq (a -> b) where
seq = genericSeq

  ... Other seq instances ...

$ cat test.hs
import Prelude hiding (seq)
import Data.Function (fix)
import Control.Seq (Seq(seq))
import Data.Typeable

foldl :: (a -> b -> a) -> a -> [b] -> a
foldl c = fix (\h n ys -> case ys of
[] -> n
x : xs -> let n' = c n x in h n' xs)

foldl' :: Seq a => (a -> b -> a) -> a -> [b] -> a
foldl' c = fix (\h n ys -> case ys of
[] -> n
x : xs -> let n' = c n x in seq n' (h n' xs))

foldl'' :: (Typeable a, Typeable b, Seq b) => (a -> b -> a) -> a -> [b] -> a
foldl'' c = fix (\h n ys -> seq (c n) (case ys of
 [] -> n
 x : xs -> seq xs (seq x
 (let n' = c n x in h n' 
xs

foldl''' :: (Typeable a, Typeable b) => (a -> b -> a) -> a -> [b] -> a
-- GHC infer this one
-- foldl''' :: Seq (a -> b -> a) => (a -> b -> a) -> a -> [b] -> a
-- however this one require FlexibleContext, and the first one is accepted.
foldl''' c = seq c (fix (\h n ys -> case ys of
  [] -> n
  x : xs -> let n' = c n x in h n' xs))

Best regards,

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


[Haskell-cafe] Re: Software architecture

2010-08-04 Thread Ertugrul Soeylemez
Ertugrul Soeylemez  wrote:

>   forkIO . forever $ takeMVar logVar >>= hPutStrLn stderr

hPutStrLn should become hPutStr, otherwise the output may look
strange. =)


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/


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


[Haskell-cafe] Re: Software architecture

2010-08-04 Thread Ertugrul Soeylemez
Charles-Pierre Astolfi  wrote:

> I'm searching for software designs in Haskell ; for example, I have a
> pretty good ideo of how I would arrange my modules/classes (in
> ocaml/(java/c++)) and how they would all fit together to create, say,
> a website aspirator. But I don't have any clue of the right way to do
> it with Haskell.
>
> I don't need a solution for this example, I'd just like to see how to
> manage non-trivial code. I haven't found any pointers on the
> interwebs.

This really depends on the concept you use to solve your problem.  In
most programming languages the glue is ready-made and tells you, how to
structure your program.  In Haskell you make your own glue.

For example, I use monads heavily and the logical parts of my program
are monad transformers.  The program itself is the stack of those.
Using type classes the individual transformers can communicate with each
other:

  newtype GameT m a= GT (StateT GameConfig m a)
  newtype TextureT m a = TT (StateT TextureConfig m a)
  newtype OpenGLT m a  = GLT (IdentityT m a)
  newtype SDLT m a = SDLT (ReaderT SDLConfig m a)

  type MyAppT = GameT (TextureT (OpenGLT SDLT))

  game :: MyAppT IO ()

Another important type of glue in modern software programming is
concurrency.  Split your program into a number of subprograms (threads).
This is very well supported in Haskell:

  logVar <- newEmptyMVar
  let logStr   = putMVar logVar
  let logStrLn = putMVar logVar >=> const (putChar '\n')

  forkIO . forever $ takeMVar logVar >>= hPutStrLn stderr

When using other concepts, usually by using a library, use the glue of
that particular concept/library.  For example, if you use Yampa to model
a reactive system, your individual program parts could become signal
transformers:

  fire :: SF Particle Particle
  snow :: SF Particle Particle

If your current problem is a Parser, your split it into subparsers.  For
example to parse HTML you definitely want to parse tags and entities.
To parse tags you want to parse attribute/value pairs.  Use the
composability features of monads to do this:

  tag   :: Parser Tag
  attribute :: Parser (ByteString, ByteString)
  entity:: Parser Entity

The possibilities are endless.  You get the idea when writing actual
applications.


Greets,
Ertugrul


-- 
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/


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


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Bradford Larsen
On Wed, Aug 4, 2010 at 1:00 AM, Mark Lentczner  wrote:
> The Haddock team has spent the last few months revamping the look of the 
> generated output. We're pretty close to done, but we'd like to get the 
> community's input before we put it in the main release.
>
> Please take a look, and then give us your feedback through a short survey
>
> Sample pages:  http://www.ozonehouse.com/mark/snap-xhtml/index.html
> Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html
>
> Survey:
>        
> http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ
> Short link to same survey:
>        http://bit.ly/9Zvs9B
>
> Thanks!
>
>        - Mark
>
> Mark Lentczner
> http://www.ozonehouse.com/mark/
> irc: MtnViewMark

The index page is not rendered properly on Firefox 3.0.18 on 64-bit
Ubuntu:  .  Note that the package name a
module comes from is not aligned with the module.

The synopsis pull-out box is also not rendered properly:
.  The `Synopsis' tab is raised an inch
or so above the box, long type signatures are truncated, and the
nested scroll bar is obscured.  I also really dislike nested scroll
bars in web pages.

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


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Ben
Great work!

I'm sure you're already aware of

http://sphinx.pocoo.org/

which is used to generate the Python docs.  A lot of good ideas there.
 One thing which would be great would be to integrate their javascript
in-browser text search engine.  Obviously not a priority but it might
be nice.

Best, B

> Message: 14
> Date: Wed, 4 Aug 2010 15:56:58 +0100
> From: Thomas Schilling 
> Subject: Re: [Haskell-cafe] Preview the new haddock look and take a
>        short   survey
> To: aditya siram 
> Cc: haddock , haskell-cafe@haskell.org
> Message-ID:
>        
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 4 August 2010 15:44, aditya siram  wrote:
>> I really like the color scheme and the Javadoc looking frames.
>>
>> One suggestion I can make is to have the index show all the functions with
>> type signatures without having to pick a letter. A lot of times I'll be
>> looking for a function of a certain signature as opposed to a name. Indeed
>> an index of type signatures would great! I remember wishing I had this when
>> trying the understand the Parsec package.
>>
>> -deech
>
> Wouldn't hoogle be better for this kind of use case?  The index can
> become very large already.
>
> More direct hoogle/hayoo integration (at least on Hackage) sounds like
> a worthwhile goal, though.  Noted.
>
>>
>> On Wed, Aug 4, 2010 at 8:55 AM, Yitzchak Gale  wrote:
>>>
>>> Mark Lentczner wrote:
>>> > The Haddock team...
>>> > Please take a look, and then give us your feedback
>>>
>>> Very very nice. I took the survey, but here are some comments
>>> I left out.
>>>
>>> I like the idea of the Snappy style the best, but there are two
>>> serious problems with it, at least in my browser (Safari):
>>>
>>> 1. The black on dark blue of the "Snap Packages" title makes it
>>> nearly unreadable for me.
>>> 2. The wide fonts stretch things out so far on my screen that the
>>> page becomes almost unusable.
>>>
>>> The other styles are fine, I would use them instead.
>>>
>>> Here is a comment I'll repeat from the survey because of its
>>> importance: Please add a "collapse all" button for the tree on
>>> the contents page. For me, that is perhaps the most urgent
>>> thing missing in all of Haddock. It would make that tree so
>>> much more usable.
>>>
>>> Thanks for the great work,
>>> Yitz
>>> ___
>>> 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
>>
>>
>
>
>
> --
> If it looks like a duck, and quacks like a duck, we have at least to
> consider the possibility that we have a small aquatic bird of the
> family Anatidae on our hands.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Maybe to Either -- is there a better way?

2010-08-04 Thread Max Rabkin
On Tue, Aug 3, 2010 at 8:33 PM, Claude Heiland-Allen
 wrote:
> {-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}
> import Language.Haskell.Djinn (djinnD)
> $(djinnD "maybeToEither" [t|forall a b . a -> Maybe b ->  Either a b|])
> main = print . map (maybeToEither "foo") $ [Nothing, Just "bar"]

This is very cool (as is Djinn itself), but for me the ideal syntax would be

maybeToEither :: a -> Maybe b -> Either a b
maybeToEither = $(derived)

Is something like this possible in TH? The splice would have to know
its declared (even inferred?) type.

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


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread John Van Enk
Is there a Git/Darcs dev repo hiding anywhere we could submit patches to?

On Tue, Aug 3, 2010 at 4:35 AM, Frank Kupke wrote:

> Hi,
>
> DSTM is an implementation of a robust distributed Software Transactional 
> Memory (STM) library for Haskell. Many real-life applications are distributed 
> by nature. Concurrent applications may profit from robustness added by 
> re-implementation as distributed applications. DSTM extends the STM 
> abstraction to distributed systems and presents an implementation efficient 
> enough to be used in soft real-time applications. Further, the implemented 
> library is robust in itself, offering the application developer a high 
> abstraction level to realize robustness, hence, significantly simplifying 
> this, in general, complex task.
>
> The DSTM package consists of the DSTM library, a name server application, and 
> three sample distributed programs using the library. Provided are a simple 
> Dining Philosophers, a Chat, and a soft real-time Bomberman game application. 
> Distributed communication is transparent to the application programmer. The 
> application designer uses a very simple name server mechanism to set up the 
> system. The DSTM library includes the management of unavailable process nodes 
> and provides the application with abstract error information thus 
> facilitating the implementation of robust distributed application programs.
>
> For usage please look into the documentation file: DSTMManual.pdf.
>
> The package including the documentation can be found 
> on:http://hackage.haskell.org/package/DSTM-0.1.1
>
>
> Best regards,
> Frank Kupke
>
>
>
> ___
> 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] Maybe to Either -- is there a better way?

2010-08-04 Thread Alexander Dunlap
On Wed, Aug 4, 2010 at 9:21 AM, Henning Thielemann
 wrote:
> Ivan Lazar Miljenovic schrieb:
>> Yitzchak Gale  writes:
>
>>> While useful, I think its ubiquity to simplicity ratio is not
>>> high enough to justify either depending on MissingH
>>> just for that, or adding it to a base library.
>>
>> Just like the swap :: (a,b) -> (b,a) function a lot of people were
>> discussing on librar...@?
>
> I have 'swap' in my utility-ht.
>
>> In general, I agree.
>
> Problem in Haskell is, that it allows for a high degree of
> modularization such that most components become trivial. Does that mean
> that we should not define simple functions at all, which in the extreme
> case would mean that we inline all potential function calls?
>

It's also nice for people reading code if common functions are
functions from common libraries. This allows readers' "vocabulary" of
common functions to increase, so they don't have to trawl through
someone's personal "utility" library to figure out what each utility
function does.

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


Re: [Haskell-cafe] Maybe to Either -- is there a better way?

2010-08-04 Thread Henning Thielemann
Ivan Lazar Miljenovic schrieb:
> Yitzchak Gale  writes:

>> While useful, I think its ubiquity to simplicity ratio is not
>> high enough to justify either depending on MissingH
>> just for that, or adding it to a base library.
> 
> Just like the swap :: (a,b) -> (b,a) function a lot of people were
> discussing on librar...@?

I have 'swap' in my utility-ht.

> In general, I agree.

Problem in Haskell is, that it allows for a high degree of
modularization such that most components become trivial. Does that mean
that we should not define simple functions at all, which in the extreme
case would mean that we inline all potential function calls?

I think converting Maybe to Either is an often repeating task which
justifies an individual function. Maybe I add it to utility-ht.

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


[Haskell-cafe] Haskell Platform OPENGL dependencies

2010-08-04 Thread aditya siram
Hi folks,
I just installed the latest Haskell Platform on a fresh Ubuntu Lucid machine
and I had to install the following packages to satisfy Open GL:
libgmp3-dev,libgl1-mesa-dev, libglu1-mesa-dev, freeglut3-dev

Just thought you might want to document that on the Haskell Platform page.
-deech
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Janis Voigtländer

Nicolas Pouillard schrieb:

On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer 
 wrote:

Nicolas Pouillard schrieb:

On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer 
 wrote:

Nicolas Pouillard schrieb:

However the rule is still the same when using an unsafe function you are on
your own.

Clearer?

Almost. What I am missing is whether or not you would then consider your
genericSeq (which is applicable to functions) one of those "unsafe
functions" or not.

I would consider it as a safe function.

Well, then I fear you have come full-circle back to a non-solution. It
is not safe:


I feared a bit... but no


Consider the example foldl''' from our paper, and replace seq therein by
your genericSeq. Then the function will have the same type as the
original foldl, but the standard free theorem for foldl does not hold
for foldl''' (as also shown in the paper).


So foldl''' now has some Typeable constraints.


No, I don't see how it has that. Or maybe you should make explicit under
what conditions a type (a -> b) is in Typeable. What exactly will the
type of foldl''' be, and why?

Ciao,
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


Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Nicolas Pouillard
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer 
 wrote:
> Nicolas Pouillard schrieb:
> > On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer 
> >  wrote:
> >> Nicolas Pouillard schrieb:
> >>> However the rule is still the same when using an unsafe function you are 
> >>> on
> >>> your own.
> >>>
> >>> Clearer?
> >> Almost. What I am missing is whether or not you would then consider your
> >> genericSeq (which is applicable to functions) one of those "unsafe
> >> functions" or not.
> > 
> > I would consider it as a safe function.
> 
> Well, then I fear you have come full-circle back to a non-solution. It
> is not safe:

I feared a bit... but no

>
> Consider the example foldl''' from our paper, and replace seq therein by
> your genericSeq. Then the function will have the same type as the
> original foldl, but the standard free theorem for foldl does not hold
> for foldl''' (as also shown in the paper).

So foldl''' now has some Typeable constraints.

I agree that the free theorem for foldl does not hold for foldl'''.

However can we derive the free theorem by looking at the type? No because
of the Typeable constraint.

So it is safe to derive free theorems without looking at the usage of seq,
just the type of the function. Taking care of not considering parametric
a type constrained by Typeable.

Finally the difference between your solution and this one is that fewer
(valid) free theorems can be derived (because of the Typable constraints
introduced by seq on functions). Still it is a solution since we no longer
have to fear the usage of seq when deriving a free theorem.

Best regards,

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


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Andrew Coppin

Frank Kupke wrote:

Good questions. I am about to write a paper explaining the design of the DSTM 
library in more detail which I will link when available. Please bear with me, 
here. In the meantime please find some shorter answers below.
  


Well, that was pretty comprehensive. A few questions remain...


- If the failure comes up *before* the transaction has been validated ok, it is 
aborted.


Right. So the transaction rolls back and the application gets an exception?


- If the failure comes up *after* the transaction has been validated ok, it is 
committed.
  


So if a TVar goes walkabout in the split second between validate and 
commit, the others commit anyway, and then the application gets an 
exception?


In that case, is there a way to determine whether or not the rest of the 
transaction completed? Because it looks like you can the same exception 
either way, regardless of whether a commit happened or not.



4. What network transport does this thing use? TCP? UDP? What port numbers?


DSTM uses TCP communication. It searches dynamically for available ports 
starting at port 60001, using 6 for the name server. If two nodes are 
running each on a separate machine with a different IP address, chances are 
that both use the same port 60001. If they run on the same machine, most likely 
one will use port 60001 and the other 60002.
  


Right. So both the nameserver and any clients run on random port 
numbers? (Begs the question of how the clients figure out which port a 
remote nameserver is on...)



5. How does it work? Does it spawn a Haskell thread for each machine connection 
or something?


Each node spawns a Haskell thread listening to its designated port and spawning 
itself a thread for each accepted TCP communication, i.e. one for each foreign 
node talking to it. Each such thread implements a communication line between 
two threads. I have tried several communication line schemas which I will 
describe in more detail in the paper yet to come...
  


What impact (if any) does threaded vs non-threaded RTS have?

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


Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Janis Voigtländer

Nicolas Pouillard schrieb:

On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer 
 wrote:

Nicolas Pouillard schrieb:

However the rule is still the same when using an unsafe function you are on
your own.

Clearer?

Almost. What I am missing is whether or not you would then consider your
genericSeq (which is applicable to functions) one of those "unsafe
functions" or not.


I would consider it as a safe function.


Well, then I fear you have come full-circle back to a non-solution. It
is not safe:

Consider the example foldl''' from our paper, and replace seq therein by
your genericSeq. Then the function will have the same type as the
original foldl, but the standard free theorem for foldl does not hold
for foldl''' (as also shown in the paper).

Ciao,
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


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Evan Laforge
This is something I've wanted for a long time, but I always intended
to just submit a patch since it would be trivial, but maybe other
people have an opinion about it too:

I've always wanted a button to collapse or maybe toggle all expanded
branches.  Once a library gets large, it's easier to navigate when
things are closed by default.  I used to have to re-close giant things
I didn't care about, like the open gl modules, all the time.  And if I
hit the back button to go back to the toc, it's forgotten which
branches I had closed.  Of course, since the stdlib has been broken up
a lot this is less of a problem than it used to be, but as my own
project gets bigger it's since become a problem there.

In fact, without an easy way of closing everything, the fact that
sub-packages are collapsable at all doesn't seem very useful, unless
you use frame view and keep the page open for a long time.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Nicolas Pouillard
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer 
 wrote:
> Nicolas Pouillard schrieb:
> > However the rule is still the same when using an unsafe function you are on
> > your own.
> > 
> > Clearer?
> 
> Almost. What I am missing is whether or not you would then consider your
> genericSeq (which is applicable to functions) one of those "unsafe
> functions" or not.

I would consider it as a safe function.

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


Re: [Haskell-cafe] Re: can Haskell do everyting as we want?

2010-08-04 Thread aditya siram
I think what the OP is asking for is a killer application of Haskell - Ruby,
for example, is great for web programming because of Rails.

The Haskell community is somewhat unique in that it has many killer apps and
that confuses people.  It's great for version control (Darcs), window
managers (XMonad), parsing grammers (Parsec), concurrency (would STM be
considered a killer app?) etc. etc.

People outside the community get flustered because they keep trying to peg
the language as more suitable to one domain than another.

To the OP, while Haskell is not perfect (Jeremy Shaw already mentioned the
garbage-collector issue) it seems as though you could get pretty far before
you hit a wall. So pick a domain and have at it!

-deech

On Wed, Aug 4, 2010 at 10:04 AM, Kevin Jardine wrote:

> In my experience two of the biggest issues in selecting any language
> are the pool of potential programmers and the learning curve for the
> programmers you already have.
>
> If you only need two programmers to do a project and they both know
> Haskell well, then I think Haskell would do almost any job very well.
>
> I also think that the pool of potential Haskell programmers is
> growing. But it is still much smaller than many other languages.
>
> I do think that there is a larger learning curve for Haskell than
> moving from one imperative language (eg. PHP) to another one (eg.
> Ruby).
>
> In my view Haskell programmers are likely to be more productive and
> produce more correct (and possibly even more efficient) code once they
> know the language well.
>
> Kevin
>
> On Aug 4, 4:35 pm, David Leimbach  wrote:
> > On Wed, Aug 4, 2010 at 3:16 AM, Alberto G. Corona  >wrote:
> >
> > > Just to clarify,  I mean: Haskell may be seriously addictive.  Sounds
> like
> > > a joke, but it is not.  I do not recommend it for coding something
> quick and
> > > dirty.
> >
> > I use it for quick and dirty stuff all the time, mainly because what I
> want
> > is often something that can be broken down into stages of processing, and
> > pure functions are really nice for that.
> >
> > If I know the input is coming from a reliable enough stream (like a unix
> > pipe to stdin) I can use functions like "interact" to create filters, or
> > parse some input, and produce some output.
> >
> > It's pretty nice.
> >
> >
> >
> > > 2010/8/4 Alberto G. Corona 
> >
> > > Before entering haskell, please read our disclaimer:
> >
> > >>http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html
> >
> > >> You've been warned
> > >> *
> > >> *
> >
> > >> 2010/8/4 Zura_ 
> >
> > >>> As already noted here, Haskell is a general purpose language, but you
> > >>> should
> > >>> take it with a grain of salt.
> > >>> For instance, you can nail with a laptop (provided that you hit the
> place
> > >>> where a HDD is located), but you prefer a hammer :)
> > >>> One thing is if you do it only for enjoyment, in this case you can
> even
> > >>> develop 3D shooter game in Haskell, but when it comes to
> production/real
> > >>> world use, I think it is better to maintain "right tool for the right
> > >>> job"
> > >>> attitude.
> >
> > >>> Regards,
> > >>> Zura
> >
> > >>> Qi Qi-2 wrote:
> >
> > >>> > Is there anyone happen to come into any tasks that haskell is not
> able
> > >>> > to achieve?
> >
> > >>> --
> > >>> View this message in context:
> > >>>
> http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176...
> > >>> Sent from the Haskell - Haskell-Cafe mailing list archive at
> Nabble.com.
> >
> > >>> ___
> > >>> Haskell-Cafe mailing list
> > >>> haskell-c...@haskell.org
> > >>>http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> > > ___
> > > Haskell-Cafe mailing list
> > > haskell-c...@haskell.org
> > >http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> >
> > ___
> > 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
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Janis Voigtländer

Nicolas Pouillard schrieb:

However the rule is still the same when using an unsafe function you are on
your own.

Clearer?


Almost. What I am missing is whether or not you would then consider your
genericSeq (which is applicable to functions) one of those "unsafe
functions" or not.

Ciao,
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


Re: [Haskell-cafe] Arrays and image processing

2010-08-04 Thread Anthony Cowley
On Wed, Aug 4, 2010 at 12:49 AM, kirstin penelope rhys
 wrote:
> But now I need a fast multidimensional array which can handle a tuple of
> primitive types.
>
> My options, as far an I can see, are:
>
> 1) Add an instance for UArray (Int,Int) (Word16, Word16, Word16)
> and/or UArray (Int,Int) (Word8, Word8, Word8)
>
> 2) Add a multidimensional wrapper for Data.Vector

What about something like,

import qualified Data.Vector.Unboxed as V
import Data.Word

type Pixel = (Word8, Word8, Word8)
type Image = (Int, Int, V.Vector Pixel)


Since you may want interoperability with C, you could also consider
using Data.Vector.Storable with flat data. Just put the
multi-dimensional logic in your indexing operations. I do quite a bit
of image processing with a mix of Haskell and C, and have found
Unboxed and Storable Vectors effective.

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


[Haskell-cafe] Re: can Haskell do everyting as we want?

2010-08-04 Thread Kevin Jardine
In my experience two of the biggest issues in selecting any language
are the pool of potential programmers and the learning curve for the
programmers you already have.

If you only need two programmers to do a project and they both know
Haskell well, then I think Haskell would do almost any job very well.

I also think that the pool of potential Haskell programmers is
growing. But it is still much smaller than many other languages.

I do think that there is a larger learning curve for Haskell than
moving from one imperative language (eg. PHP) to another one (eg.
Ruby).

In my view Haskell programmers are likely to be more productive and
produce more correct (and possibly even more efficient) code once they
know the language well.

Kevin

On Aug 4, 4:35 pm, David Leimbach  wrote:
> On Wed, Aug 4, 2010 at 3:16 AM, Alberto G. Corona wrote:
>
> > Just to clarify,  I mean: Haskell may be seriously addictive.  Sounds like
> > a joke, but it is not.  I do not recommend it for coding something quick and
> > dirty.
>
> I use it for quick and dirty stuff all the time, mainly because what I want
> is often something that can be broken down into stages of processing, and
> pure functions are really nice for that.
>
> If I know the input is coming from a reliable enough stream (like a unix
> pipe to stdin) I can use functions like "interact" to create filters, or
> parse some input, and produce some output.
>
> It's pretty nice.
>
>
>
> > 2010/8/4 Alberto G. Corona 
>
> > Before entering haskell, please read our disclaimer:
>
> >>http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html
>
> >> You've been warned
> >> *
> >> *
>
> >> 2010/8/4 Zura_ 
>
> >>> As already noted here, Haskell is a general purpose language, but you
> >>> should
> >>> take it with a grain of salt.
> >>> For instance, you can nail with a laptop (provided that you hit the place
> >>> where a HDD is located), but you prefer a hammer :)
> >>> One thing is if you do it only for enjoyment, in this case you can even
> >>> develop 3D shooter game in Haskell, but when it comes to production/real
> >>> world use, I think it is better to maintain "right tool for the right
> >>> job"
> >>> attitude.
>
> >>> Regards,
> >>> Zura
>
> >>> Qi Qi-2 wrote:
>
> >>> > Is there anyone happen to come into any tasks that haskell is not able
> >>> > to achieve?
>
> >>> --
> >>> View this message in context:
> >>>http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176...
> >>> Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
>
> >>> ___
> >>> Haskell-Cafe mailing list
> >>> haskell-c...@haskell.org
> >>>http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> > ___
> > Haskell-Cafe mailing list
> > haskell-c...@haskell.org
> >http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> ___
> 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: Laziness question

2010-08-04 Thread Nicolas Pouillard
On Wed, 04 Aug 2010 15:41:54 +0200, Janis Voigtländer 
 wrote:
> Nicolas Pouillard schrieb:
> >>> Actually I think we can keep the old generic seq, but cutting its full
> >>> polymorphism:
> >>>
> >>> seq :: Typeable a => a -> b -> b
> >> I guess I don't know enough about Typeable to appreciate that.
> > 
> > Basically the Typeable constraints tells that we dynamically know the 
> > identity
> > of the type being passed in. So this may be a bit challenging to cleanly
> > explain how this safely disable the parametricity but in the mean time
> > this is the net result the type is dynamically known at run time.
> > 
> > ...
> > 
> > However I would like to here more comments about this seq variant, anyone?
> 
> On reflection, isn't Typeable actually much too strong a constraint?

It is indeed "too strong", or "not precise enough" we could say.

However at least this simple change make it "correct" (i.e. restore
the parametricity results).

I would call this function genericSeq :: Typeable a => a -> b -> b

> Given that it provides runtime type inspection, probably one cannot
> derive any parametricity results at all for a type variable constrained
> by Typeable.

Exactly. We could say that we no longer car derive wrong parametricity
results about it.

> In contrast, for a type variable constrained via a
> hypothetical (and tailored to seq) Eval-constraint, one still gets
> something which looks like a standard free theorem, just with some side
> conditions relating to _|_ (strictness, totality, ...).

Indeed, that's why I want both!

In particular for the instance on functions which could be defined using
genericSeq.

> >>> OK, I better understand now where we disagree. You want to see in the type
> >>> whether or not the free theorem apply,
> >> Oh, YES. That's the point of a free theorem, isn't it: that I only need
> >> to look at the type of the function to derive some property about it.
> >>
> >>> I want them to always apply when
> >>> no call to unsafe function is made.
> >> Well, the question is what you mean by "no call to unsafe function is
> >> made". Where? In the function under consideration, from whose type the
> >> free theorem is derived? Are you sure that this is enough? Maybe that
> >> function f does not contain a call to unsafeSeq, but it has an argument
> >> which is itself a function. Maybe in some function application,
> >> unsafeSeq is passed to f in that argument position, directly or
> >> indirectly. Maybe f does internally apply that function argument to
> >> something. Can you be sure that this will not lead to a failure of the
> >> free theorem you derived from f's type (counting on the fact that f does
> >> not call an unsafe function)?
> >>
> >> Of course, preventing the *whole program* from calling unsafeSeq is
> >> enough to guarantee validity of the free theorems thus derived. But
> >> that's equivalent to excluding seq from Haskell altogether.
> > 
> > It depends on the unsafe function that is used. Using unsafeCoerce
> > or unsafePerformIO (from which we can derive unsafeCoerce) badely
> > anywhere suffice to break anything. So while seq is less invasive
> > I find it too much invasive in its raw form.
> 
> Hmm, from this answer I still do not see what you meant when you said
> you want free theorems to always apply when no call to seq is made. You
> say that seq is less invasive, so do you indeed assume that as soon as
> you are sure a function f does not itself (syntactically) contain a call
> to seq you are safe to use the standard free theorem derived from f's
> type unconstrained? Do you have any justification for that? Otherwise,
> we are back to banning seq completely from the whole program/language,
> in which case it is trivial that no seq-related side conditions will be
> relevant.

Actually given genericSeq, I no longer advocate the need for a polymorphic
seq function. So both genericSeq and the seq from the type class would
both safe.

However the rule is still the same when using an unsafe function you are on
your own.

Clearer?

Best regards,

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


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Thomas Schilling
On 4 August 2010 15:44, aditya siram  wrote:
> I really like the color scheme and the Javadoc looking frames.
>
> One suggestion I can make is to have the index show all the functions with
> type signatures without having to pick a letter. A lot of times I'll be
> looking for a function of a certain signature as opposed to a name. Indeed
> an index of type signatures would great! I remember wishing I had this when
> trying the understand the Parsec package.
>
> -deech

Wouldn't hoogle be better for this kind of use case?  The index can
become very large already.

More direct hoogle/hayoo integration (at least on Hackage) sounds like
a worthwhile goal, though.  Noted.

>
> On Wed, Aug 4, 2010 at 8:55 AM, Yitzchak Gale  wrote:
>>
>> Mark Lentczner wrote:
>> > The Haddock team...
>> > Please take a look, and then give us your feedback
>>
>> Very very nice. I took the survey, but here are some comments
>> I left out.
>>
>> I like the idea of the Snappy style the best, but there are two
>> serious problems with it, at least in my browser (Safari):
>>
>> 1. The black on dark blue of the "Snap Packages" title makes it
>> nearly unreadable for me.
>> 2. The wide fonts stretch things out so far on my screen that the
>> page becomes almost unusable.
>>
>> The other styles are fine, I would use them instead.
>>
>> Here is a comment I'll repeat from the survey because of its
>> importance: Please add a "collapse all" button for the tree on
>> the contents page. For me, that is perhaps the most urgent
>> thing missing in all of Haddock. It would make that tree so
>> much more usable.
>>
>> Thanks for the great work,
>> Yitz
>> ___
>> 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
>
>



-- 
If it looks like a duck, and quacks like a duck, we have at least to
consider the possibility that we have a small aquatic bird of the
family Anatidae on our hands.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread aditya siram
I really like the color scheme and the Javadoc looking frames.

One suggestion I can make is to have the index show all the functions with
type signatures without having to pick a letter. A lot of times I'll be
looking for a function of a certain signature as opposed to a name. Indeed
an index of type signatures would great! I remember wishing I had this when
trying the understand the Parsec package.

-deech

On Wed, Aug 4, 2010 at 8:55 AM, Yitzchak Gale  wrote:

> Mark Lentczner wrote:
> > The Haddock team...
> > Please take a look, and then give us your feedback
>
> Very very nice. I took the survey, but here are some comments
> I left out.
>
> I like the idea of the Snappy style the best, but there are two
> serious problems with it, at least in my browser (Safari):
>
> 1. The black on dark blue of the "Snap Packages" title makes it
> nearly unreadable for me.
> 2. The wide fonts stretch things out so far on my screen that the
> page becomes almost unusable.
>
> The other styles are fine, I would use them instead.
>
> Here is a comment I'll repeat from the survey because of its
> importance: Please add a "collapse all" button for the tree on
> the contents page. For me, that is perhaps the most urgent
> thing missing in all of Haddock. It would make that tree so
> much more usable.
>
> Thanks for the great work,
> Yitz
> ___
> 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] Preview the new haddock look and take a short survey

2010-08-04 Thread Ozgur Akgun
A few points,

* The text in Synopsis part is typically wide. (See
http://www.ozonehouse.com/mark/snap-xhtml/heist/Text-Templating-Heist.htmlwith
Ocean style)
I think it would be more *usable *if it was at the bottom of the page (again
with a similar button and open/close toggling effect)

* On my browser (firefox on a mac) if I select any of the two styles other
than Ocean, module pages seem like they do not apply any style. And also
they still reference ocean.css. A cookie problem or something like that?

* Opening the synopsis frame (either at its current position or at the
bottom of the page) might be better if it was implemented as a preference.
Namely, if I open the synopsis frame in a module page, I'd possibly like to
see it in the next modules page as well. Carrying that information to the
same extend as preferred style information sounds like a better idea to me.

Thanks for the work!

Best,

On 4 August 2010 06:00, Mark Lentczner  wrote:

> The Haddock team has spent the last few months revamping the look of the
> generated output. We're pretty close to done, but we'd like to get the
> community's input before we put it in the main release.
>
> Please take a look, and then give us your feedback through a short survey
>
> Sample pages:  http://www.ozonehouse.com/mark/snap-xhtml/index.html
> Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html
>
> Survey:
>
> http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ
> Short link to same survey:
>http://bit.ly/9Zvs9B
>
> Thanks!
>
>- Mark
>
> Mark Lentczner
> http://www.ozonehouse.com/mark/
> irc: MtnViewMark
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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


Re: [Haskell-cafe] can Haskell do everyting as we want?

2010-08-04 Thread David Leimbach
On Wed, Aug 4, 2010 at 3:16 AM, Alberto G. Corona wrote:

> Just to clarify,  I mean: Haskell may be seriously addictive.  Sounds like
> a joke, but it is not.  I do not recommend it for coding something quick and
> dirty.
>

I use it for quick and dirty stuff all the time, mainly because what I want
is often something that can be broken down into stages of processing, and
pure functions are really nice for that.

If I know the input is coming from a reliable enough stream (like a unix
pipe to stdin) I can use functions like "interact" to create filters, or
parse some input, and produce some output.

It's pretty nice.


>
> 2010/8/4 Alberto G. Corona 
>
> Before entering haskell, please read our disclaimer:
>>
>> http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html
>>
>> You've been warned
>> *
>> *
>>
>> 2010/8/4 Zura_ 
>>
>>
>>> As already noted here, Haskell is a general purpose language, but you
>>> should
>>> take it with a grain of salt.
>>> For instance, you can nail with a laptop (provided that you hit the place
>>> where a HDD is located), but you prefer a hammer :)
>>> One thing is if you do it only for enjoyment, in this case you can even
>>> develop 3D shooter game in Haskell, but when it comes to production/real
>>> world use, I think it is better to maintain "right tool for the right
>>> job"
>>> attitude.
>>>
>>> Regards,
>>> Zura
>>>
>>>
>>> Qi Qi-2 wrote:
>>> >
>>> > Is there anyone happen to come into any tasks that haskell is not able
>>> > to achieve?
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176p29342871.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 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] Preview the new haddock look and take a short survey

2010-08-04 Thread Yitzchak Gale
Mark Lentczner wrote:
> The Haddock team...
> Please take a look, and then give us your feedback

Very very nice. I took the survey, but here are some comments
I left out.

I like the idea of the Snappy style the best, but there are two
serious problems with it, at least in my browser (Safari):

1. The black on dark blue of the "Snap Packages" title makes it
nearly unreadable for me.
2. The wide fonts stretch things out so far on my screen that the
page becomes almost unusable.

The other styles are fine, I would use them instead.

Here is a comment I'll repeat from the survey because of its
importance: Please add a "collapse all" button for the tree on
the contents page. For me, that is perhaps the most urgent
thing missing in all of Haddock. It would make that tree so
much more usable.

Thanks for the great work,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Frank Kupke
Good questions. I am about to write a paper explaining the design of the DSTM 
library in more detail which I will link when available. Please bear with me, 
here. In the meantime please find some shorter answers below.

Regards,
Frank

Am 04.08.2010 um 10:53 schrieb Andrew Coppin:

> Frank Kupke wrote:
>> For usage please look into the documentation file: DSTMManual.pdf.
> 
> 1. Any danger of puting this somewhere I can read it without having to 
> download and manually unpack the Hackage tarball?
Actually not. I just had not thought about it. Here is a link to the pdf.

http://www-ps.informatik.uni-kiel.de/~frk/dstm.pdf

> 
> 2. Since DSTM depends on the Unix package, I presume this won't work on 
> Windows. (?) OOC, what does it use Unix for?
Good point. I use System.Posix for benchmark debug code and a sigPIPE handler. 
Probably both can go without doing any damage. I will look into it. As you can 
tell, I have not tested using Windows...
> 
> 3. It is unclear to me what happens in the event of a communications failure. 
> The documentation says an exception is thrown, but does the running 
> transaction rollback or just retry or...? (The documentation seems to suggest 
> that it might actually *commit* in spite of a communications failure, which 
> sounds wrong.)
Two things happen in parallel. 
+ One is that the library throws an exception to the application saying 
basically: Hey, at least one of your TVars you just accessed is broken, you 
better check which ones and react on it in your program. This is the 
abstraction level outside of a transaction (atomic function). The app now knows 
that one or more of its services represented by TVars is down and needs 
attention.
+ The other thing is the low-level stuff within the transaction thus within the 
library. The behavior of the transaction depends on *when* actually the failure 
is detected. 
- If the failure comes up *before* the transaction has been validated ok, it is 
aborted. A normal invalidation abort would restart the transaction 
automatically but in this case throwing the exception terminates it. Abort is 
often called rollback (when referring to databases) but I prefer not to because 
up to now everything has been done safely within the STM monad. Nothing 
happened in the IO world, hence nothing need to be rolled back. (Btw. *retry* 
is a different kind of transaction restart. It is not done automatically but 
forced by the application calling the retry function.)
- If the failure comes up *after* the transaction has been validated ok, it is 
committed. At first, this might look wrong but it is not. Here is why: If the 
validation is ok, all participating TVars on any node have agreed that the 
transaction is ready to commit. If then any one of these TVars fails, the 
decision to commit is still valid as nothing else has changed. Note that all 
TVars are locked by the library from before validating until after committing. 
Furthermore, some TVars might have already finished the commit. Then it would 
be inconsistent for the others not to commit.
In both cases, commit or not, however, the library takes precautions that no 
deadlocks build up by broken TVars unexpectedly quitting the transaction 
protocol.

> Also, when is failure detected? Is it only when a transaction tries to access 
> the variable?
Yes. However, all such accesses are happening within the library and are fully 
transparent to the application. As TCP is a connection based protocol only 
simulating a connection, we do not know exactly when a connection actually 
breaks. We can peek, though. Either by sending test messages (ping), if they 
bounce, the connection is obviously broken; Or by just observing when a regular 
message bounces. Regular messages are due to reading, validating, committing, 
... TVars within atomic transactions. The library detects the failure (sooner 
or later) and informs the application by throwing the exception right after the 
detection. From an application's perspective the failure is only detected when 
the application reads from or writes to the TVar within an atomic transaction. 
If a TVar is not accessed its failure might remain undetected.
> 
> 4. What network transport does this thing use? TCP? UDP? What port numbers?
DSTM uses TCP communication. It searches dynamically for available ports 
starting at port 60001, using 6 for the name server. If two nodes are 
running each on a separate machine with a different IP address, chances are 
that both use the same port 60001. If they run on the same machine, most likely 
one will use port 60001 and the other 60002.
> 
> 5. How does it work? Does it spawn a Haskell thread for each machine 
> connection or something?
Each node spawns a Haskell thread listening to its designated port and spawning 
itself a thread for each accepted TCP communication, i.e. one for each foreign 
node talking to it. Each such thread implements a communication line between 
two threads. I have tried several communica

Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Janis Voigtländer

Nicolas Pouillard schrieb:

Actually I think we can keep the old generic seq, but cutting its full
polymorphism:

seq :: Typeable a => a -> b -> b

I guess I don't know enough about Typeable to appreciate that.


Basically the Typeable constraints tells that we dynamically know the identity
of the type being passed in. So this may be a bit challenging to cleanly
explain how this safely disable the parametricity but in the mean time
this is the net result the type is dynamically known at run time.

...

However I would like to here more comments about this seq variant, anyone?


On reflection, isn't Typeable actually much too strong a constraint?
Given that it provides runtime type inspection, probably one cannot
derive any parametricity results at all for a type variable constrained
by Typeable. In contrast, for a type variable constrained via a
hypothetical (and tailored to seq) Eval-constraint, one still gets
something which looks like a standard free theorem, just with some side
conditions relating to _|_ (strictness, totality, ...).

In other words, by saying seq :: Typeable a => a -> b -> b, you assume
pessimistically that seq can do everything that is possible on members
of the Typeable class. But that might be overly pessimistic, since in
reality the only thing that seq can do is evaluate an arbitrary
expression to weak head normal form.


OK, I better understand now where we disagree. You want to see in the type
whether or not the free theorem apply,

Oh, YES. That's the point of a free theorem, isn't it: that I only need
to look at the type of the function to derive some property about it.


I want them to always apply when
no call to unsafe function is made.

Well, the question is what you mean by "no call to unsafe function is
made". Where? In the function under consideration, from whose type the
free theorem is derived? Are you sure that this is enough? Maybe that
function f does not contain a call to unsafeSeq, but it has an argument
which is itself a function. Maybe in some function application,
unsafeSeq is passed to f in that argument position, directly or
indirectly. Maybe f does internally apply that function argument to
something. Can you be sure that this will not lead to a failure of the
free theorem you derived from f's type (counting on the fact that f does
not call an unsafe function)?

Of course, preventing the *whole program* from calling unsafeSeq is
enough to guarantee validity of the free theorems thus derived. But
that's equivalent to excluding seq from Haskell altogether.


It depends on the unsafe function that is used. Using unsafeCoerce
or unsafePerformIO (from which we can derive unsafeCoerce) badely
anywhere suffice to break anything. So while seq is less invasive
I find it too much invasive in its raw form.


Hmm, from this answer I still do not see what you meant when you said
you want free theorems to always apply when no call to seq is made. You
say that seq is less invasive, so do you indeed assume that as soon as
you are sure a function f does not itself (syntactically) contain a call
to seq you are safe to use the standard free theorem derived from f's
type unconstrained? Do you have any justification for that? Otherwise,
we are back to banning seq completely from the whole program/language,
in which case it is trivial that no seq-related side conditions will be
relevant.

Best,
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


Re: [Haskell-cafe] Re: Laziness question

2010-08-04 Thread Nicolas Pouillard
On Tue, 03 Aug 2010 16:36:33 +0200, Janis Voigtländer 
 wrote:
> Nicolas Pouillard schrieb:
> >> - If there is no class instance for function types, then those problems
> >> go away, of course. But it is doubtful whether that would be a viable
> >> solution. Quite a few programs would be rejected as a consequence. (Say,
> >> you want to use the strict version of foldl. That will lead to a type
> >> class constraint on one of the type variables. Now suppose you actually
> >> want to fold in a higher-order fashion, like when expressing efficient
> >> reverse via foldr. That would not anymore be possible for the strict
> >> version of foldl, as it would require the type-class-constrained
> >> variable to be instantiated with a function type.)
> > 
> > I think it would be a step forward. The old seq would still exists as
> > unsafeSeq and such applications could continue to use it. In the mean
> > time parametricity results would better apply to programs without unsafe
> > functions. And this without adding extra complexity into the type system.
> 
> Yes, I agree. Of course, you (and Lennart, and others advocating putting
> seq into a type class) could work toward that solution right away, could
> have done so for quite some time: write a package with an Eval type
> class and method safeSeq (and *no* class instance for function types),
> upload it on Hackage, encourage people to use it. Modulo the naming
> difference seq/safeSeq vs. unsafeSeq/seq, that's exactly the solution
> you want. I wonder why it is not happening. :-)

Yes it would be a starting point.

> > Actually I think we can keep the old generic seq, but cutting its full
> > polymorphism:
> > 
> > seq :: Typeable a => a -> b -> b
> 
> I guess I don't know enough about Typeable to appreciate that.

Basically the Typeable constraints tells that we dynamically know the identity
of the type being passed in. So this may be a bit challenging to cleanly
explain how this safely disable the parametricity but in the mean time
this is the net result the type is dynamically known at run time.

The same trick is known to work for references as well when effects are
everywhere:

newRef :: Typeable a => a -> Ref a
readRef :: Ref a -> a
writeRef :: Ref a -> a -> ()

In the same vein it would make unsafePerformIO less dangerous to add such
a constraint.

However I would like to here more comments about this seq variant, anyone?

> > OK, I better understand now where we disagree. You want to see in the type
> > whether or not the free theorem apply,
> 
> Oh, YES. That's the point of a free theorem, isn't it: that I only need
> to look at the type of the function to derive some property about it.
> 
> > I want them to always apply when
> > no call to unsafe function is made.
> 
> Well, the question is what you mean by "no call to unsafe function is
> made". Where? In the function under consideration, from whose type the
> free theorem is derived? Are you sure that this is enough? Maybe that
> function f does not contain a call to unsafeSeq, but it has an argument
> which is itself a function. Maybe in some function application,
> unsafeSeq is passed to f in that argument position, directly or
> indirectly. Maybe f does internally apply that function argument to
> something. Can you be sure that this will not lead to a failure of the
> free theorem you derived from f's type (counting on the fact that f does
> not call an unsafe function)?
> 
> Of course, preventing the *whole program* from calling unsafeSeq is
> enough to guarantee validity of the free theorems thus derived. But
> that's equivalent to excluding seq from Haskell altogether.

It depends on the unsafe function that is used. Using unsafeCoerce
or unsafePerformIO (from which we can derive unsafeCoerce) badely
anywhere suffice to break anything. So while seq is less invasive
I find it too much invasive in its raw form.

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


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Thomas Schilling
On 4 August 2010 10:11, Magnus Therning  wrote:
> On Wed, Aug 4, 2010 at 06:00, Mark Lentczner  wrote:
>> The Haddock team has spent the last few months revamping the look of the 
>> generated output. We're pretty close to done, but we'd like to get the 
>> community's input before we put it in the main release.
>>
>> Please take a look, and then give us your feedback through a short survey
>>
>> Sample pages:  http://www.ozonehouse.com/mark/snap-xhtml/index.html
>
> I really like it, especially the synopsis tab on the right.  Brilliant!  The
> TOC is nice too!  The over-all impression is that it doesn't look as
> auto-generated as the old style.
>
>> Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html
>
> Also very good looking.  Does the current stable version of Haddock really
> create a frame version?
> I've never seen one before...

Yes, I added it two years ago, but we never advertised it much,
because of a problem on Firefox.  You had to press the back button
twice, which was annoying.  I've just found a fix, though, so it
should work fine in the next  release.  It already works fine in
Chrome, though.

>
> /M
>
> --
> Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
> magnus@therning.org          Jabber: magnus@therning.org
> http://therning.org/magnus         identi.ca|twitter: magthe
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
If it looks like a duck, and quacks like a duck, we have at least to
consider the possibility that we have a small aquatic bird of the
family Anatidae on our hands.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: can Haskell do everyting as we want?

2010-08-04 Thread Ivan Lazar Miljenovic
On 4 August 2010 23:13, Johannes Waldmann  wrote:
>
>> However, if you tried to do "s.equalsIgnoreCase(", does it offer to
>> insert every single String available and every function that could
>> result in a String?
>
> well, try this:
>
>                String s = "foo";
>                String t = "bar";
>                int u = 42;
>                s.equalsIgnoreCase(
>
> it suggests s, t, and null (but not u),
> so this is again type-based.

Huh, last time I tried an IDE for Java (which was admittedly quite a
while ago) it wouldn't do anything like that...

I stand corrected then.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: can Haskell do everyting as we want?

2010-08-04 Thread Johannes Waldmann

> However, if you tried to do "s.equalsIgnoreCase(", does it offer to
> insert every single String available and every function that could
> result in a String?

well, try this:

String s = "foo";
String t = "bar";
int u = 42;
s.equalsIgnoreCase(

it suggests s, t, and null (but not u),
so this is again type-based.


if you try completion on

  s.equalsIgnoreCase(t.

then you see that those methods that return a String,
are at the front of the completion list.


J.W.



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] can Haskell do everyting as we want?

2010-08-04 Thread Ivan Lazar Miljenovic
Tillmann Rendel  writes:

> Ivan Lazar Miljenovic wrote::
>> My understanding of tab-completion in IDEs for Java, etc. is that it
>> just displayed every single possible class method for a particular
>> object value, and then did some kind of matching based upon what you
>> typed to narrow down the list, not that it was type-based.
>
> Good completion is type based. For example, consider the following
> situations in Eclipse:
>
>   (1) int foo = "bar".
>   (2) String foo = "bar".
>
> In both cases, completion will only propose methods of String and its
> super class Object, so the type of the receiver is taken into account.

Yes, it knows which class methods are available.  But can it list every
possible argument that a given class method needs?  IMHO, that is a
closer analogy/comparison to what type-based completion for Haskell
would require.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] can Haskell do everyting as we want?

2010-08-04 Thread Yitzchak Gale
Rogan Creswick wrote:
> Haskell has very limited support for high-level Natural Language
> Processing (tokenization, sentence splitting, Named-entity
> recognition, etc...).

Since the role of a general purpose language is relatively
new for Haskell, there are many areas where Haskell is still
an emerging language. So it is interesting that you say that
about NLP, where Haskell is not only quite mature, but
arguably the leading language today.

For example, the EU's huge Molto project http://molto-project.eu/,
which aims to provide automated real-time high-quality
translation of a wide class of documents between all
of the EU languages, is based on Haskell's GF
http://grammaticalframework.org/.

Coincidentally, just yesterday a company that markets
one of the top semantic NLP products contacted me.
They have decided to dump their entire Java code base,
using older technologies such as the ones you mentioned.
One of their leading candidates for a replacement language
is Haskell. They told me, "You see Haskell everywhere in
NLP these days."

See http://www.haskell.org/haskellwiki/Applications_and_libraries/Linguistics
for links about NLP work in Haskell. That is a huge wiki
page and hard to maintain, so some of the links are out of
date, but you get the idea.

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


Re: [Haskell-cafe] can Haskell do everyting as we want?

2010-08-04 Thread Tillmann Rendel

Ivan Lazar Miljenovic wrote::

My understanding of tab-completion in IDEs for Java, etc. is that it
just displayed every single possible class method for a particular
object value, and then did some kind of matching based upon what you
typed to narrow down the list, not that it was type-based.


Good completion is type based. For example, consider the following 
situations in Eclipse:


  (1) int foo = "bar".
  (2) String foo = "bar".

In both cases, completion will only propose methods of String and its 
super class Object, so the type of the receiver is taken into account.


Furthermore, the proposed methods will be ordered differently in (1) and 
(2). In (1), the list of proposed methods starts with methods returning 
int, while in (2), the list of proposed methods starts with methods 
returning String, so the type of the context is taken into account.


I guess that it may be easier to implement effective completion for Java 
because in Java, completion-relevant context information is often to the 
left of the completion position.


On the other hand, shouldn't constraint-based type inference à la 
Haskell be relatively easy to extend towards type-based completion? An 
IDE could infer the types of the holes in half-finished source code, and 
then try to unify the types of identifiers in scope with the type of the 
hole the programmer is typing in. If the resulting constraint system is 
consistent, the identifier should be proposed as a completion.


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


Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer

2010-08-04 Thread Max Bolingbroke
On 4 August 2010 12:34, Thomas Schilling  wrote:
> I believe the main reason why ghci isn't available on all platforms is
> the dynamic linker.  I don't think it would be easy (or even feasible)
> to switch to something like 'ld', though.

AFAIK the current linker is meant to support Mach O, ELF and COFF,
which should cover almost every platform GHC is able to run on. Now,
it's not ideal that GHC maintains its own dynamic linker
implementation, but if someone has discovered a bugs with it (or any
other bug preventing TH from working) I'm sure GHC HQ would be
interested in knowing.

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


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Daniel Peebles
Great! I like it a lot, but a couple of minor suggestions regarding the
"tree" view of modules. I think it would be more attractive (and
space-efficient) to have them indent a little less and to provide some sort
of visual link, in the form of even subtle branches, from parents to
children. A bit like
http://origin.arstechnica.com/journals/linux.media/300/dolphin_tree_view.pngor
similar.


On Wed, Aug 4, 2010 at 7:00 AM, Mark Lentczner  wrote:

> The Haddock team has spent the last few months revamping the look of the
> generated output. We're pretty close to done, but we'd like to get the
> community's input before we put it in the main release.
>
> Please take a look, and then give us your feedback through a short survey
>
> Sample pages:  http://www.ozonehouse.com/mark/snap-xhtml/index.html
> Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html
>
> Survey:
>
> http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ
> Short link to same survey:
>http://bit.ly/9Zvs9B
>
> Thanks!
>
>- Mark
>
> Mark Lentczner
> http://www.ozonehouse.com/mark/
> irc: MtnViewMark
>
>
>
> ___
> 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: can Haskell do everyting as we want?

2010-08-04 Thread Ivan Lazar Miljenovic
Johannes Waldmann  writes:

>> My understanding of tab-completion in IDEs for Java, etc. is that it
>> just displayed every single possible class method for a particular
>> object value, and then did some kind of matching based upon what you
>> typed to narrow down the list, not that it was type-based.
>
> With Eclipse, try something like (within some method)
>   String s = "foo";  s.   (stop after the dot)
> and you see only methods of String (and Object).
> To me, that seems very much "type-based".

Well, yes, it is every single possible class method for a String object.
However, if you tried to do "s.equalsIgnoreCase(", does it offer to
insert every single String available and every function that could
result in a String?

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Re: can Haskell do everyting as we want?

2010-08-04 Thread Johannes Waldmann

> My understanding of tab-completion in IDEs for Java, etc. is that it
> just displayed every single possible class method for a particular
> object value, and then did some kind of matching based upon what you
> typed to narrow down the list, not that it was type-based.

With Eclipse, try something like (within some method)
  String s = "foo";  s.   (stop after the dot)
and you see only methods of String (and Object).
To me, that seems very much "type-based".

Of course this requires the integration 
of parser and static analyzer with the editor -
and you need to be able to parse and analyze partial programs.

J.W.


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


Re: [Haskell-cafe] Software architecture

2010-08-04 Thread Chris Eidhof
I think the general process is the same. You define your components, try to 
decouple them as much as possible and implement them. One thing that is 
different from other languages: try to write as much pure code as possible. 
This is great for creating composable components.

There are several different ways to structure your programs. The Utrecht 
Haskell Compiler is structured using attribute grammars, which is (similar to) 
aspect-oriented programming.

Another architectural pattern you see a lot is that a program is provided as a 
library and a very small main function. A very good example of this is XMonad.

You could also look at http://www.haskell.org/haskellwiki/Haskell_in_industry, 
which gives some pointers to commercial projects and how they are structured.

-chris

On 4 aug 2010, at 13:07, Charles-Pierre Astolfi wrote:

> Hey there,
> 
> I'm searching for software designs in Haskell ; for example, I have a
> pretty good ideo of how I would arrange my modules/classes (in
> ocaml/(java/c++)) and how they would all fit together to create, say,
> a website aspirator. But I don't have any clue of the right way to do
> it with Haskell.
> 
> I don't need a solution for this example, I'd just like to see how to
> manage non-trivial code. I haven't found any pointers on the
> interwebs.
> 
> On an unrelated note, what is the simplest way to get the llvm
> bitcode? I understand I can compile myself ghc but it there an easier
> way?
> 
> Thanks a lot!
> --
> Cp
> ___
> 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] ANNOUNCE: DSTM 0.1.1

2010-08-04 Thread Frank Kupke
After chatting with Chris privately it turned out that the confusion within the 
Chat example is partly because I did not find a good and simple solution for 
mixing user input and chat output asynchronously in one terminal stream. One 
can possibly do better, here. 
Also, apparently I left some debug flags active in the library which does not 
help to explore it. Sorry. You can turn debugging mode off by setting all debug 
flags to False in DebugBase.hs. I will correct that with the next update as 
well.

As a quick fix to put the documentation online it can be downloaded from 
http://www-ps.informatik.uni-kiel.de/~frk/dstm.pdf, also available through my 
very rudimentary institute's web presence 
http://www.informatik.uni-kiel.de/prog/mitarbeiter/frank-kupke/.

Regards,
Frank

Am 04.08.2010 um 10:43 schrieb Chris Eidhof:

> This looks very cool! It would be nice to put the pdf online somewhere, and 
> add a link from the package documentation. Also, the chat client seems to 
> have some problems with output buffering on my system (OS X, GHC 6.12).
> 
> -chris
> 
> On 3 aug 2010, at 10:35, Frank Kupke wrote:
> 
>> Hi,
>> DSTM is an implementation of a robust distributed Software Transactional 
>> Memory (STM) library for Haskell. Many real-life applications are 
>> distributed by nature. Concurrent applications may profit from robustness 
>> added by re-implementation as distributed applications. DSTM extends the STM 
>> abstraction to distributed systems and presents an implementation efficient 
>> enough to be used in soft real-time applications. Further, the implemented 
>> library is robust in itself, offering the application developer a high 
>> abstraction level to realize robustness, hence, significantly simplifying 
>> this, in general, complex task.
>> The DSTM package consists of the DSTM library, a name server application, 
>> and three sample distributed programs using the library. Provided are a 
>> simple Dining Philosophers, a Chat, and a soft real-time Bomberman game 
>> application. Distributed communication is transparent to the application 
>> programmer. The application designer uses a very simple name server 
>> mechanism to set up the system. The DSTM library includes the management of 
>> unavailable process nodes and provides the application with abstract error 
>> information thus facilitating the implementation of robust distributed 
>> application programs.
>> For usage please look into the documentation file: DSTMManual.pdf.
>> 
>> 
>> The package including the documentation can be found on:
>> 
>> http://hackage.haskell.org/package/DSTM-0.1.1
>> 
>> Best regards,
>> Frank Kupke
>> 
>> 
>> ___
>> 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] Preview the new haddock look and take a short survey

2010-08-04 Thread Mark Lentczner

On Aug 4, 2010, at 5:11 AM, Magnus Therning wrote:

> Does the current stable version of Haddock really
> create a frame version?
> I've never seen one before...

Yes it does. For example, the standaed GHC book packages doc has the frames 
version here:

http://www.haskell.org/ghc/docs/6.12.2/html/libraries/frames.html

Documentation on Hackage doesn't seems to be missing two of the generated files 
to enable the frames version to work for each package.

- Mark

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


Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.

2010-08-04 Thread Tillmann Rendel

Hi,

aditya siram wrote:

For example in the beginning it was useful for me to think of monads
(and typeclasses really) as approximating Java interfaces.


Type classes are somewhat parallel to Java interfaces, but Monad is a 
*specific* type class, so it should be somewhat parallel to a *specific* 
Java interface, if at all.



Type classes are somewhat parallel to Java interfaces because a Java 
interface


  interface Foo {
Result method (Argument argument);
  }

declares that there is a set of types so that every type T in that set 
has an operation (T, Argument) -> Result, with these operations all 
implemented specifically to particular type T. In Haskell, the type class


  class Foo t where
method : t -> Argument -> Result

expresses a similar concept. There are a number of differences though:

Firstly, in Java, calls to the method are late bound, while in Haskell, 
they are early bound. However, a kind of late bound behavior can be 
achieved using existentials.


Secondly, in Java, the receiver of the method has to be of type T, and T 
may not appear at other positions in the type of the method, while in 
Haskell, T may appear anywhere in the type of the method, even more then 
once.


Finally, in Java, T has to be a proper type (of kind *), while in 
Haskell, it may be an improper type (of a kind involving ->).



Already for the type class Functor, these differences become relevant.

  class Functor f where
fmap :: (a -> b) -> f a -> f b

f has kind (* -> *), and it is mentioned twice in the type of fmap.


Conclusion: While Haskell type classes have some similarities to Java 
interfaces, the type class Functor (or Monad, if you like) is not that 
similar to any Java interface, because it uses features specific to 
Haskell type classes which are not available in Java interfaces.



Nevertheless, it may be helpful for a Java developer to understand that 
Haskell type classes are more similar to Java interfaces than to Java 
classes.


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


Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer

2010-08-04 Thread Thomas Schilling
On 4 August 2010 12:05, Ivan Lazar Miljenovic  wrote:
> Max Bolingbroke  writes:
>
>> On 4 August 2010 11:39, Ivan Lazar Miljenovic  
>> wrote:
>>> Joachim Breitner  writes:
 the problem is that Template Haskell does not work on all architectures,
 so the Debian people prefer solutions that avoid TH if it is not
 needed.
>>>
>>> Yeah, we've just come across this problem in Gentoo when dealing with
>>> how Haddock behaves when there's TH to be documented in some
>>> architectures :s
>>
>> I didn't know this: is there a corresponding GHC ticket? I can't find
>> one, but I could just have chosen the wrong keywords. It seems like
>> the right thing to do would just be to make TH work properly rather
>> than maintain a special-purpose preprocessor.
>
> Not that I know of; all I know is that Sergei (aka slyfox) disabled
> building documentation (for libraries that come with GHC) on some
> architectures where ghci isn't available because of this.  My
> understanding is that TH uses ghci (or something like it) to evaluate
> the expressions, and that when Haddock started understanding TH it also
> needed to run ghci to build documentation containing TH.

Correct.  It also needs to be able to generate machine code from the
currently compiled package and its dependencies.  This is because ghci
does not support some features, in particular unboxed tuples.
Therefore, to be on the safe side, Haddock has to create (unoptimised)
binary code as well.

I believe the main reason why ghci isn't available on all platforms is
the dynamic linker.  I don't think it would be easy (or even feasible)
to switch to something like 'ld', though.


>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
If it looks like a duck, and quacks like a duck, we have at least to
consider the possibility that we have a small aquatic bird of the
family Anatidae on our hands.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] can Haskell do everyting as we want?

2010-08-04 Thread Ivan Lazar Miljenovic
Marc Weber  writes:

> Excerpts from Ivan Lazar Miljenovic's message of Wed Aug 04 12:37:29 +0200 
> 2010:
>> functionality in Emacs.
>
> I know - I patched the py backend for scion. I'm talking about:
>
>   node.getParent().getParent().Attributes["value"]
>
> Or (let's talk about a haskell example):
>
> pkgVersion $ package $ packageDescription
>
> It feels unnatural to complete this. How should this be done?
> I know that you can define your own .dot. operator, so that you can
> write it in (let's call it Java style):
>
> packageDescription .dot. package .dot. pkgVersion

I don't get the point of this ".dot." operator (which isn't even a valid
operator).

> Without completion I have to get the type of packageDescription, then
> follow the structure until I find Version. Using tags and Vim that's
> fast. Still completion is a lot faster.

Not really following your example here: you want something to write your
code for you and read your mind to know what that code should be?

My understanding of tab-completion in IDEs for Java, etc. is that it
just displayed every single possible class method for a particular
object value, and then did some kind of matching based upon what you
typed to narrow down the list, not that it was type-based.

> I'm not talking about the universal "put everything in scope" completion
> thing - eg which Vim provides for some languages. I'm talking about
> really helpful context sensitive completion. I know its pretty hard to
> get this hard for Haskell - because type is determined by things you
> use. But the example I gave above is one which could be implemented
> easily.

How is it easy?  How would this mythical completer know which function
to use?

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Software architecture

2010-08-04 Thread Charles-Pierre Astolfi
Hey there,

I'm searching for software designs in Haskell ; for example, I have a
pretty good ideo of how I would arrange my modules/classes (in
ocaml/(java/c++)) and how they would all fit together to create, say,
a website aspirator. But I don't have any clue of the right way to do
it with Haskell.

I don't need a solution for this example, I'd just like to see how to
manage non-trivial code. I haven't found any pointers on the
interwebs.

On an unrelated note, what is the simplest way to get the llvm
bitcode? I understand I can compile myself ghc but it there an easier
way?

Thanks a lot!
--
Cp
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer

2010-08-04 Thread Ivan Lazar Miljenovic
Max Bolingbroke  writes:

> On 4 August 2010 11:39, Ivan Lazar Miljenovic  
> wrote:
>> Joachim Breitner  writes:
>>> the problem is that Template Haskell does not work on all architectures,
>>> so the Debian people prefer solutions that avoid TH if it is not
>>> needed.
>>
>> Yeah, we've just come across this problem in Gentoo when dealing with
>> how Haddock behaves when there's TH to be documented in some
>> architectures :s
>
> I didn't know this: is there a corresponding GHC ticket? I can't find
> one, but I could just have chosen the wrong keywords. It seems like
> the right thing to do would just be to make TH work properly rather
> than maintain a special-purpose preprocessor.

Not that I know of; all I know is that Sergei (aka slyfox) disabled
building documentation (for libraries that come with GHC) on some
architectures where ghci isn't available because of this.  My
understanding is that TH uses ghci (or something like it) to evaluate
the expressions, and that when Haddock started understanding TH it also
needed to run ghci to build documentation containing TH.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer

2010-08-04 Thread Max Bolingbroke
On 4 August 2010 11:39, Ivan Lazar Miljenovic  wrote:
> Joachim Breitner  writes:
>> the problem is that Template Haskell does not work on all architectures,
>> so the Debian people prefer solutions that avoid TH if it is not
>> needed.
>
> Yeah, we've just come across this problem in Gentoo when dealing with
> how Haddock behaves when there's TH to be documented in some
> architectures :s

I didn't know this: is there a corresponding GHC ticket? I can't find
one, but I could just have chosen the wrong keywords. It seems like
the right thing to do would just be to make TH work properly rather
than maintain a special-purpose preprocessor.

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


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Ivan Lazar Miljenovic
Ivan Lazar Miljenovic  writes:

>> On Wed, Aug 4, 2010 at 06:00, Mark Lentczner  wrote:
>>> Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html
>>
> I quite like this new approach

Dammit, I just realised as I went to do the survey that the old framed
approach is almost identical to the new framed approach :s

For some reason I thought it was different... :s

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer

2010-08-04 Thread Ivan Lazar Miljenovic
Joachim Breitner  writes:

> Hi,
>
> Am Mittwoch, den 04.08.2010, 08:05 +0100 schrieb Max Bolingbroke:
>> On 4 August 2010 07:42, Joachim Breitner  wrote:
>> > out of a discussion in haskell-devscripts, John MacFarlane wrote a very
>> > nice tool, called hsb2hs, that allows you to include any binary (or
>> > text) file as a constant in your program.
>> 
>> When I've needed to do this in the past, I've used a simple bit of
>> Template Haskell:
>
> the problem is that Template Haskell does not work on all architectures,
> so the Debian people prefer solutions that avoid TH if it is not
> needed.

Yeah, we've just come across this problem in Gentoo when dealing with
how Haddock behaves when there's TH to be documented in some
architectures :s

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] can Haskell do everyting as we want?

2010-08-04 Thread Ivan Lazar Miljenovic
Marc Weber  writes:

> Hi Qi,
>
> have a look at brainfuck language. Its turing complete as Python, Haskell, etc
> are. Then you'll learn that the quesntion "Can I do everything possible"
> is not at all important. You have to ask instead:  Can I complete my
> task in reasonable time and with reasonable runtime performance etc.

And in a way that makes the code maintainable.

>   For most use cases Haskell is a good choice - the only real things
> I'm missing are
> - nice stack traces
> - completion support - because I find it relaxing not having to looking
>   all names. This could be fixed to some extend though..

If you mean whilst writing your code, this is an editor issue (I believe
scion aims to help writing cross-editor utilities for things like
this).  ghci also has tab-completion, and ghc-mod provides such
functionality in Emacs.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Why do "unsafe" foreign calls block other threads?

2010-08-04 Thread Gábor Lehel
On Wed, Aug 4, 2010 at 1:50 AM, Donn Cave  wrote:
> Quoth John Meacham ,
>
>> It is more an accident of ghc's design than anything, the same mechanism
>> that allowed threads to call back into the runtime also allowed them to
>> be non blocking so the previously used 'safe' and 'unsafe' terms got
>> re-used. personally, I really don't like those terms, they are
>> non-descriptive in terms of what they actually mean and presuppose a RTS
>> similar to ghcs current design. 'reentrant' and 'blocking' which could
>> be specified independently would be better and would be more
>> future-proof against changes in the RTS or between compilers.
>
> Is the concurrency issue documented somewhere?  What does `non blocking'
> mean, and why would it not just always be that way?
>
> In my situation, thread creation and dispatch happens in foreign
> library code, and execution in the Haskell runtime happens _only_
> via callbacks.  I don't need those callbacks to compute in parallel,
> generally, but it would be disappointing to hear that a callback
> strictly blocks execution of any others for its entire duration,
> for example even during a potentially slow I/O.
>
> (Will test for that, but not sure whether it would be conclusive
> since the system seems to be slightly broken at this point - need
> to disable RTS timer signals ( -V0 ) to survive externally generated
> thread dispatch events.)

This is slightly out of date (GHC couldn't multiplex haskell threads
onto multiple OS threads at the time, but now does), but basically
spells out the situation:

http://www.haskell.org/~simonmar/papers/conc-ffi.pdf

As for the specific question, callbacks do happen concurrently.

>
> thanks,
>        Donn Cave, d...@avvanta.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Work is punishment for failing to procrastinate effectively.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Preview the new haddock look and take a short survey

2010-08-04 Thread Ivan Lazar Miljenovic
Magnus Therning  writes:

> On Wed, Aug 4, 2010 at 06:00, Mark Lentczner  wrote:
>> The Haddock team has spent the last few months revamping the look of the 
>> generated output. We're pretty close to done, but we'd like to get the 
>> community's input before we put it in the main release.
>>
>> Please take a look, and then give us your feedback through a short survey
>>
>> Sample pages:  http://www.ozonehouse.com/mark/snap-xhtml/index.html
>
> I really like it, especially the synopsis tab on the right.  Brilliant!  The
> TOC is nice too!  The over-all impression is that it doesn't look as
> auto-generated as the old style.

Agreed; I'm also glad that the usage of a middle column isn't a fixed
width but resizes as the text resizes (the lack of this is something
that annoys me to no end on some websites).

>> Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html
>
> Also very good looking.  Does the current stable version of Haddock really
> create a frame version?
> I've never seen one before...

There is, but I for one don't use it (and there was an email sent out in
May asking if anyone did:
http://www.mail-archive.com/haskell-cafe@haskell.org/msg75269.html ).

I quite like this new approach, however, but with one caveat: the empty
frame on the bottom left at default.  Especially with my weird firefox
setup (which has almost grown organically over the years and should
really be wiped), it doesn't display too well; is it possible to have
_something_ there by default just to make it look more interesting
(Haskell logo, a message saying "stuff will appear here when you click
on something above", etc.) ?

However, I would still be highly tempted to use the framed version by
default with that new layout.

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] can Haskell do everyting as we want?

2010-08-04 Thread Alberto G. Corona
Just to clarify,  I mean: Haskell may be seriously addictive.  Sounds like a
joke, but it is not.  I do not recommend it for coding something quick and
dirty.

2010/8/4 Alberto G. Corona 

> Before entering haskell, please read our disclaimer:
>
> http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html
>
> You've been warned
> *
> *
>
> 2010/8/4 Zura_ 
>
>
>> As already noted here, Haskell is a general purpose language, but you
>> should
>> take it with a grain of salt.
>> For instance, you can nail with a laptop (provided that you hit the place
>> where a HDD is located), but you prefer a hammer :)
>> One thing is if you do it only for enjoyment, in this case you can even
>> develop 3D shooter game in Haskell, but when it comes to production/real
>> world use, I think it is better to maintain "right tool for the right job"
>> attitude.
>>
>> Regards,
>> Zura
>>
>>
>> Qi Qi-2 wrote:
>> >
>> > Is there anyone happen to come into any tasks that haskell is not able
>> > to achieve?
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176p29342871.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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] design question: decision tree from "Programming Collective Intelligence"

2010-08-04 Thread S. Doaitse Swierstra
I have added the permutation parsers from uulib to uu-parsinglib:

http://hackage.haskell.org/packages/archive/uu-parsinglib/2.5.1.1/doc/html/Text-ParserCombinators-UU-Perms.html,

where you find reference to the paper

Doaitse


On 22 jun 2010, at 09:24, Stephen Tetley wrote:

> Hello
> 
> Maybe "permutation trees" are a viable starting point?
> 
> See the paper "Parsing Permutation Phrases" which appears to be on CiteSeer.
> 
> Some slides are also here - the data type definitions and Functor
> instance for permutation trees are on page 18 (pdf index page 19):
> http://www.comlab.ox.ac.uk/jeremy.gibbons/wg21/meeting56/loeh-slides.pdf
> 
> An alternative implementation for applicative functors is here:
> http://hackage.haskell.org/package/action-permutations
> 
> Note the use of existentials here is pretty cunning, I didn't get very
> far the time I attempted to use the technique for my own purposes.
> 
> Best wishes
> 
> Stephen
> ___
> 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


  1   2   >