Re: [Haskell-cafe] Re: two problems with Data.Binary and Data.ByteString

[Duncan Coutts]

On Thu, 2008-08-28 at 21:34 +0200, Ben Franksen wrote:

 Just some raw ideas:
 
 What if we had a way to express 'optional dependencies' between packages in
 a cabal file. Something like 'if package x is installed (and satisfies
 given version constraints) then add module UseX'.
 
 One problem with this idea is that I might install the missing (optional)
 package afterwards, and then I still do not have the instance I would like
 (unless I re-build). Could cabal be instructed to re-build a package if an
 optional dependency becomes available (or if one gets removed)?

Right, requiring an order of installation is rather unfortunate. Always
rebuilding things doesn't really fit well with many deployment models.

Duncan

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

Re: [Haskell-cafe] Re: [Haskell] Top Level -

[Adrian Hey]

Brandon S. Allbery KF8NH wrote:


On 2008 Aug 28, at 20:45, Adrian Hey wrote:


Lennart Augustsson wrote:

If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today.  It would be Perl, ML, or Java.
The Haskell philosophy has always been to stick it out until someone
comes up with the right solution to a problem rather than picking some
easy way out.


BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's
not get too snobby about this. (Sorry, I couldn't resist.)



It's anything but easy; there are specific rules you need to follow, 
including use of certain compiler pragmas, to insure it works properly.


Yes, of course. The worst thing about all this is that the single most
common use case AFAICS (the one under discussion) isn't even a safe
use. Just pointing out that this pseudo function is certainly not
something one would expect from an organisation as dedicated to the
persuit of perfection as Lennart would have us believe. It's an
expedient hack. Not that I wish to seem ungrateful or anything :-)

Regards
--
Adrian Hey

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

Re: [Haskell-cafe] HEq and Context reduction stack overflow, non optimal ghc behaviour ?

[wren ng thornton]

Marc Weber wrote:

Now ghc can try to resolve (1),(2),(3) in arbitrary order..
What happens if ghc starts with (3)?
  It tries to find an instance for not known types..
  Damn. There is even a matching instance..
  , the same one. This time it starts even with 
  HEq unkown unkown unkown which is even more bad!

  after the second recursion it already knows that won't find a
  solution, because it will try to resolve 
  HEq unkown unkown unkown again and again..


What happens if ghc starts with (1 or 2)?
  It happily finds an instance *and* it can even resolve elNr and elNr'
  Those can then be used to find an instance for (3) easily
 
So I think the behaviour of ghc should be changed to prefer resolving

class constraints which reduce the amount of unkown types first

I even consider this beeing a bug ?

So maybe this thread should be moved to glasgow-haskell-users ?



There are a number of issues like this due to the fact that typeclass 
instances aren't determined by full SLD resolution. More particularly 
the determinism information in fundeps seems to be ignored in this whole 
process. Not that I'm a GHC hacker (yet), but research in this area is 
at the top of my to-do stack; alas that's still a ways away.


To put a refinement on your proposal, I'd suggest that fundeps be used 
to construct a dataflow graph in order to know which instances to pursue 
first (namely, the leaves). To resolve the ordering any toposort of the 
dataflow graph should be fine. This still has the problem of if there's 
no toposort, though:


class Foo a b | a - b
class Bar a b | b - a
class Wtf a b

instance (Foo a b, Bar a b) = Wtf a b

There are a few standard approaches to break the cycle, though if 
instances of Foo or Bar are given inductively we might run into the same 
problems as your code.



Here's another proposal, and perhaps an easier one to hack together for 
the time being. When pursuing the context of an instance for some class 
A, resolve all instances for non-A classes before pursuing instances for 
A. It's not a general solution, but it's closer to correct at least.


--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Propeganda

[wren ng thornton]

Richard A. O'Keefe wrote:


On 28 Aug 2008, at 8:34 am, Aaron Tomb wrote:
What type safety buys you, in my mind, is that Nothing is only a valid 
value for explicit Maybe types. In cases where you don't use Maybe, 
the null situation just can't occur. In languages with null 
pointers, any pointer could possibly be null.


This is not true of Eiffel.
The ECMA Eiffel standard has
?Teither a void reference or a reference to an instance of T
!Ta reference to an instance of T
 Tsame as !T in ECMA Eiffel; used to be same as ?T

I suppose you could call the detachable type ?T an *implicit* Maybe.
Needless to say, the switch in semantics of undecorated T helped to
fork the Eiffel community...



Just because the devil needs more advocacy... there are safer dialects 
of C that have non-nullable pointers in addition to the standard 
variety. Cyclone[1] comes to mind, there are others.


In so far as propaganda goes, imperative programming is ugly, unsafe, 
and evil, but it is getting better. Blanket statements about their 
failings tend toward falsity as they keep adopting things from the 
functional world.


[1] http://www.cs.bu.edu/groups/ibench/presentations/2003-04-10.pdf

--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Named field syntax

[Maurí­cio]

Hi,

I see that this works:

data Test = Test Integer String

This also works:

data Test = Test {a::Integer,b::String}

However, this doesn't:

data Test = Test Integer {b::String}

Is there some way to name only a single, or a few,
of some data type fields?

Thanks,
Maurício

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

Re: [Haskell-cafe] Named field syntax

[Ketil Malde]

Maurí­cio [EMAIL PROTECTED] writes:

 However, this doesn't work:

 data Test = Test Integer {b::String}

 Is there some way to name only a single, or a few,
 of some data type fields?

data Test = Test Integer String

b :: Test - String
b (Test i s) = s

:-)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Syntax of 'do'

[Maurí­cio]

Hi,

http://haskell.org/haskellwiki/Keywords says that:

-
[do is a] syntactic sugar for use with monadic
expressions. For example:

 do { x ; result - y ; foo result }

is shorthand for:

 x  y = \result - foo result
-

