Re: [Haskell-cafe] Program for displaying graph state in lambda interpreter?

[Benjamin Redelings I]

On 06/01/2012 05:07 PM, Sean Leather wrote:

Hi Benjamin,

On Fri, Jun 1, 2012 at 9:54 PM, Benjamin Redelings wrote:

   I have written an interpreter that operates on the lambda
calculus augmented with letrec, constructors, case, primitive
objects, and builtin operations.  I'd like to display the internal
state of the intepreter at various points so that I can, um, debug
the "programs" that I've written.

   Currently I've got about 3500 nodes, and I'm dumping a graph
that I format using the 'dot' program in graphviz. 


[...]

   However, it would be nice to know of any programs that are
better suited for this.  For example, if I could write <>*<> and
draw arrows from the placeholders "<>" to the memory location
being referenced, that would be easier to read.  This is done here
http://en.wikibooks.org/wiki/Haskell/Graph_reduction to illustrate
that 'square (1+2)' doesn't evaluate 1+2 twice.  Any ideas?


This may not answer your question, but it might be related and/or helpful:

http://rochel.info/#graph-rewriting

Regards,
Sean

Thanks Sean,

The note on Very Lazy evaluation was quite interesting.

I can't directly use the graph rewriting libraries, though, since 
the interpreter is written in C++.


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

[Haskell-cafe] SafeSemapore

[Chris Kuklewicz]

This message is in three parts: a problem, a solution, and a request for help.

The problem is that Control.Concurrent.QSem, QSemN, and SampleVar are all still
broken.  GHC ticket #3160 is still open [1].  These three synchronization
mechanisms can be irretrievable broken by a killThread on a blocked waiter.

The solution is that I am please to announce that SafeSemaphore has been updated
to 0.9.0 on hackage [2] and github.  These provides safe solutions to replace
QSem and QSemN, actually several such solutions.  See the github [2] page
(scroll down for README) for a summary of all the modules.

The request for help is that I would like to unbreak the Haskell Platform by
replacing the guts of QSem, QSemN, and SampleVar with SafeSemaphore.

Do you think my replacement is correct or buggy?  Can we get #3160 closed?

Replacing these will preserve their API but may tinker with corner case
undocumented behavior.  Should waiters block in FIFO order?  Should QSemN starve
big or small requests to be fairer?

[1] http://hackage.haskell.org/trac/ghc/ticket/3160  (three years old!)
[2] http://hackage.haskell.org/package/SafeSemaphore/
[3] https://github.com/ChrisKuklewicz/SafeSemaphore

Sincerely,
  Chris Kuklewicz

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

Re: [Haskell-cafe] Program for displaying graph state in lambda interpreter?

[Ertugrul Söylemez]

Benjamin Redelings  wrote:

>  However, it would be nice to know of any programs that are better
> suited for this.  For example, if I could write <>*<> and draw arrows
> from the placeholders "<>" to the memory location being referenced,
> that would be easier to read.  This is done here
> http://en.wikibooks.org/wiki/Haskell/Graph_reduction to illustrate
> that 'square (1+2)' doesn't evaluate 1+2 twice.  Any ideas?

Have a look at Brent Yorgey's 'diagrams' package:



It does not do the automatic balancing that Graphviz does, but is a nice
generic drawing library for diagrams.  In particular I assume that the
initial graph of your programs is actually a tree, for which diagrams
should be very well suitable.


Greets,
Ertugrul

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez "
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/


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

Re: [Haskell-cafe] GHCi Loop Detection

[Michal Terepeta]

On 01.06 11:06, John Van Enk wrote:
> Hi Cafe,
> 
> Is there a reason that the GHCi interpreter doesn't detect and report
> infinite loops in statements like this (like compiled programs do) even
> though no CPU time appears to be used? My (admittedly weak) searching for
> an answer didn't turn much up.
> 
> let s | not $ null s = [] in s
> 
> GHCi v7.0.4 on OSX
> 
> Thanks,
> John

Hi John,

I think this is a known problem in GHCi:
http://hackage.haskell.org/trac/ghc/ticket/2786

Regards,
Michal

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

[Haskell-cafe] Re-exports of resourcet in conduit

[Myles C. Maxfield]

To: Michael Snoyman
CC: haskell-cafe

Hello,
I'm having a problem working with the conduit library, and was hoping
you could help me out.

Data.Conduit re-exports ResourceT, MonadResource, and MonadThrow (but
not ExceptionT) from Control.Monad.Trans.Resource. I have a conduit
which operates on a monad in the MonadThrow class. I am trying to
figure out which MonadThrow class this should be (the
Data.Conduit.MonadThrow class, or the
Montrol.Monad.Trans.Resource.MonadThrow class, since apparently GHC
doesn't recognize them as the same, even though one is just a
re-export of the other).

If a user of this conduit wants to chain this conduit up with
something like sourceFile, the underlying monad has to be a member of
Data.Conduit.MonadResource and whatever MonadThrow class I chose to
use. I would like to be able to use an existing instance to lift the
class of the inner monad to the class of the entire monad stack (so I
don't have to tell the user of my conduit that they have to define
their own instances), and the only rule that I can find that does that
is the following from Data.Conduit:

Data.Conduit.MonadThrow m => Data.Conduit.MonadThrow (Data.Conduit.ResourceT m)

However, GHC doesn't seem to think that
Control.Monad.Trans.Resource.ExceptionT is an instance of
Data.Conduit.MonadThrow:

No instance for (Data.Conduit.MonadThrow (ExceptionT IO))
  arising from a use of `.'

Control.Monad.Trans.Resource has a similar instance:

Control.Monad.Trans.Resource.MonadThrow m =>
Control.Monad.Trans.Resource.MonadThrow
(Control.Monad.Trans.Resource.ResourceT m)

but because sourceFile operates in the Data.Conduit.MonadResource
class, and Control.Monad.Trans.Resource.ResourceT isn't a member of
that class (it's only a member of
Control.Monad.Trans.Resource.MonadResource), that doesn't help:

No instance for (Data.Conduit.MonadResource
   (Control.Monad.Trans.Resource.ResourceT (ExceptionT IO)))
  arising from a use of `.'

It should be noted that neither module defines anything like the following:

MonadResource m => MonadResource (ExceptionT m)

It seems like the underlying problem here is that:
1) I am required to use the Control.Monad.Trans.Resource.ExceptionT
class, because Data.Conduit doesn't re-export it
2) I am required to use the Data.Conduit.MonadResource class, because
sourceFile and others require it
3) There doesn't seem to be an existing instance that bridges between the two.

This seems like a fundamental flaw with re-exporting; it can only work
if you re-export every single last thing from the original module.
This doesn't seem tenable because the orignal module might not be
under your control, so its author can add new symbols whenever he/she
wants to.

I see two solutions to this problem:
1) Re-export Control.Monad.Trans.Resource.ExceptionT in Data.Conduit.
This will work until someone adds something to the resourcet package
and someone wants to use the new addition and Data.Conduit.ResourceT
in the same stack
2) Don't re-export anything in Data.Conduit; make sourceFile and
others explicitly depend on types in another module, but this might
break compatibility with existing programs if they use fully-qualified
symbol names.
3) Make anyone who wants to use a monad stack in MonadThrow and
MonadResource define their own instances. This is probably no good
because it means that many different modules will implement the same
instance in potentially many different ways.

I feel like option 2) is probably the best solution here. I'm
perfectly happy to issue a pull request for whichever option you think
is best, but I don't know which solution you think is best for your
project. What do you think?

--Myles

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

Re: [Haskell-cafe] Re-exports of resourcet in conduit

[Antoine Latter]

Is it possible that you are puuling in two different versions of the
package that defines the MonadThrow class?

That is, package a was built against version 1, but package b was built
against version 2? This would make GHC think the type-class were
incompatable.

This is just a guess - I have not tried what you are trying.
On Jun 2, 2012 6:35 PM, "Myles C. Maxfield" 
wrote:

> To: Michael Snoyman
> CC: haskell-cafe
>
> Hello,
> I'm having a problem working with the conduit library, and was hoping
> you could help me out.
>
> Data.Conduit re-exports ResourceT, MonadResource, and MonadThrow (but
> not ExceptionT) from Control.Monad.Trans.Resource. I have a conduit
> which operates on a monad in the MonadThrow class. I am trying to
> figure out which MonadThrow class this should be (the
> Data.Conduit.MonadThrow class, or the
> Montrol.Monad.Trans.Resource.MonadThrow class, since apparently GHC
> doesn't recognize them as the same, even though one is just a
> re-export of the other).
>
> If a user of this conduit wants to chain this conduit up with
> something like sourceFile, the underlying monad has to be a member of
> Data.Conduit.MonadResource and whatever MonadThrow class I chose to
> use. I would like to be able to use an existing instance to lift the
> class of the inner monad to the class of the entire monad stack (so I
> don't have to tell the user of my conduit that they have to define
> their own instances), and the only rule that I can find that does that
> is the following from Data.Conduit:
>
> Data.Conduit.MonadThrow m => Data.Conduit.MonadThrow
> (Data.Conduit.ResourceT m)
>
> However, GHC doesn't seem to think that
> Control.Monad.Trans.Resource.ExceptionT is an instance of
> Data.Conduit.MonadThrow:
>
>No instance for (Data.Conduit.MonadThrow (ExceptionT IO))
>  arising from a use of `.'
>
> Control.Monad.Trans.Resource has a similar instance:
>
> Control.Monad.Trans.Resource.MonadThrow m =>
> Control.Monad.Trans.Resource.MonadThrow
> (Control.Monad.Trans.Resource.ResourceT m)
>
> but because sourceFile operates in the Data.Conduit.MonadResource
> class, and Control.Monad.Trans.Resource.ResourceT isn't a member of
> that class (it's only a member of
> Control.Monad.Trans.Resource.MonadResource), that doesn't help:
>
>No instance for (Data.Conduit.MonadResource
>   (Control.Monad.Trans.Resource.ResourceT (ExceptionT
> IO)))
>  arising from a use of `.'
>
> It should be noted that neither module defines anything like the following:
>
> MonadResource m => MonadResource (ExceptionT m)
>
> It seems like the underlying problem here is that:
> 1) I am required to use the Control.Monad.Trans.Resource.ExceptionT
> class, because Data.Conduit doesn't re-export it
> 2) I am required to use the Data.Conduit.MonadResource class, because
> sourceFile and others require it
> 3) There doesn't seem to be an existing instance that bridges between the
> two.
>
> This seems like a fundamental flaw with re-exporting; it can only work
> if you re-export every single last thing from the original module.
> This doesn't seem tenable because the orignal module might not be
> under your control, so its author can add new symbols whenever he/she
> wants to.
>
> I see two solutions to this problem:
> 1) Re-export Control.Monad.Trans.Resource.ExceptionT in Data.Conduit.
> This will work until someone adds something to the resourcet package
> and someone wants to use the new addition and Data.Conduit.ResourceT
> in the same stack
> 2) Don't re-export anything in Data.Conduit; make sourceFile and
> others explicitly depend on types in another module, but this might
> break compatibility with existing programs if they use fully-qualified
> symbol names.
> 3) Make anyone who wants to use a monad stack in MonadThrow and
> MonadResource define their own instances. This is probably no good
> because it means that many different modules will implement the same
> instance in potentially many different ways.
>
> I feel like option 2) is probably the best solution here. I'm
> perfectly happy to issue a pull request for whichever option you think
> is best, but I don't know which solution you think is best for your
> project. What do you think?
>
> --Myles
>
> ___
> 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-exports of resourcet in conduit

[Myles C. Maxfield]

It could be. Do you know how I can check which versions of packages other
packages have built against with Cabal? Will it help if I remove all the
relevant packages and then re-install only a single version?

Thanks,
Myles

On Saturday, June 2, 2012, Antoine Latter wrote:

> Is it possible that you are puuling in two different versions of the
> package that defines the MonadThrow class?
>
> That is, package a was built against version 1, but package b was built
> against version 2? This would make GHC think the type-class were
> incompatable.
>
> This is just a guess - I have not tried what you are trying.
> On Jun 2, 2012 6:35 PM, "Myles C. Maxfield" 
>  'myles.maxfi...@gmail.com');>>
> wrote:
>
>> To: Michael Snoyman
>> CC: haskell-cafe
>>
>> Hello,
>> I'm having a problem working with the conduit library, and was hoping
>> you could help me out.
>>
>> Data.Conduit re-exports ResourceT, MonadResource, and MonadThrow (but
>> not ExceptionT) from Control.Monad.Trans.Resource. I have a conduit
>> which operates on a monad in the MonadThrow class. I am trying to
>> figure out which MonadThrow class this should be (the
>> Data.Conduit.MonadThrow class, or the
>> Montrol.Monad.Trans.Resource.MonadThrow class, since apparently GHC
>> doesn't recognize them as the same, even though one is just a
>> re-export of the other).
>>
>> If a user of this conduit wants to chain this conduit up with
>> something like sourceFile, the underlying monad has to be a member of
>> Data.Conduit.MonadResource and whatever MonadThrow class I chose to
>> use. I would like to be able to use an existing instance to lift the
>> class of the inner monad to the class of the entire monad stack (so I
>> don't have to tell the user of my conduit that they have to define
>> their own instances), and the only rule that I can find that does that
>> is the following from Data.Conduit:
>>
>> Data.Conduit.MonadThrow m => Data.Conduit.MonadThrow
>> (Data.Conduit.ResourceT m)
>>
>> However, GHC doesn't seem to think that
>> Control.Monad.Trans.Resource.ExceptionT is an instance of
>> Data.Conduit.MonadThrow:
>>
>>No instance for (Data.Conduit.MonadThrow (ExceptionT IO))
>>  arising from a use of `.'
>>
>> Control.Monad.Trans.Resource has a similar instance:
>>
>> Control.Monad.Trans.Resource.MonadThrow m =>
>> Control.Monad.Trans.Resource.MonadThrow
>> (Control.Monad.Trans.Resource.ResourceT m)
>>
>> but because sourceFile operates in the Data.Conduit.MonadResource
>> class, and Control.Monad.Trans.Resource.ResourceT isn't a member of
>> that class (it's only a member of
>> Control.Monad.Trans.Resource.MonadResource), that doesn't help:
>>
>>No instance for (Data.Conduit.MonadResource
>>   (Control.Monad.Trans.Resource.ResourceT (ExceptionT
>> IO)))
>>  arising from a use of `.'
>>
>> It should be noted that neither module defines anything like the
>> following:
>>
>> MonadResource m => MonadResource (ExceptionT m)
>>
>> It seems like the underlying problem here is that:
>> 1) I am required to use the Control.Monad.Trans.Resource.ExceptionT
>> class, because Data.Conduit doesn't re-export it
>> 2) I am required to use the Data.Conduit.MonadResource class, because
>> sourceFile and others require it
>> 3) There doesn't seem to be an existing instance that bridges between the
>> two.
>>
>> This seems like a fundamental flaw with re-exporting; it can only work
>> if you re-export every single last thing from the original module.
>> This doesn't seem tenable because the orignal module might not be
>> under your control, so its author can add new symbols whenever he/she
>> wants to.
>>
>> I see two solutions to this problem:
>> 1) Re-export Control.Monad.Trans.Resource.ExceptionT in Data.Conduit.
>> This will work until someone adds something to the resourcet package
>> and someone wants to use the new addition and Data.Conduit.ResourceT
>> in the same stack
>> 2) Don't re-export anything in Data.Conduit; make sourceFile and
>> others explicitly depend on types in another module, but this might
>> break compatibility with existing programs if they use fully-qualified
>> symbol names.
>> 3) Make anyone who wants to use a monad stack in MonadThrow and
>> MonadResource define their own instances. This is probably no good
>> because it means that many different modules will implement the same
>> instance in potentially many different ways.
>>
>> I feel like option 2) is probably the best solution here. I'm
>> perfectly happy to issue a pull request for whichever option you think
>> is best, but I don't know which solution you think is best for your
>> project. What do you think?
>>
>> --Myles
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org > 'Haskell-Cafe@haskell.org');>
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/m