I did some tests hiding Prelude. and Prelude.=
and applying  and = to non-monadic types, and
saw that 'do' would not apply to them. So, I would
like to add the following to that text:

-
as long as proper types apply:

x :: Prelude.Monad a
y :: Prelude.Monad b
foo :: b - Prelude.Monad c
-

Is that correct (Haskell and English)?

Thanks,
Maurício

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

Re: [Haskell-cafe] Syntax of 'do'

[Miguel Mitrofanov]

-XNoImplicitPrelude ?

On 29 Aug 2008, at 17:41, Maurí cio wrote:


Hi,

http://haskell.org/haskellwiki/Keywords says that:

-
[do is a] syntactic sugar for use with monadic
expressions. For example:

do { x ; result - y ; foo result }

is shorthand for:

x  y = \result - foo result
-

I did some tests hiding Prelude. and Prelude.=
and applying  and = to non-monadic types, and
saw that 'do' would not apply to them. So, I would
like to add the following to that text:

-
as long as proper types apply:

x :: Prelude.Monad a
y :: Prelude.Monad b
foo :: b - Prelude.Monad c
-

Is that correct (Haskell and English)?

Thanks,
Maurício

___
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] Named field syntax

[Johannes Waldmann]

 data Test = Test Integer {b::String}

positional (= unnamed) record notation is a language design error :-)
and its use should be discouraged. - 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] Re: [Haskell] Top Level -

[Brandon S. Allbery KF8NH]

On 2008 Aug 29, at 4:22, Adrian Hey wrote:

Brandon S. Allbery KF8NH wrote:

On 2008 Aug 28, at 20:45, Adrian Hey wrote:

Lennart Augustsson wrote:

If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be  
the

language it is today.  It would be Perl, ML, or Java.
The Haskell philosophy has always been to stick it out until  
someone
comes up with the right solution to a problem rather than picking  
some

easy way out.


BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's
not get too snobby about this. (Sorry, I couldn't resist.)
It's anything but easy; there are specific rules you need to  
follow, including use of certain compiler pragmas, to insure it  
works properly.


Yes, of course. The worst thing about all this is that the single most
common use case AFAICS (the one under discussion) isn't even a safe
use. Just pointing out that this pseudo function is certainly not
something one would expect from an organisation as dedicated to the
persuit of perfection as Lennart would have us believe. It's an
expedient hack. Not that I wish to seem ungrateful or anything :-)



...but, as he noted, we *do* that until we find the right way to do it.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Syntax of 'do'

[Bulat Ziganshin]

Hello Mauri­cio,

Friday, August 29, 2008, 5:41:41 PM, you wrote:

afaik, this shorthand isn't exact. actually there is more code dealing
with fails and this code use Monad operations


 Hi,

 http://haskell.org/haskellwiki/Keywords says that:

 -
 [do is a] syntactic sugar for use with monadic
 expressions. For example:

   do { x ; result - y ; foo result }

 is shorthand for:

   x  y = \result - foo result
 -

 I did some tests hiding Prelude. and Prelude.=
and applying  and = to non-monadic types, and
 saw that 'do' would not apply to them. So, I would
 like to add the following to that text:

 -
 as long as proper types apply:

 x :: Prelude.Monad a
 y :: Prelude.Monad b
foo :: b - Prelude.Monad c
 -

 Is that correct (Haskell and English)?

 Thanks,
 Mauricio

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


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Named field syntax

[Brandon S. Allbery KF8NH]

On 2008 Aug 29, at 9:30, Maurí cio wrote:

However, this doesn't:

data Test = Test Integer {b::String}

Is there some way to name only a single, or a few,
of some data type fields?



There's no shorthand for it, no (and therefore you can't get one that  
works for pattern matching).  Personally, I haven't found it a  
hardship, because you can always used the unnamed field syntax.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Syntax of 'do'

[David House]

2008/8/29 Maurí­cio [EMAIL PROTECTED]:
 x :: Prelude.Monad a
 y :: Prelude.Monad b
 foo :: b - Prelude.Monad c

Monad is not a type, it is a type class, so you probably mean:

x :: Monad m = m a
y :: Monad m = m b
foo :: Monad m = b - m c

With the further understanding that all three `m's must be the same.

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

Re: [Haskell-cafe] Syntax of 'do'

[Philip Weaver]

On Fri, Aug 29, 2008 at 6:41 AM, Maurí­cio [EMAIL PROTECTED] wrote:

 Hi,

 http://haskell.org/haskellwiki/Keywords says that:

 -
 [do is a] syntactic sugar for use with monadic
 expressions. For example:

  do { x ; result - y ; foo result }

 is shorthand for:

  x  y = \result - foo result
 -

 I did some tests hiding Prelude. and Prelude.=
 and applying  and = to non-monadic types, and
 saw that 'do' would not apply to them. So, I would
 like to add the following to that text:


It sounds like you tried to redefine () and (=) and make 'do' use the
new definitions.  This is not possible, regardless of what types you give
() and (=).

If you want to define () and (=), do so for a particular instance of
Monad.


 -
 as long as proper types apply:

 x :: Prelude.Monad a
 y :: Prelude.Monad b
 foo :: b - Prelude.Monad c
 -

 Is that correct (Haskell and English)?

 Thanks,
 Maurício

 ___
 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] Syntax of 'do'

[David House]

2008/8/29 Philip Weaver [EMAIL PROTECTED]:
 It sounds like you tried to redefine () and (=) and make 'do' use the
 new definitions.  This is not possible, regardless of what types you give
 () and (=).

Watch out for rebindable syntax:
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax

At first reading, I thought that -XNoImplicitPrelude was required to
turn this on. But now I'm not sure: it seems that if you hide
Prelude.= and Prelude.return, that ought to be enough to make do
notation work with your alternative definitions. I'm not at home, so I
can't try this right now.

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

Re: [Haskell-cafe] Re: [Haskell] Top Level -

[Adrian Hey]

Brandon S. Allbery KF8NH wrote:

On 2008 Aug 29, at 4:22, Adrian Hey wrote:

Brandon S. Allbery KF8NH wrote:

On 2008 Aug 28, at 20:45, Adrian Hey wrote:

Lennart Augustsson wrote:

If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today.  It would be Perl, ML, or Java.
The Haskell philosophy has always been to stick it out until someone
comes up with the right solution to a problem rather than picking some
easy way out.


BTW, unsafePerformIO seems quite pragmatic and easy to me, so let's
not get too snobby about this. (Sorry, I couldn't resist.)
It's anything but easy; there are specific rules you need to follow, 
including use of certain compiler pragmas, to insure it works properly.


Yes, of course. The worst thing about all this is that the single most
common use case AFAICS (the one under discussion) isn't even a safe
use. Just pointing out that this pseudo function is certainly not
something one would expect from an organisation as dedicated to the
persuit of perfection as Lennart would have us believe. It's an
expedient hack. Not that I wish to seem ungrateful or anything :-)



...but, as he noted, we *do* that until we find the right way to do it.


So what's the problem with doing it *safely*, that is at least until
someone has found the mythic right way to do it.

Not that anybody has ever been able to offer any rational explanation
of what's *wrong* with the current proposed solution AFAICS.

Regards
--
Adrian Hey





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

Re: [Haskell-cafe] Haskell Speed Myth

[Isaac Gouy]

--- Don Stewart [EMAIL PROTECTED] wrote:

-snip
  How should the benchmarks game approach multicore?
 
 Well, there's a famous paper, 
 
 Algorithm + Strategy = Parallelism
 
 I'd imagine we use the benchmark game's algorithms, but let
 submitters determine the strategy. Then the results would show 
 
 a) how well you utilize the cores, and
 b) overall wall clock results.

otoh I see the attraction of showing parallelised versions alongside
existing programs; otoh that adds yet another layer of confusion about
why the measurements differ (and another level of quarreling about
whether even vaguely the same thing is being measured); otoh some
existing programs already use more cores when they can ...

The Scala threadring program shows 524s cpu but 157s elapsed:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadringlang=all


 
 I'm keen to get going on this, if only because I think we can turn
 out parallelised versions of many of the existing programs, fairly
 cheaply.

I'm always delighted that you're keen to get going on things like this!



The benchmarks game always seems to demand somewhat unnatural acts and
here's another - is there an effective way to /prevent/ ghc using
multiple cores when multiple cores are available? Can we force ghc to
only use one core on the quadcore machine? (Moreover can we do the same
trick for other languages?)



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

Re: [Haskell-cafe] Parsec and network data

[Donn Cave]

Quoth brian [EMAIL PROTECTED]:

| I want to use Parsec to parse NNTP data coming to me from a handle I
| get from connectTo.

Are you still having trouble with this?

Take my opinion for what it's worth - I'm no Haskell guru - but for me,
your basic approach is unsound.  I would implement the network service
input data stream myself, with timeouts, encryption, whatever as required,
and then apply the parser to available data as a simple, pure function
that returns NNTP results and whatever data remains.  So the parser would
never see any streams or handles or anything, it would just get strings
to parse.

Donn Cave, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Speed Myth

[Aaron Tomb]

On Aug 29, 2008, at 9:11 AM, Isaac Gouy wrote:


The benchmarks game always seems to demand somewhat unnatural acts and
here's another - is there an effective way to /prevent/ ghc using
multiple cores when multiple cores are available? Can we force ghc to
only use one core on the quadcore machine? (Moreover can we do the  
same

trick for other languages?)


There is indeed. In fact, GHC-compiled programs will only use multiple  
processors if you explicitly tell them to. To make use of two  
processors, for instance, you have to pass the flags '+RTS -N2' to the  
compiled executable when you run it. This tells it to schedule its  
internal threads on two OS threads, which the OS will presumably run  
on two processors if possible.


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

Re: [Haskell-cafe] Parsec and network data

[Johannes Waldmann]

Donn Cave wrote:

 ...  I would implement the network service
 input data stream myself, with timeouts, encryption, whatever as required,
 and then apply the parser to available data as a simple, pure function
 that returns NNTP results and whatever data remains.  So the parser would
 never see any streams or handles or anything, it would just get strings
 to parse.

A likely problem with that is that your implementation  of the input
data stream will still need to parse some information from it.
So you're going to replicate code from the parser.

I think the following is analoguous.

Imagine you're writing a parser for a simple programming language.
A program is a sequence of statements.
Fine, you do readFile (once) and then apply a pure Parsec parser.

Then you decide to include import statements in your  language.
Suddenly the parser needs to do IO. Assume the import statements
need not be the first statements  of the program
(there may be headers, comments etc. before).
Then you really have to interweave the parsing and the IO.

If anyone has a nice solution to this, please tell. - 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] Parsec and network data

[Derek Elkins]

On Fri, 2008-08-29 at 20:01 +0200, Johannes Waldmann wrote:
 Donn Cave wrote:
 
  ...  I would implement the network service
  input data stream myself, with timeouts, encryption, whatever as required,
  and then apply the parser to available data as a simple, pure function
  that returns NNTP results and whatever data remains.  So the parser would
  never see any streams or handles or anything, it would just get strings
  to parse.
 
 A likely problem with that is that your implementation  of the input
 data stream will still need to parse some information from it.
 So you're going to replicate code from the parser.
 
 I think the following is analoguous.
 
 Imagine you're writing a parser for a simple programming language.
 A program is a sequence of statements.
 Fine, you do readFile (once) and then apply a pure Parsec parser.
 
 Then you decide to include import statements in your  language.
 Suddenly the parser needs to do IO. Assume the import statements
 need not be the first statements  of the program
 (there may be headers, comments etc. before).
 Then you really have to interweave the parsing and the IO.
 
 If anyone has a nice solution to this, please tell. - J.W.

Using parsec3 you can just do exactly what you said.

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

Re: [Haskell-cafe] Parsec and network data

[brian]

On Fri, Aug 29, 2008 at 11:15 AM, Donn Cave [EMAIL PROTECTED] wrote:
 Quoth brian [EMAIL PROTECTED]:

 | I want to use Parsec to parse NNTP data coming to me from a handle I
 | get from connectTo.

 I would implement the network service
 input data stream myself, with timeouts

Could you explain a little about how this would look?

If it's reading characters trying to make a String we want to call a
'line', isn't that what the parser is supposed to be doing? If you
were parsing /etc/passwd, would you read each line yourself and give
each one to Parsec?

 So the parser would
 never see any streams or handles or anything, it would just get strings
 to parse.

Well, I think the parser still works with a Stream. For example,
Text/Parsec/ByteString.hs makes ByteString an instance of Stream.

My next try is to make this thing an instance of Stream:
data Connection = Connection
{ connectionHandle :: Handle
, connectionData   :: C.ByteString
}

In uncons, the easy case is when connectionData is nonnull. If it is
null, hWaitForInput on the handle. If we get something, read it and
return appropriate stuff. If not, it's a parse error similar to
getting unexpected EOF in a file.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] New Category Theory Intros

[Darrin Thompson]

These category theory intros were new to me. Thought others here might care.

http://golem.ph.utexas.edu/category/2008/08/new_structures_for_physics_i.html

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

Re: [Haskell-cafe] Compiler's bane

[Andrew Coppin]

Neil Mitchell wrote:

Hi

  

I'm writing a simple interpretter for a small extended-lambda-calculus sort
of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! _



Agreed :-)
  


I'm glad it's not just me! ;-)

(Oleg cat sez: see, yr type problum not so hard.)


To illustrate:

 let x = f x; y = 5 in x y

A simple-minded interpretter might try to replace every occurrance of x
with f x. This yields

 let y = 5 in (f x) y



That's wrong, its a two step transformation. You just substitute all
occurances of x for f x:

let x = f (f x); y = 5 in (f x) y

For the case let x = 5 in x, you do the same thing:

let x = 5 in 5

Now as a second step you hoover up unused let bindings and disguard:

5

You seem to be combining the substitution and the removing of dead let
bindings, if you separate them you should have more luck.
  


Right. So substitute in the RHS and then perform a let-cull afterwards. 
Got it.


I've been playing with this today, and no matter what rules I come up 
with, it seems to be ridiculously easy to put the interpretter into an 
infinite loop from which it will never escape. Is there any way to know 
which binds are worth expanding and which ones aren't? (I have a 
sinking feeling this might be equivilent to the Halting Problem...)


For example, if you have let x = f y; y = g x in x then since all the 
functions are free variables, there's really nothing much useful you 
can do to simplify this any further. However, my interpretter merrily 
goes into an endless loop building a huge expression like f (g (f (g (f 
(g... Is it possible to avoid this?


(The problem isn't unique to recursive let-binds of course. I discovered 
today that (\x - x x) (\x - x x) reduces to itself, so that puts the 
interpretter into a loop too. However, NON-recursive let-binds always 
terminate eventually. It's only the recursive ones that cause problems.)


My word, this stuff is really surprisingly hard! At least this time I 
built a general-purpose renamer rather than trying to avoid name capture 
by construction! ;-)



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

Re: [Haskell-cafe] Compiler's bane

[Jonathan Cast]

On Fri, 2008-08-29 at 20:56 +0100, Andrew Coppin wrote:
 Neil Mitchell wrote:
  Hi
 

  I'm writing a simple interpretter for a small extended-lambda-calculus sort
  of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! _
  
 
  Agreed :-)

 
 I'm glad it's not just me! ;-)
 
 (Oleg cat sez: see, yr type problum not so hard.)
 
  To illustrate:
 
   let x = f x; y = 5 in x y
 
  A simple-minded interpretter might try to replace every occurrance of x
  with f x. This yields
 
   let y = 5 in (f x) y
  
 
  That's wrong, its a two step transformation. You just substitute all
  occurances of x for f x:
 
  let x = f (f x); y = 5 in (f x) y
 
  For the case let x = 5 in x, you do the same thing:
 
  let x = 5 in 5
 
  Now as a second step you hoover up unused let bindings and disguard:
 
  5
 
  You seem to be combining the substitution and the removing of dead let
  bindings, if you separate them you should have more luck.

 
 Right. So substitute in the RHS and then perform a let-cull afterwards. 
 Got it.
 
 I've been playing with this today, and no matter what rules I come up 
 with, it seems to be ridiculously easy to put the interpretter into an 
 infinite loop from which it will never escape. Is there any way to know 
 which binds are worth expanding and which ones aren't? (I have a 
 sinking feeling this might be equivilent to the Halting Problem...)
 
 For example, if you have let x = f y; y = g x in x then since all the 
 functions are free variables, there's really nothing much useful you 
 can do to simplify this any further. However, my interpretter merrily 
 goes into an endless loop building a huge expression like f (g (f (g (f 
 (g... Is it possible to avoid this?

If you want to avoid infinite normal forms (or just plain lack of normal
forms, as in let x = x in x or (\x - x x) (\ x - x x)), you need to
follow three rules:

1) Static typing
2) No value recursion
3) If you allow data types, no recursive data types

Otherwise, your language will be Turing-complete, so yes, trying to
determine ahead of time if even a HNF exists will be the halting
problem.

If you really want to write a general-purpose evaluator, then infinite
normal forms may not be an issue, as long as they are generated lazily,
so your evaluator can at least print something out while it goes into an
infinite loop.  Otherwise, you can declare f x, where f is an unknown
function, a HNF, and stop at that point, or go on only under the
client's control.

The optimizers used by GHC and YHC pick one function out of each
recursive binding group, and just refuse to inline it at all.  If you
don't mind producing expressions that aren't really in any definable
HNF, that would be an alternative as well.

jcc


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

Re: [Haskell-cafe] Compiler's bane

[Conor McBride]

Hi

On 29 Aug 2008, at 21:12, Jonathan Cast wrote:



If you want to avoid infinite normal forms (or just plain lack of  
normal

forms, as in let x = x in x or (\x - x x) (\ x - x x)), you need to
follow three rules:

1) Static typing


With you there.


2) No value recursion


Mostly with you: might allow productive corecursion
computing only on demand.


3) If you allow data types, no recursive data types


I can think of a few Turing incomplete languages with
(co)recursive data types, so


Otherwise, your language will be Turing-complete,


seems suspect to me.

It's quite possible to identify a total fragment of
Haskell, eg, by seeing which of your Haskell programs
compile in Agda.

Things aren't as hopeless as you suggest.

Cheers

Conor

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

Re: [Haskell-cafe] Compiler's bane

[Jonathan Cast]

On Fri, 2008-08-29 at 21:48 +0100, Conor McBride wrote:
 Hi
 
 On 29 Aug 2008, at 21:12, Jonathan Cast wrote:
 
 
  If you want to avoid infinite normal forms (or just plain lack of  
  normal
  forms, as in let x = x in x or (\x - x x) (\ x - x x)), you need to
  follow three rules:
 
  1) Static typing
 
 With you there.
 
  2) No value recursion
 
 Mostly with you: might allow productive corecursion
 computing only on demand.
 
  3) If you allow data types, no recursive data types
 
 I can think of a few Turing incomplete languages with
 (co)recursive data types, so

  Otherwise, your language will be Turing-complete,
 
 seems suspect to me.

OK.  If you have any of

1) Dynamic typing, as implemented in say Scheme, or
2) Unlimited recursion, as implemented in say Haskell, or
3) Unlimited recursive data types, as implemented in say Haskell

your language is Turing-complete.

 It's quite possible to identify a total fragment of
 Haskell, eg, by seeing which of your Haskell programs
 compile in Agda.

 Things aren't as hopeless as you suggest.

OK.  There are intermediate cases that involve some suitably restricted
form of recursion.  I don't actually know anything about them, so I
won't comment on the suitability of such restrictions for Andrew's
interpreter.  But I should have remembered their existence.

jcc


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

Re: [Haskell-cafe] Named field syntax

[Roman Cheplyaka]

* Johannes Waldmann [EMAIL PROTECTED] [2008-08-29 15:39:15+0200]
  data Test = Test Integer {b::String}
 
 positional (= unnamed) record notation is a language design error :-)
 and its use should be discouraged. - J.W.

Polluting namespace with unneeded functions should not be encouraged
either. Consider for instance defining datatype for 3x3 matrix.
Would the absence of unnamed record notation make you more happy?

-- 
Roman I. Cheplyaka :: http://ro-che.info/
kzm: My program contains a bug. How ungrateful, after all I've done for it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsec and network data

[Donn Cave]

Quoth Johannes Waldmann [EMAIL PROTECTED]:
...
| I think the following is analoguous.
|
| Imagine you're writing a parser for a simple programming language.
| A program is a sequence of statements.
| Fine, you do readFile (once) and then apply a pure Parsec parser.
|
| Then you decide to include import statements in your  language.
| Suddenly the parser needs to do IO. Assume the import statements
| need not be the first statements  of the program
| (there may be headers, comments etc. before).
| Then you really have to interweave the parsing and the IO.

I think readFile might be where the analogy fails.  In a network
client like we were talking about, it's understood that you have to
interweave the parsing and I/O, to some extent.  From this point
of view, I don't see a problem with this programming language parser,
in fact I suppose I might indeed do it that way - maybe map the
file to a ByteString or something, would have to think about it.

Donn Cave, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsec and network data

[Donn Cave]

Quoth brian [EMAIL PROTECTED]:
| On Fri, Aug 29, 2008 at 11:15 AM, Donn Cave [EMAIL PROTECTED] wrote:
| Quoth brian [EMAIL PROTECTED]:
|
| | I want to use Parsec to parse NNTP data coming to me from a handle I
| | get from connectTo.
|
| I would implement the network service
| input data stream myself, with timeouts
|
| Could you explain a little about how this would look?
|
| If it's reading characters trying to make a String we want to call a
| 'line', isn't that what the parser is supposed to be doing? If you
| were parsing /etc/passwd, would you read each line yourself and give
| each one to Parsec?

You bet, given that passwd is a simple line record file and I'm reasonably
confident that hGetLine will do what I want for a disk file (or more or
less so, anyway, since while I don't want end of file to raise an exception,
I'm aware of work-arounds for this.)  On the other hand, for the very same
reason, I wouldn't worry too much about letting a parse function read the
data -- from a disk file.

With a network client, though, the value of those buffered I/O routines
isn't so obvious to me.  While it can be a convenient metaphor in some
common circumstances, a socket is not a file and the notion easily becomes
more trouble than it's worth.

I wouldn't read byte-by-byte, but rather read available data into my own
buffer.

Donn Cave, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -

[Ganesh Sittampalam]

On Thu, 28 Aug 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:

On Thu, 28 Aug 2008, Adrian Hey wrote:


There's no semantic difficulty with the proposed language extension,


How does it behave in the presence of dynamic loading?


To answer this you need to be precise about the semantics of what
is being dynamically loaded. But this is too complex an issue
for me to get in to right now.


If you want to standardise a language feature, you have to explain its 
behaviour properly. This is one part of the necessary explanation.


To be concrete about scenarios I was considering, what happens if:

 - the same process loads two copies of the GHC RTS as part of two 
completely independent libraries? For added complications, imagine that 
one of the libraries uses a different implementation instead (e.g. Hugs)


 - one Haskell program loads several different plugins in a way that 
allows Haskell values to pass across the plugin boundary


How do these scenarios work with use cases for - like (a) Data.Unique and 
(b) preventing multiple instantiation of a sub-library?


Actually as far as things like hs-plugins are concerned I'd alway meant 
one day what exactly a plugin is, semantically. But as I've never had 
cause to use them so never got round to it. Like is it a value, or does 
it have state and identity or what?


Personally I think of them as values. I'm not sure what your questions 
about state and identity mean. If you don't have global variables, then 
state doesn't matter.



What about remote procedure calls?


Dunno, what problem do you anticipate?


Will Data.Unique still work properly if a value is sent across a RPC 
interface?



Also what if I want a thread-local variable?


Well actually I would say that threads are bad concurrency model so
I'm not keen on thread local state at all. Mainly because I'd like to
get rid of threads, but also a few other doubts even if we keep
threads.


Even if you don't like them, people still use them.

(I.E. Just making existing practice *safe*, at least in the sense that 
the compiler ain't gonna fcuk it up with INLINING or CSE and every one 
understands what is and isn't safe in ACIO)


Creating new language features means defining their semantics rather more 
clearly than just no inlining or cse, IMO.


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

Re: [Haskell-cafe] Re: [Haskell] Top Level -

[Dan Weston]

C++ faced this very issue by saying that with global data, uniqueness of 
initialization is guaranteed but order of evaluation is not. Assuming 
that the global data are merely thunk wrappers over some common data 
source, this means that at minimum, there can be no data dependencies 
between plugins where the order of evaluation matters.


Another C++ comparison is with a virtual base class, where A::B::D and 
A::C::D are supposed to be equal, irrespective of whether it was B or C 
that first called the constructor. In this case, some witness (a vtable) 
is necessary to ensure that this happens correctly.


Dan

Ganesh Sittampalam wrote:

On Thu, 28 Aug 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:

On Thu, 28 Aug 2008, Adrian Hey wrote:


There's no semantic difficulty with the proposed language extension,


How does it behave in the presence of dynamic loading?


To answer this you need to be precise about the semantics of what
is being dynamically loaded. But this is too complex an issue
for me to get in to right now.


If you want to standardise a language feature, you have to explain its 
behaviour properly. This is one part of the necessary explanation.


To be concrete about scenarios I was considering, what happens if:

 - the same process loads two copies of the GHC RTS as part of two 
completely independent libraries? For added complications, imagine that 
one of the libraries uses a different implementation instead (e.g. Hugs)


 - one Haskell program loads several different plugins in a way that 
allows Haskell values to pass across the plugin boundary


How do these scenarios work with use cases for - like (a) Data.Unique 
and (b) preventing multiple instantiation of a sub-library?


Actually as far as things like hs-plugins are concerned I'd alway 
meant one day what exactly a plugin is, semantically. But as I've 
never had cause to use them so never got round to it. Like is it a 
value, or does it have state and identity or what?


Personally I think of them as values. I'm not sure what your questions 
about state and identity mean. If you don't have global variables, then 
state doesn't matter.



What about remote procedure calls?


Dunno, what problem do you anticipate?


Will Data.Unique still work properly if a value is sent across a RPC 
interface?



Also what if I want a thread-local variable?


Well actually I would say that threads are bad concurrency model so
I'm not keen on thread local state at all. Mainly because I'd like to
get rid of threads, but also a few other doubts even if we keep
threads.


Even if you don't like them, people still use them.

(I.E. Just making existing practice *safe*, at least in the sense that 
the compiler ain't gonna fcuk it up with INLINING or CSE and every one 
understands what is and isn't safe in ACIO)


Creating new language features means defining their semantics rather 
more clearly than just no inlining or cse, IMO.


Ganesh
___
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: [Haskell] Top Level -

[Bryan O'Sullivan]

On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston [EMAIL PROTECTED] wrote:
 C++ faced this very issue by saying that with global data, uniqueness of
 initialization is guaranteed but order of evaluation is not.

In C++ circles, this is referred to as the static initialization
order fiasco, and it is a frequent cause of crashes that are very
difficult to debug.

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12

I think it would be fair to say that C++ pushed this problem off to
every user of the language. I haven't seen a coherent description of
what the semantics of top-level - should be, but avoidance of
widespread swearing would be at the top of my list of requirements.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -

[Dan Weston]

I actually was more interested in the problems with the obvious fix 
for this, namely the construct on first use idiom:


int A(int a) { static int aa = a; return aa; }
int B()  { return A(3); }
int C()  { return A(7); }
int D()  { if (today() == Tuesday) B(); else C(); return a(0); }

What is the value of D? Notice that this is never a problem with pure 
functions. The problem is that today() makes this an IO monad, and the 
swearing starts again.


Dan

Bryan O'Sullivan wrote:

On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston [EMAIL PROTECTED] wrote:

C++ faced this very issue by saying that with global data, uniqueness of
initialization is guaranteed but order of evaluation is not.


In C++ circles, this is referred to as the static initialization
order fiasco, and it is a frequent cause of crashes that are very
difficult to debug.

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12

I think it would be fair to say that C++ pushed this problem off to
every user of the language. I haven't seen a coherent description of
what the semantics of top-level - should be, but avoidance of
widespread swearing would be at the top of my list of requirements.





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

Re: [Haskell-cafe] Re: [Haskell] Top Level -

[Adrian Hey]

Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC 
interface?


A value of type Unique you mean? This isn't possible. Data.Unique has
been designed so cannot be Shown/Read or otherwise
serialised/deserialised (for obvious reasons I guess).


Also what if I want a thread-local variable?


Well actually I would say that threads are bad concurrency model so
I'm not keen on thread local state at all. Mainly because I'd like to
get rid of threads, but also a few other doubts even if we keep
threads.


Even if you don't like them, people still use them.


AFAICS this is irrelvant for the present discussions as Haskell doesn't
support thread local variable thingies. If it ever does being precise
about that is someone elses problem. For the time being the scope
of IORefs/MVars/Chans is (and should remain) whatever process is
described by main (whether or not they appear at top level).

(I.E. Just making existing practice *safe*, at least in the sense that 
the compiler ain't gonna fcuk it up with INLINING or CSE and every one 
understands what is and isn't safe in ACIO)


Creating new language features means defining their semantics rather 
more clearly than just no inlining or cse, IMO.


I wouldn't even know how to go about that to the satisfaction of
purists. But global variables *are* being used whether or not the top
level - bindings are implemented. They're in the standard libraries!

So if this stuff matters someone had better figure it out :-)

Regards
--
Adrian Hey

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

Re: [Haskell-cafe] Re: [Haskell] Top Level -

[Adrian Hey]

Bryan O'Sullivan wrote:

I haven't seen a coherent description of
what the semantics of top-level - should be, but avoidance of
widespread swearing would be at the top of my list of requirements.


Don't the ACIO monad properties satisfy you?

Anyway, as I pointed out in my last post, if this is a problem
with top level - ACIO monad bindings it's still going to be
a problem (probably much worse) with unsafePerformIO hack IO
monad bindings.

This problem isn't just going to go away, no matter how long
it's ignored :-)

Regards
--
Adrian Hey

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

[Haskell-cafe] ANN: vxml (validating xml lib) - proof of concept - need some guidance - bad type level performance (ghc)

[Marc Weber]

Hi @ll.

This shouldn't have been an announce yet.. it's more crying for help to
get to know how / wether to continue :-)

I had an idea: a xml generating library validating the result against a
given dtd (to be used in web frameworks etc .. )

After one week of coding I got the result

git clone git://mawercer.de/vxml (1) (see README)
git hash as of writing : 4dc53

A minimal example looks like this (taken from test.hs):

  import Text.XML.Validated.TH

  $( dtdToTypes dtds/xhtml1-20020801/DTD/xhtml1-strict_onefile.dtd 
(XmlIds (Just -//W3C//DTD XHTML 1.0 Strict//EN) 
(Just 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;) ) )

  main = putStrLn $ xml $ ((html  (head  (title  vxml hello world)))
  (body  (div  PCDATA text )) )

Which takes about 7 secs to compile on my (fast) 2.5 Ghz machine.
Before Oleg telling me about how to use the TypeEq implementation found
in HList it took several hours (switch the cabal configure flag to see
experience the incredible slow TypeToNat implementation)

However type checking the simple small document (2) already takes 35
seconds, duplicating the tags within the body raises compilation
time to 74 seconds. (Have a look at test/XmlToQ.hs to automatically
create the code generating such a given xml file (its used in
run-testcases.hs)

The dtd representation used is very easy to understand:
(3a) shows allowed subelements of the head tag
  Seq = sequence
  Star = zero or more
  ...
(3b)
  shows the list of allowed attributes

for a more commonly used tag such as div the element list (3a) is 324 lines
long and there are approximately 15 attributes.

Use a line such as 
  putStrLn $ xml $ debugEl div
to get this view.


All the work is done by

  class Consume st el r | st el - r -- result is on of C,CS,R,F 
  class Retry elType st el st' | st el - st'

  st = state as given in (3a)
  el = child to be added (Elem Html_T) or PCDATA

  C = element consumed, end
  CS a = element consumed, continue with state a
  R a = retry with given state (can happen after removing a Star = ()*
on a no match )
  F a = no match, show failure a

  instance Retry elType C el C
  instance Retry elType (CS st) el st
  instance ( -- retry 
Consume st el r
, Retry elType r el st'
) = Retry elType (R st) el  st'

Maybe you knowing much more about ghc internals have some more
ideas how to optimize? I only came up with

a) implement
  xml HTrue $ xmldoc -- type checking variant 
  xml HFalse $ xmldoc -- unchecked but faster variant
  so you can run xml HTrue once a day only while having lunch..
 ( doubt Maybe you have to take lunch two or more times on intermediate 
  web projects .. )

b)  change (A attrType) to attrType only
 and (Elem e) to e
  which does not work for the same reason as
class TypeEq a b c | a b - c
instance TypeEq a a HTrue
instance TypeEq a b HFalse
  doesn't.
  Of course a a will match a b as well, but the result is totally
  different..
  So would it be possible to either tell ghc to ignore this happily
  taking the result of the better matching instance?

  Or to explicitely tell ghc when an instance matches the way it does in
  current implementations make it a no match if some constraints can or
  cannot be satisfied such as this:

class TypeEq a b c | a b - c
instance TypeEq a a HTrue
instance [ NoMatchOn a b -- if this can be satisfied ignore this instance 
 ] = TypeEq a b HFalse
class NoMatchOn a b
instance NoMatchOn a a

c) Having a reduction rule such as this:
  If the left side of (Or a b) returnns C (consumed) tell ghc to not
  evaluate the result of (Consume b element result) which must be done
  to see wether there is closer instance match (Is this correct ?)


Of course not everything is implemented yet.. but except speed I
consider it beeing quite usable.

He, thanks for reading till the end. Any feedback and suggestions
are appreciated. If you have any trouble contact me on irc.

I've been using
  $ ghc --version
  The Glorious Glasgow Haskell Compilation System, version 6.8.2

Sincerly
Marc Weber


(1) If you are interested and either don't have git or are not familiar
using it I can send you a tarball.

(2)

  !DOCTYPE html SYSTEM /tmp/dtd.dtd
  html xmlns=http://www.w3.org/1999/xhtml; lang=en-US xml:lang=en-US
  head
titleExample 6 - XHTML 1.0 Strict as application/xhtml+xml/title
meta http-equiv=Content-Type content=application/xhtml+xml; 
charset=utf-8 /
link rel=stylesheet type=text/css href=style.css /
  /head
  body
h1Example 6 - XHTML 1.0 Strict as application/xhtml+xml/h1
p
 This document is valid XHTML 1.0 Strict served as
 codeapplication/xhtml+xml/code.
/p
   
p
This document references CSS rules contained in an external
stylesheet via codelink/code.
/p
   
p
Note how the CSS rules for the background are applied in Netscape 7.x,
Mozilla, Opera 7 but that 

[Haskell-cafe] Re: Syntax of 'do'

[Maurí­cio]

 It sounds like you tried to redefine () and
 (=) and make 'do' use the new definitions.
 This is not possible, regardless of what types
 you give () and (=).

 Watch out for rebindable syntax: (...)

 At first reading, I thought that
 -XNoImplicitPrelude was required to turn this
 on. But now I'm not sure: (...)

I wrote this test to check your sugestion. It does
build with -XNoImplicitPrelude, but not without
it:

--
module Test where {
import Prelude hiding ( (  ) , ( = ) ) ;

 data PseudoMonad a = PseudoMonad a ;
 (  ) = \(PseudoMonad x) (PseudoMonad _) - PseudoMonad x ;
 ( = ) = (\(PseudoMonad a) f - f a)
 :: PseudoMonad Integer - (Integer - PseudoMonad Integer)
 - PseudoMonad Integer;
 plusOne n = (PseudoMonad (n + 1))
 :: PseudoMonad Integer;
 c = (PseudoMonad 1)  ((PseudoMonad 2) = (\n - plusOne n));
 d = do {(PseudoMonad 1) ; a - (PseudoMonad 2) ; plusOne a }
}
--

It's interesting that the types involved in =
etc. should still be like t t1, that's why I had
to create PseudoMonad. Using just Integer (i.e., 2
 3 would be valid) doesn't work, even if all
operators are defined accordingly.

Best,
Maurício

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

Re: [Haskell-cafe] Syntax of 'do'

[Philip Weaver]

On Fri, Aug 29, 2008 at 8:50 AM, David House [EMAIL PROTECTED] wrote:

 2008/8/29 Philip Weaver [EMAIL PROTECTED]:
  It sounds like you tried to redefine () and (=) and make 'do' use the
  new definitions.  This is not possible, regardless of what types you give
  () and (=).

 Watch out for rebindable syntax:

 http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax



Oh, I had no idea!  Thanks :).



 At first reading, I thought that -XNoImplicitPrelude was required to
 turn this on. But now I'm not sure: it seems that if you hide
 Prelude.= and Prelude.return, that ought to be enough to make do
 notation work with your alternative definitions. I'm not at home, so I
 can't try this right now.



 --
 -David

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

Re: [Haskell-cafe] Named field syntax

[Philip Weaver]

On Fri, Aug 29, 2008 at 1:59 PM, Roman Cheplyaka [EMAIL PROTECTED] wrote:

 * Johannes Waldmann [EMAIL PROTECTED] [2008-08-29
 15:39:15+0200]
   data Test = Test Integer {b::String}
 
  positional (= unnamed) record notation is a language design error :-)
  and its use should be discouraged. - J.W.

 Polluting namespace with unneeded functions should not be encouraged
 either. Consider for instance defining datatype for 3x3 matrix.
 Would the absence of unnamed record notation make you more happy?


Also, if positional record notation is a design error, then is it also a
design error not to require all arguments to be explicitly associated with
named formal parameters at a function call site (e.g. f(x = 1, y = 2, z =
3))?



 --
 Roman I. Cheplyaka :: http://ro-che.info/
 kzm: My program contains a bug. How ungrateful, after all I've done for it.
 ___
 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] ANN: LogFloat 0.9

[wren ng thornton]

-- Announcing: logfloat 0.9.1


New official release of the logfloat package for manipulating log-domain 
floating numbers. This release is mainly for those who are playing with 
Transfinite rather than LogFloat, but the interface changes warrant a 
minor version change.


If you're just using the LogFloat stuff you shouldn't notice any changes 
except that the constructors/destructors may be a bit pickier about 
being used when a polymorphic return type is expected.




-- Changes


* John Meacham pointed out that the Num and Ord superclasses on 
Transfinite may be onerous due to the growing disaffection with the 
Prelude. The Num requirement has been lifted, and the Ord requirement 
has been weakened to the new PartialOrd class.


* Introduced a new class for partially ordered types: PartialOrd.

* The transfinite-value respecting logarithm has been moved from 
Data.Number.LogFloat to Data.Number.Transfinite because it's more 
appropriate there. (It's still reexported by Data.Number.LogFloat.)


* In the continuing battle between transfinite values and Rationals, 
I've added a new class RealToFrac for overloading the Prelude's 
realToFrac function. On GHC, primitive converters are used to improve 
both performance and correctness. For non-GHC compilers, only a few 
generic instances are given. For an older discussion on this topic, see:


http://www.haskell.org/pipermail/haskell-prime/2006-February/000791.html

* Due to all this development on trying to solve the issues of 
transfinite values, the stability of the package has been changed from 
stable to provisional.




-- Future Extensions


* A strict version. The current lazy version will move to 
Data.Number.LogFloat.Lazy, and the strict version will be the standard 
one in Data.Number.LogFloat


* A signed version in Data.Number.LogFloat.Signed

* A test suite



-- Links


Homepage:
http://code.haskell.org/~wren/

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

Darcs:
http://code.haskell.org/~wren/logfloat

Haddock (Darcs version):
http://code.haskell.org/~wren/logfloat/dist/doc/html/logfloat/

--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANN: LogFloat 0.9

[Don Stewart]

wren:
 
 -- Announcing: logfloat 0.9.1
 
 
 New official release of the logfloat package for manipulating log-domain 
 floating numbers. This release is mainly for those who are playing with 
 Transfinite rather than LogFloat, but the interface changes warrant a 
 minor version change.

And in Arch Linux

http://aur.archlinux.org/packages.php?ID=18832

-- Don (come on packagers!)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe