[Haskell-cafe] FPGA / Lava and haskell

[Satnam Singh]

Hello Marc.

I've been distracted with the Kiwi project (parallel C# programs to hardware) 
and right now a Bluespec project so I've not made any progress on a merge of 
the Lava I produced for designing circuits (with layout) for Xilinx's FPGAs and 
the Chalmers version (which I recommend for situations where you don't care 
about circuit layout or when you don't want to use FPGA architecture specific 
features). The version of Lava on my website at http://raintown.org/lava/  
still builds under the current version of ghc and it provides support for 
generating Xilinx EDIF netlists that supports the basic FPGA circuit building 
blocks. If you need things like ODDRs etc. which appear in the new FPGAs then 
you have to either add them yourself (not too difficult) or wait for me to do 
it :)

Cheers,

Satnam


Satnam Singh
Microsoft
7 JJ Thomson Avenue
Cambridge
CB3 0FB
United Kingdom

Email: [EMAIL PROTECTED]
UK tel: +44 1223 479905
Fax: +44 1223 479 999
UK mobile: +44 7979 648412
USA cell: 206 330 1580
USA tel: 206 219 9024
URL: http://research.microsoft.com/~satnams
Live Messenger: [EMAIL PROTECTED]

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

[Haskell-cafe] ANN: Takusen 0.8.3

[Alistair Bayley]

Changes since 0.8.1 (I put 0.8.2 up on hackage with an error in Setup.hs,
so it's been skipped):

 - ODBC support: datetime marshalling is improved. For bind parameters
   this uses the timestamp struct for most back-ends, but String for
   MS SQL Server because populating the timestamp struct always failed.

 - more Cabal improvements: now uses configurations, so the Setup.hs
   script should be both simpler and more robust. Requires Cabal >= 1.4.
   Oracle backend on Linux should build nicely.

 - bug fix for a resource leak if an exception was thrown when initiating
   a query (the Statement handle was not closed).

 - some basic result-set validation against the iteratee: if you try to
   fetch a column that is not in the result-set, an error is thrown
   (rather than garbage returned).


The release bundle:
  http://hackage.haskell.org/packages/archive/Takusen/0.8.3/Takusen-0.8.3.tar.gz
The latest code:
  darcs get http://darcs.haskell.org/takusen
Docs:
  http://darcs.haskell.org/takusen/doc/html/index.html

A comprehensive description of API usage can be found in the documentation
for module Database.Enumerator (look for the Usage section):
  http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html


Future plans:

 - Output bind-parameters and multiple-result sets for ODBC

 - FreeTDS backend (Sybase and MS Sql Server)

 - support for Blobs and Clobs


For those of you unfamiliar with Takusen, here is our HCAR blurb:

Takusen is a DBMS access library. Like HSQL and HDBC, we support
arbitrary SQL statements (currently strings, extensible to anything
that can be converted to a string).

Takusen's 'unique-selling-point' is safety and efficiency.
We statically ensure all acquired database resources - such
as cursors, connection and statement handles - are released, exactly
once, at predictable times. Takusen can avoid loading the whole result
set in memory, and so can handle queries returning millions of rows in
constant space. Takusen also supports automatic marshalling and
unmarshalling of results and query parameters. These benefits come
from the design of query result processing around a left-fold
enumerator.

Currently we fully support ODBC, Oracle, Sqlite, and PostgreSQL.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Combining Wouter's expressions with extensible records

[Ron Alford]

What's odd is that it works directly (typeOf ... (Expr (f :+: g))
returns a type), but if you enclose the expression in a list, it fails
with Prelude.undefined.  Do I also need a custom instance for
Typeable [Expr ...] ? (See previous message for code)

-Ron



On Fri, Jul 11, 2008 at 1:56 AM, Antoine Latter <[EMAIL PROTECTED]> wrote:
> 2008/7/10 Ron Alford <[EMAIL PROTECTED]>:
>> Ok, I'm closer, but I'm running into a problem with typeOf and lists,
>> of all things:
>> *WouterTest> typeOf (eVar "v" :: TermExpr)
>> Planning.Wouter.Expr (Planning.Wouter.:+: WouterTest.Const WouterTest.Var)
>> *WouterTest> typeOf ([eVar "v"] :: [TermExpr])
>> *** Exception: Prelude.undefined
>>
>> I'm pretty sure this is the culprit for getName:
>> *WouterTest> getName testNamed
>> "*** Exception: Prelude.undefined
>>
>> Any hints?
>>
>> Also, anyone have hints for how to get automatic derivation of Data (Expr f) 
>> ?
>> I don't want to proliferate the last lines:
>> deriving instance Data (Expr (And :+: Atomic (Expr (Const :+: Var
>> deriving instance Data (Expr (Const :+: Var))
>>
>>
>
>
> I screwed up the example code - it typechecks, but it'll fail at runtime.
>
> If you say:
>
>> Inr x = undefined
>
> and then try to pass 'x' off to another function, you're trying to
> evaluate the "undeifned", which is a runtime error.
>
> You'll want something more like:
>
> typeOf1 in@(InR f) = [...]
>   where InL f = (InL undefined) `asTypeOf` in
>
> This is approaching silliness, but I've tested the code this time
> around - so it should even work.
>
> -Antoine
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inductive graphs memory usage

[Gökhan San]

On Friday July 11 2008, Andre Nathan wrote:
> On Thu, 2008-07-10 at 16:52 -0700, Don Stewart wrote:
> > Well, they're radically different graph representations, and fgl
> > hasn't been designed for large graphs.
>
> Do you know if King and Launchbury's implementation (Data.Graph) scales
> better?

Looks like it.

I now did a rough benchmark on fully connected graphs with 25 and 50 nodes. 
Data.Graph.Inductive used 28MB and 365MB respectively (x13 increase) compared 
to Data.Graph's 486KB and 2MB (x4). And Data.Graph seems to be much faster 
(basic operations up to 200 times), although it might be related to GC.

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

Re: [Haskell-cafe] Newbie: Appending arrays?

[Dmitri O.Kondratiev]

I don't quite understand how Data.Array.Diff work.
I tried this:

> let arr = listArray (1,3) [1..3] :: DiffArray Int Int

then:
> replaceDiffArray arr [(1, 777)]
array (1,3) [(1,1),(2,777),(3,3)]
Why when replacing first element the second one changes?

and also trying to add 4-th element results in:
Prelude Data.Array.Diff> replaceDiffArray arr [(4, 444)]
array (1,3) [(1,1),(2,2),(3,3)]

It looks like replaceDiffArray can not be used to add new element to the end
of array?


Thanks,
Dima

On Thu, Jul 10, 2008 at 10:59 PM, Jefferson Heard <
[EMAIL PROTECTED]> wrote:

> Two questions.  How often does the array change, and how big does it
> get?  It may well be that you just copy it and take the hit, as
> that'll be cheaper (even in C, incidentally) than any other solution,
> if it's a short array or if the updates happen rarely.
>
> If not, try using Data.Array.Diff and replaceDiffArray.  This is
> usually fairly efficient for most applications.
>
> By the way, depending on the type of the data you're putting into
> these arrays, Data.ByteString might be a good choice as well.
>
> On Thu, Jul 10, 2008 at 12:12 PM, Felipe Lessa <[EMAIL PROTECTED]>
> wrote:
> > 2008/7/10 Dmitri O.Kondratiev <[EMAIL PROTECTED]>:
> >> allows construct an array of a fixed size. How to add more elements to
> the
> >> array later?
> >
> > I can't really answer your question, however I bet that it would
> > require allocating another, bigger array and copying the old elements
> > over, at least from time to time. So you may want to take a look at
> > Data.Sequence[1], supporting O(1) append on both sides and (sort of)
> > O(log i) for accessing the i-th element.
> >
> > [1]
> http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Sequence.html
> >
> > HTH,
> >
> > --
> > Felipe.
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> I try to take things like a crow; war and chaos don't always ruin a
> picnic, they just mean you have to be careful what you swallow.
>
> -- Jessica Edwards
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Associative Commutative Unification

[John D. Ramsdell]

> Are you aware of "Term Rewriting and all That"? It describes how to do
> associative commutative unification; whether it satisfies your
> 'obviously correct' criterion I don't know.

Oh yes, I know about term rewriting.  If your equations can be
expressed as a set of confluent rewrite rules, one can use the
Martelli and Montanari's formalization of unification to come up with
an obviously correct equational unifier.  Alas, that simple trick
doesn't work for AC unification.

Have you heard of Maude?  I hear the next version will have support
for AC unification.  If I stay with Haskell, I'd have to use their
support via interprocess communication.  Yuck.

http://maude.cs.uiuc.edu/

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

Re: [Haskell-cafe] Associative Commutative Unification

[Janis Voigtlaender]

John D. Ramsdell wrote:

Are you aware of "Term Rewriting and all That"? It describes how to do
associative commutative unification; whether it satisfies your
'obviously correct' criterion I don't know.



Oh yes, I know about term rewriting. 


I think Edsko was more specifically referring to the book "Term
Rewriting and all That" by Baader and Nipkow.

--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Newbie: Appending arrays?

[Chaddaï Fouché]

2008/7/11 Dmitri O.Kondratiev <[EMAIL PROTECTED]>:
> I don't quite understand how Data.Array.Diff work.
> I tried this:
>
>> let arr = listArray (1,3) [1..3] :: DiffArray Int Int
>
> then:
>> replaceDiffArray arr [(1, 777)]
> array (1,3) [(1,1),(2,777),(3,3)]
> Why when replacing first element the second one changes?

replaceDiffArray is low-level, nobody should use it, use the normal
IArray interface instead.
(To answer your question, replaceDiffArray works with low level index,
not the Ix class, all array are indexed by 0, 1, .. for it, so 1 is
the index of the second element of the array)

> and also trying to add 4-th element results in:
> Prelude Data.Array.Diff> replaceDiffArray arr [(4, 444)]
> array (1,3) [(1,1),(2,2),(3,3)]
>
> It looks like replaceDiffArray can not be used to add new element to the end
> of array?

No, the size of a DiffArray can't be changed : DiffArray are just an
IArray instance with better performances for update than the classic
IArray instance (which copy the entire content on every update...).

There are some libraries that allows you to change the size of your
array, be aware though that this operation is very costly (in every
language).
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ArrayRef

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

Re: [Haskell-cafe] More idiomatic use of strictness

[Grzegorz Chrupala]

Don Stewart-2 wrote:
> 
> I'd use a strict pair and the rnf strategy.
> 
> data P = P [Something] !Int
> 
> rnf dfs' (P dfs' (n+1)
> 

Thanks all, it definitely seems like an improvement.
--
Grzegorz
-- 
View this message in context: 
http://www.nabble.com/More-idiomatic-use-of-strictness-tp18379800p18403657.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

Re[2]: [Haskell-cafe] Newbie: Appending arrays?

[Bulat Ziganshin]

Hello Chaddai,

Friday, July 11, 2008, 4:58:00 PM, you wrote:

> There are some libraries that allows you to change the size of your
> array, be aware though that this operation is very costly (in every
> language).
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ArrayRef

or http://haskell.org/haskellwiki/Library/ArrayRef for reference


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Newbie: Appending arrays?

[Dmitri O.Kondratiev]

How does Data.Sequence
http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Sequence.html
compares with ArrayRef for appending and accessing arrays efficiently ?

On Fri, Jul 11, 2008 at 4:58 PM, Chaddaï Fouché <[EMAIL PROTECTED]>
wrote:

> 2008/7/11 Dmitri O.Kondratiev <[EMAIL PROTECTED]>:
> > I don't quite understand how Data.Array.Diff work.
> > I tried this:
> >
> >> let arr = listArray (1,3) [1..3] :: DiffArray Int Int
> >
> > then:
> >> replaceDiffArray arr [(1, 777)]
> > array (1,3) [(1,1),(2,777),(3,3)]
> > Why when replacing first element the second one changes?
>
> replaceDiffArray is low-level, nobody should use it, use the normal
> IArray interface instead.
> (To answer your question, replaceDiffArray works with low level index,
> not the Ix class, all array are indexed by 0, 1, .. for it, so 1 is
> the index of the second element of the array)
>
> > and also trying to add 4-th element results in:
> > Prelude Data.Array.Diff> replaceDiffArray arr [(4, 444)]
> > array (1,3) [(1,1),(2,2),(3,3)]
> >
> > It looks like replaceDiffArray can not be used to add new element to the
> end
> > of array?
>
> No, the size of a DiffArray can't be changed : DiffArray are just an
> IArray instance with better performances for update than the classic
> IArray instance (which copy the entire content on every update...).
>
> There are some libraries that allows you to change the size of your
> array, be aware though that this operation is very costly (in every
> language).
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ArrayRef
>
> --
> Jedaï
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Associative Commutative Unification

[Pepe Iborra]

On Fri, Jul 11, 2008 at 2:39 PM, John D. Ramsdell <[EMAIL PROTECTED]> wrote:
>> Are you aware of "Term Rewriting and all That"? It describes how to do
>> associative commutative unification; whether it satisfies your
>> 'obviously correct' criterion I don't know.
>
> Oh yes, I know about term rewriting.  If your equations can be
> expressed as a set of confluent rewrite rules, one can use the
> Martelli and Montanari's formalization of unification to come up with
> an obviously correct equational unifier.  Alas, that simple trick
> doesn't work for AC unification.
>
> Have you heard of Maude?  I hear the next version will have support
> for AC unification.  If I stay with Haskell, I'd have to use their
> support via interprocess communication.  Yuck.
>
> http://maude.cs.uiuc.edu/
>
> John
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

You are surely aware that AC unification is much more difficult than
syntactical unification.
CIMe[1] might be useful to solve the generated diophantine equations.
But I don't think you will be able to obtain obvious correctness, and
probably performance neither.

I don't know what you are planning to do, but perhaps you'd be better
served by Maude than by Haskell.
The Maude language is a joy to use and version 2.4 with AC unification
is (expectedly) being released next week in RTA.

Cheers
pepe

[1] - http://cime.lri.fr/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Newbie: Appending arrays?

[Chaddaï Fouché]

2008/7/11 Dmitri O.Kondratiev <[EMAIL PROTECTED]>:
> How does Data.Sequence
> http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Sequence.html
> compares with ArrayRef for appending and accessing arrays efficiently ?

It doesn't since Data.Sequence doesn't use arrays, it uses a custom
data structure that allows to do plenty of operations with pretty good
asymptotic complexity. Be aware though that the constants aren't that
good and that depending on your usage, lists, array or another
specialized data structure could be much more efficient.

By comparisons, extending an array is very likely to be much more
expensive from time to time than adding some elements to your
Data.Sequence. On the other hand the random access would be much
faster in an array and even the amortized cost of extending the array
may not be much worse than the amortized cost on the Data.Sequence in
some cases.

What exactly are you trying to do ?

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

Re: [Haskell-cafe] Newbie: Appending arrays?

[Dmitri O.Kondratiev]

I need extendable array to store and count unique vectors. I have a file
containing vectors presented as strings like:
10, 6, 80, 25, 6, 7
1, 2, 15, 17, 33, 22
21, 34, 56, 78, 91, 2
...
(BTW, what is the best library function to use to convert string of digits
into a list or array?)

There are two arrays:
1) Array of unique vectors.
The first vector red from file starts this array. Next vectors are added to
this array if they are sufficiently dissimilar from the already existing in
the array. Similarity is computed as euclidean distance between two
vectors.
2) Array of counts. Length of this array is equal to the length of array
with unique vectors. Thus every vector has a corresponding count. If new
vector is similar to some vector already existing in the first array then
corresponding count is incremented.

For example, array of unique vectors:
[[10, 6, 80, 25, 6, 7],
[1, 2, 15, 17, 33, 22],
[21, 34, 56, 78, 91, 2]]

may have a corresponding counts array:
[5,1,3]

where:
5 tells that my file has 5 vectors similar to vector [10, 6, 80, 25, 6, 7],
Only 1 vector [1, 2, 15, 17, 33, 22],
and 3 vectors similar to  [21, 34, 56, 78, 91, 2]

As long as I don't know a priory how many unique vectors my file has, as
well as how many similar to these unique others exists - I need to start
both arrays with size 0.
Next when I find a similar vector I need to increment count at corresponding
index in 'counts' array. I will also need to  access  vectors at different
index in unique array later.
That's why I need a collection both indexed and able to extend also.

I think that Data.Sequence will do for the task, don't you think?

On Fri, Jul 11, 2008 at 7:23 PM, Chaddaï Fouché <[EMAIL PROTECTED]>
wrote:

> 2008/7/11 Dmitri O.Kondratiev <[EMAIL PROTECTED]>:
> > How does Data.Sequence
> >
> http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Sequence.html
> > compares with ArrayRef for appending and accessing arrays efficiently ?
>
> It doesn't since Data.Sequence doesn't use arrays, it uses a custom
> data structure that allows to do plenty of operations with pretty good
> asymptotic complexity. Be aware though that the constants aren't that
> good and that depending on your usage, lists, array or another
> specialized data structure could be much more efficient.
>
> By comparisons, extending an array is very likely to be much more
> expensive from time to time than adding some elements to your
> Data.Sequence. On the other hand the random access would be much
> faster in an array and even the amortized cost of extending the array
> may not be much worse than the amortized cost on the Data.Sequence in
> some cases.
>
> What exactly are you trying to do ?
>
> --
> Jedaï
>



-- 
Dmitri O. Kondratiev
[EMAIL PROTECTED]
http://www.geocities.com/dkondr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Typeable and fancy types

[Ron Alford]

Hey all,
I've reduced my previous problem to a small example. Anyone know why
typeOf (...) would work, but typeOf [...] would not?  Is the
derivation for lists funky?

data Expr f = In (f (Expr f))
instance Typeable1 f => Typeable (Expr f) where
typeOf (In x) = mkTyConApp (mkTyCon "TypeTest.Expr") [typeOf1 x]

data Foo e = Foo
deriving instance Typeable1 Foo

*TypeTest> typeOf (In Foo)
TypeTest.Expr TypeTest.Foo
*TypeTest> typeOf [In Foo]
*** Exception: Prelude.undefined


TypeTest.hs
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Combining Wouter's expressions with extensible records

[Antoine Latter]

On Fri, Jul 11, 2008 at 7:07 AM, Ron Alford <[EMAIL PROTECTED]> wrote:
> What's odd is that it works directly (typeOf ... (Expr (f :+: g))
> returns a type), but if you enclose the expression in a list, it fails
> with Prelude.undefined.  Do I also need a custom instance for
> Typeable [Expr ...] ? (See previous message for code)
>

The problem is that the List instance is playing the same dirty tricks
with it's 'typeOf' implementation as we are:  it's asking us the type
of one of the list elements by passing in "undefined" to our "typeOf1"
implementation.

And then your "typeOf1" implementation tries to do pattern matching on
undefined.

Here is what will work:


instance (Typeable1 f, Typeable1 g) => Typeable1 (f :+: g) where
   typeOf1 x = mkTyConApp (mkTyCon "Planning.Wouter.:+:") [typeOf1
left, typeOf1 right]
   where
(Inr right) = Inr undefined `asTypeOf` x
(Inl left) = Inl undefined `asTypeOf` x

Now we never do pattern matching on our input.

This has been pretty educational.

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

Re: [Haskell-cafe] Re: Combining Wouter's expressions with extensible records

[Ron Alford]

On Fri, Jul 11, 2008 at 12:50 PM, Antoine Latter <[EMAIL PROTECTED]> wrote:
>
> Now we never do pattern matching on our input.
>
> This has been pretty educational.
>

Mightily! I'll have to do the same trick for Expr.

Thank you very much!
-Ron
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Typeable and fancy types

[Roberto Zunino]

Ron Alford wrote:

instance Typeable1 f => Typeable (Expr f) where
typeOf (In x) = mkTyConApp (mkTyCon "TypeTest.Expr") [typeOf1 x]


  typeOf ~(In x) = mkTyConApp (mkTyCon "TypeTest.Expr") [typeOf1 x]

Lazy patterns are jolly useful here.

Remember that typeOf will be usually called on _|_, so it must not 
inspect its argument.


Also, dummy functions such as

  getC :: Foo a b c d -> c
  getC _ = undefined

can be exploited in

  typeOf x = ... typeOf (getC x) ...

Zun.


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

[Haskell-cafe] Re: ANN: Takusen 0.8.3

[Don Stewart]

Wonderful. Builds out of the box for me.

Available in Arch Linux:

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

alistair:
> Changes since 0.8.1 (I put 0.8.2 up on hackage with an error in Setup.hs,
> so it's been skipped):
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Inductive graphs memory usage

[Don Stewart]

gsan:
> On Friday July 11 2008, Andre Nathan wrote:
> > On Thu, 2008-07-10 at 16:52 -0700, Don Stewart wrote:
> > > Well, they're radically different graph representations, and fgl
> > > hasn't been designed for large graphs.
> >
> > Do you know if King and Launchbury's implementation (Data.Graph) scales
> > better?
> 
> Looks like it.
> 
> I now did a rough benchmark on fully connected graphs with 25 and 50 nodes. 
> Data.Graph.Inductive used 28MB and 365MB respectively (x13 increase) compared 
> to Data.Graph's 486KB and 2MB (x4). And Data.Graph seems to be much faster 
> (basic operations up to 200 times), although it might be related to GC.
> 

Do you have the bencmark code? I'd like to try a couple of variants on
the underlying structures.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Newbie: Appending arrays?

[Reid Barton]

This doesn't require any fancy data structures.

On Fri, Jul 11, 2008 at 08:07:50PM +0400, Dmitri O.Kondratiev wrote:
> For example, array of unique vectors:
> [[10, 6, 80, 25, 6, 7],
> [1, 2, 15, 17, 33, 22],
> [21, 34, 56, 78, 91, 2]]
> 
> may have a corresponding counts array:
> [5,1,3]

Instead store this as a list of pairs [([10,6,80,25,6,7], 5), ...]
and it'll be easy to write a recursive function that accepts a new
vector and either increments the appropriate count or adds the new
vector at the end with count 1.

> I will also need to access vectors at different index in unique
> array later.

Then once you've finished constructing the list, turn it into an array
with listArray and use random access into that.

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

[Haskell-cafe] Re: QuickCheck [Architecturally flawed]

[Andrew Coppin]

Andrew Coppin wrote:

After many hours of effort, I came up with these:

 data Writer x
 instance Monad Writer
 run_writer :: Writer () -> ByteString
 write1 :: Bool -> Writer ()
 write8 :: Word8 -> Writer ()
 write16 :: Word16 -> Writer ()
 write32 :: Word32 -> Writer ()
 write64 :: Word64 -> Writer ()
 writeN :: Word8 -> Word32 -> Writer ()

 data Reader x
 instance Monad Reader
 run_reader :: Reader x -> ByteString -> x
 is_EOF :: Reader Bool
 read1 :: Reader Bool
 read8 :: Reader Word8
 read16 :: Reader Word16
 read32 :: Reader Word32
 read64 :: Reader Word64
 readN :: Word8 -> Reader Word32


How would you write QuickCheck properties for these?

For starters, what would be a good set of properties to confirm that any 
monad is actually working correctly? More particularly, how about a 
state monad? It's easy to screw up the implementation and pass the wrong 
state around. How would you catch that?


Secondly, the monads themselves. I started writing things like "if X has 
the lowest bit set then the lowest bit of the final byte of the output 
should be set"... but then all I'm really doing is reimplementing the 
algorithm as a property rather than a monad! If a property fails, is the 
program wrong or is the property wrong?


In the end, what I opted to do was define various properties where I 
take some arbitrary data, write it with the Writer monad, then read it 
back with the Reader monad and confirm that the data stays identical. 
(This actually fails for writeN, which writes the N least-significant 
bits of the supplied data, so you need to apply some masking before 
doing equity. Or, equivilently, reject some test values...)


Looking at the QuickCheck paper, it seems I should probably have done 
some checking that the size of the output is correct. I didn't actually 
bother because it's really easy to get right, whereas strickiness with 
bit-shifts and indexing is all too easy to screw up.


What I finally did was try writing/reading with each primitive (to check 
that actually works properly), and then again with a random number of 
individual bits packed on each side to give random alignment (to check 
that the index adjustments actually work right). It's easy to make the 
code work correctly with a certain alignment, but fail spectacularly 
otherwise. It's packed at *both* ends because it's also quite easy to 
make it write out the correct bit pattern, but leave the bit pointer 
with the wrong value, causing subsequent writes to screw up.


How would you approach this one? All hints welcomed.

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

[Haskell-cafe] Re: Improvements [Architecturally flawed]

[Andrew Coppin]

Andrew Coppin wrote:

data Writer x
 instance Monad Writer
 run_writer :: Writer () -> ByteString
 write1 :: Bool -> Writer ()
 write8 :: Word8 -> Writer ()
 write16 :: Word16 -> Writer ()
 write32 :: Word32 -> Writer ()
 write64 :: Word64 -> Writer ()
 writeN :: Word8 -> Word32 -> Writer ()

 data Reader x
 instance Monad Reader
 run_reader :: Reader x -> ByteString -> x
 is_EOF :: Reader Bool
 read1 :: Reader Bool
 read8 :: Reader Word8
 read16 :: Reader Word16
 read32 :: Reader Word32
 read64 :: Reader Word64
 readN :: Word8 -> Reader Word32

Next I decided to write an LZW compressor. Here's what I came up with:

 data EncodeLZW symbol
 eLZW_start :: (Ord symbol) => EncodeLZW symbol
 eLZW_encode :: (Ord symbol) => EncodeLZW symbol -> symbol -> Writer 
(EncodeLZW symbol)

 eLZW_end :: (Ord symbol) => EncodeLZW symbol -> Writer ()

 data DecodeLZW symbol
 dLZW_start :: DecodeLZW symbol
 dLZW_decode :: DecodeLZW symbol -> Reader (DecodeLZW symbol, symbol)


Suddenly it seems very obvious to me... I built a monad to allow writing 
bits to a ByteString, so why not make another monad for writing symbols 
to an LZW-compressed ByteString?


So... run a monad on top of another monad. Can that be done? Notionally 
it should be possible. I mean, thinking about it, what's the difference 
between a Writer and an EncodeLZW? One writes bits using some internal 
state, the other writes symbols using a more complex algorithm and 
internal state. Heck, if I augment Writer slightly so that the user can 
carry along some arbitrary state of their own, then I can just do 
something like


 newtype EncodeLZW symbol x = Wrap (Writer (StateLZW symbol) x) 
deriving Monad


Now I automatically have Wrap :: Writer (StateLZW symbol) x -> EncodeLZW 
symbol x as my magical lifting operator. Now the caller can't use any 
Writer functions (because they all have the wrong type) and can only use 
the LZW writing functions I provide. I can even write a class - 
something like


 class Encoder e s where
   encode :: symbol -> e symbol ()
   run_encoder :: e symbol () -> Writer s ()

where the "run_encoder" thing is actually just a typecast. (I'm doing is 
this way so you could possibly run another, different, encoder feeding 
to the same sink. If I returned an actual ByteString you'd be prevented 
from doing that.)


So far, this only appears to require GeneralizedNewtypeDeriving and 
MultiParamTypeClasses, so we should be golden...


...unless somebody else has a better idea?

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

Re: [Haskell-cafe] Newbie: Appending arrays?

[Dan Weston]

Dmitri O.Kondratiev wrote:
I need extendable array to store and count unique vectors. I have a file 
containing vectors presented as strings like:

10, 6, 80, 25, 6, 7
1, 2, 15, 17, 33, 22
21, 34, 56, 78, 91, 2
...
(BTW, what is the best library function to use to convert string of 
digits into a list or array?)


If you don't need to do error checking on the input syntax, the easiest 
(and arguably fastest) method is just read:


Prelude> let x = "10, 6, 80, 25, 6, 7"
Prelude> read ("[" ++ x ++ "]") :: [Int]
[10,6,80,25,6,7]

For error checking, you can use reads.

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

Re: [Haskell-cafe] Inductive graphs memory usage

[Gökhan San]

On Friday July 11 2008, Don Stewart wrote:
> Do you have the bencmark code? I'd like to try a couple of variants on
> the underlying structures.

It's not a thorough test but I suppose it gives an impression about 
performance.

-- Gokhan
$ ghc -O -prof --make TestGraph

$ ./TestGraph +RTS -s -P -RTS

TestGraph.stat with (testIG 50):
20,881,408 bytes maximum residency (62 sample(s))
%GC time  55.2%  (56.0% elapsed)

TestGraph.stat with (testG 50):
90,112 bytes maximum residency (1 sample(s))
%GC time  14.3%  (21.2% elapsed)

> module Main (main) where 

> import qualified Data.Graph as G
> import qualified Data.Graph.Inductive as IG
> import Data.Tree
> import Data.Maybe

> main :: IO ()
> main = do testIG 50
>   -- testG 50

> testIG nn = do let gi = createIG nn
>print $ length $ IG.edges gi
>print $ igTestDFS gi
>print $ igTestDFS' gi 1
>print $ igTestAdd gi

> createIG:: Int -> IG.Gr String ()
> createIG nn = IG.mkGraph lnodes ledges
> where nodes = [1 .. nn]
>   lnodes = zip nodes $ map show nodes
>   ledges = [(n1, n2, ()) | n1 <- nodes, n2 <- nodes]

> igTestDFS g = length $ IG.dfs [1] g

> igTestDFS' g sn = length sstr
> where ns = IG.dfs [sn] g
>   sstr = concatMap (fromJust . (IG.lab g)) ns

> igTestAdd g = igTestDFS' g'' (nn + 1)
> where nn = IG.noNodes g
>   newNodes = [nn + 1 .. nn + nn]
>   lnodes = zip newNodes $ map show newNodes
>   ledges = [(n1, n2, ()) | n1 <- newNodes, n2 <- newNodes]
>   g' = IG.insNodes lnodes g
>   g'' = IG.insEdges ledges g'

> type GG = (G.Graph, G.Vertex -> (String, Int, [Int]), Int -> Maybe G.Vertex)

> testG nn = do let g = createG nn
>   print $ length $ G.edges $ fst3 g
>   print $ gTestDFS g
>   print $ gTestDFS' g 1
>   print $ gTestAdd g

> createG:: Int -> GG
> createG nn = G.graphFromEdges edges
> where edges = [(show k, k, [1 .. nn]) | k <- [1 .. nn]]

> gTestDFS (g, fromVertex, toVertex) = length vs
> where vs = flatten $ head $ G.dfs g [(fromJust $ toVertex 1)]

> gTestDFS' (g, fromVertex, toVertex) sk = length sstr
> where vs = flatten $ head $ G.dfs g [(fromJust $ toVertex sk)]
>   sstr = concatMap (fst3 . fromVertex) vs

A little bit unfair but still performs well:

> gTestAdd (g, fromVertex, _) = gTestDFS' gg (nn + 1)
> where vertices = G.vertices g
>   nn = length vertices
>   edges = map fromVertex vertices
>   newks = [nn + 1 .. nn + nn]
>   edges' = [(show k, k, newks) | k <- newks]
>   -- edges' = map (\ (n, k, ks) -> (n, k + ki, map (ki +) ks)) edges
>   gg = G.graphFromEdges (edges ++ edges')

> fst3 (x, _, _) = x

> snd3 (_, y, _) = y
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Getting module functions

[rodrigo.bonifacio]

Hi all,

Is there any function that can be used for retrieving the exposed functions of 
a given module?

Thanks,

Rodrigo.

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

Re: [Haskell-cafe] Newbie: Appending arrays?

[Dmitri O.Kondratiev]

Thanks for your help, guys!  I like simple solutions most of all  :)
 On Fri, Jul 11, 2008 at 9:44 PM, Reid Barton <[EMAIL PROTECTED]>
wrote:

This doesn't require any fancy data structures.
Instead store this as a list of pairs [([10,6,80,25,6,7], 5), ...]
and it'll be easy to write a recursive function that accepts a new
vector and either increments the appropriate count or adds the new
vector at the end with count 1.

On Fri, Jul 11, 2008 at 11:32 PM, Dan Weston <[EMAIL PROTECTED]>
wrote:

> If you don't need to do error checking on the input syntax, the easiest
> (and arguably fastest) method is just read:
>
> Prelude> let x = "10, 6, 80, 25, 6, 7"
> Prelude> read ("[" ++ x ++ "]") :: [Int]
> [10,6,80,25,6,7]
>
> For error checking, you can use reads.
>
>


-- 
Dmitri O. Kondratiev
[EMAIL PROTECTED]
http://www.geocities.com/dkondr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Getting module functions

[Neil Mitchell]

Hi Rodrigo,

>  Is there any function that can be used for retrieving the exposed functions 
> of a given module?

Not at runtime, but if you are just looking for documentation, there
is online documentation here:
http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html

Thanks

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

[Haskell-cafe] Galois Tech Talks: Stream Fusion for Haskell Arrays

[Don Stewart]

Just a quick note about next week's Galois Tech Talk. Now that Galois 
has completed its move into downtown Portland, and a shiny new, centrally
located, office space, we're opening up our tech talk series a bit more
widely.  If you're in Portland, and interested in functional programming
and formal methods, drop by!



Title:  Stream Fusion for Haskell Arrays

Speaker:Don Stewart
Date:   Tuesday, July 15th, 10.30am sharp.

Location:   Galois, Inc.
421 SW 6th Ave. Suite 300
(3rd floor of the Commonwealth Building)
Portland, Oregon

Abstract:

Arrays have traditionally been an awkward data structure for Haskell
programmers. Despite the large number of array libraries available, they
have remained relatively awkward to use in comparison to the rich suite
of purely functional data structures, such as fingertrees or finite
maps. Arrays have simply not been first class citizens in the language.

In this talk we'll begin with a survey of the more than a dozen array
types available, including some new matrix libraries developed in the
past year. I'll then describe a new efficient, pure, and flexible
array library for Haskell with a list like interface, based on work in
the Data Parallel Haskell project, that employs stream fusion to
dramatically reduce the cost of pure arrays. The implementation will be
presented from the ground up, along with a discussion of the entire
compilation process of the library, from source to assembly.

About the Galois Tech Talks.

Galois (http://galois.com) has been holding weekly technical
seminars for several years on topics from functional programming,
formal methods, compiler and language design, to cryptography, and
operating system construction, with talks by many figures from the
programming language and formal methods communities.

The talks are open and free. If you’re planning to attend, dropping
a note to <[EMAIL PROTECTED]> is appreciated, but not required.
If you're interested in giving a talk, Don's always looking for new
speakers.


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

Re: [Haskell-cafe] Galois Tech Talks: Stream Fusion for Haskell Arrays

[Johan Tibell]

On Sat, Jul 12, 2008 at 12:13 AM, Don Stewart <[EMAIL PROTECTED]> wrote:
>
> Just a quick note about next week's Galois Tech Talk. Now that Galois
> has completed its move into downtown Portland, and a shiny new, centrally
> located, office space, we're opening up our tech talk series a bit more
> widely.  If you're in Portland, and interested in functional programming
> and formal methods, drop by!

Any possibility of you guys taping the talk?

Cheers,

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

Re: [Haskell-cafe] Galois Tech Talks: Stream Fusion for Haskell Arrays

[Henning Thielemann]

On Sat, 12 Jul 2008, Johan Tibell wrote:


On Sat, Jul 12, 2008 at 12:13 AM, Don Stewart <[EMAIL PROTECTED]> wrote:


Just a quick note about next week's Galois Tech Talk. Now that Galois
has completed its move into downtown Portland, and a shiny new, centrally
located, office space, we're opening up our tech talk series a bit more
widely.  If you're in Portland, and interested in functional programming
and formal methods, drop by!


Any possibility of you guys taping the talk?


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

Re: [Haskell-cafe] Profiling nested case

[Mitar]

Hi!

This is not all. If I compare performance of those two semantically
same functions:

castRayScene1 :: Ray -> ViewportDotColor
castRayScene1 (Ray vd o d) = ViewportDotColor vd (castRay' noColor 0)
  where castRay' color@(VoxelColor _ _ _ alpha) depth | depth >
depthOfField = color
  | alpha < 0.001
  = castRay' pointColor (depth + distance')
  | alpha > 0.999
  = color
  | otherwise
  = castRay' newColor (depth + distance')
  where (# pointColor, distance #) = worldScene (o <+> (d <* depth))
distance'  = max 1 distance
newColor   = addColor color pointColor

and:

castRay :: World -> Ray -> ViewportDotColor
castRay world (Ray vd o d) = ViewportDotColor vd (castRay' noColor 0)
  where castRay' color@(VoxelColor _ _ _ alpha) depth | depth >
depthOfField = color
  | alpha < 0.001
  = castRay' pointColor (depth + distance')
  | alpha > 0.999
  = color
  | otherwise
  = castRay' newColor (depth + distance')
  where (# pointColor, distance #) = world (o <+> (d <* depth))
distance'  = max 1 distance
newColor   = addColor color pointColor

castRayScene2 :: Ray -> ViewportDotColor
castRayScene2 = castRay worldScene

is the program which uses castRayScene1 1.35 faster then the program
which uses castRayScene2 (37 seconds versus 50 seconds).

(Compiler with GHC 6.8.3 and -O2 switch. Program is executing almost
just this function over and over again.)

It is somehow award that passing function as an argument slow down the
program so much. Is not Haskell a functional language and this such
(functional) code reuse is one of its main points?

Of course. I could use some preprocessor/template engine to
change/find/replace castRay-like function into a castRayScene1 before
compiling. But this somehow kills the idea of a compiler? Smart
compiler. Which should do things for you?

The same as my previous example. Where a hard-coded list was not
optimized. (Like it would change during the execution.) It looks like
my program would be interpreted and not compiled.


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

Re: [Haskell-cafe] Typeable and fancy types

[Luke Palmer]

On Fri, Jul 11, 2008 at 5:13 PM, Roberto Zunino <[EMAIL PROTECTED]> wrote:
> Ron Alford wrote:
>>
>> instance Typeable1 f => Typeable (Expr f) where
>>typeOf (In x) = mkTyConApp (mkTyCon "TypeTest.Expr") [typeOf1 x]
>
>  typeOf ~(In x) = mkTyConApp (mkTyCon "TypeTest.Expr") [typeOf1 x]

Yes, that works, but what would also work is this:

newtype Expr f = In (f (Expr f))

Keeping the typeOf code the same as the original.  I would consider
this more correct, since this is a type trick, not a value trick.  The
data definition makes your model have an extra bottom, which can't be
very attractive!

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

Re: [Haskell-cafe] Getting module functions

[Brandon S. Allbery KF8NH]

On 2008 Jul 11, at 17:23, rodrigo.bonifacio wrote:

Is there any function that can be used for retrieving the exposed  
functions of a given module?



Not in the usual introspection/RTTI sense; but you could probably use  
the GHC API to read a .hi file.  (At which point I direct you to  
people clueful about GHC innards, which I'm not.)


--
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] Profiling nested case

[Brandon S. Allbery KF8NH]

On 2008 Jul 11, at 19:46, Mitar wrote:


It is somehow award that passing function as an argument slow down the
program so much. Is not Haskell a functional language and this such
(functional) code reuse is one of its main points?


That is in fact the case; GHC's version of various Prelude functions  
refactors them to avoid passing functional arguments.  IIRC the  
problem is that, while Haskell is indeed functional, passing a  
polymorphic function as an argument causes the runtime to have to look  
up which type is needed for every call, whereas if it's factored out  
it can be computed only once and (implicitly) let-bound.


--
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] Profiling nested case

[Max Bolingbroke]

> It is somehow award that passing function as an argument slow down the
> program so much. Is not Haskell a functional language and this such
> (functional) code reuse is one of its main points?

I can think of a few reasons why function passing is slow:
* There is an overhead to closure creation (I don't know how big this
is in practice, but it can be significant)
* GHC has little information about what function-typed variables mean,
because the function they are bound to is not known until runtime.
This precludes the use of inlining, rewrite rules etc, which are
absolutely key factors in making Haskell fast

Regarding your first example: currently GHC does not do loop
unrolling. It probably should though because loop unrolling reduces
braches and increases the amount of information about the execution
path that is available statically (as in e.g. the case liberation
transformation), which probably explains the increased performance you
saw by doing it manually in your first email.  Earlier this year I
implemented something somewhat similar though: fusable list literals.
In this example from your first email:

world :: SpacePoint -> VoxelColor
world point = findColor [redSphere (0,50,0) 50, greenSphere (25,-50,0)
50, blueSphere (-150,0,150) 50]
 where findColor [] = noColor
   findColor (f:fs) = case f point of
   Just v  -> v
   Nothing -> findColor fs

If findColor had been a function defined in terms of foldr rather than
using explicit recursion, then theres a good chance GHC 6.9 would have
fused it with the list to yield your optimized, loop unrolled,
version:

world :: SpacePoint -> VoxelColor
world point = case redSphere (0,50,0) 50 point of
   Just v  -> v
   Nothing -> case greenSphere (25,-50,0) 50 point of
Just v  -> v
Nothing -> case blueSphere (-150,0,150) 50 point of
 Just v  -> v
 Nothing -> noColor

Incidentally, if in your most recent email castRayScene2 was your only
used of castRay, GHC would have inlined the whole definition into that
use site and you would have got castRayScene1 back again.

So, GHC does try its best to make higher order functions fast :-). But
it's quite tricky!

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

Re: [Haskell-cafe] Associative Commutative Unification

[John D. Ramsdell]

> I think Edsko was more specifically referring to the book "Term
> Rewriting and all That" by Baader and Nipkow.

Thanks for pointing this out--I was confused.  I notice the book has a
chapter on equational unification that includes a section on AC
unification.  This book looks like a winner.  Thank you.

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

Re: [Haskell-cafe] Associative Commutative Unification

[John D. Ramsdell]

> CIMe[1] might be useful to solve the generated diophantine equations.

It also has AC unification, and it probably wouldn't be all that hard
to translate our code into OCaml.  I think CiME isn't supported
anymore.  Still it's worth considering.  It's quite large.  The source
distribution compiled effortlessly on Ubuntu.  That's about all I know
now.

> I don't know what you are planning to do, but perhaps you'd be better
> served by Maude than by Haskell.

Switching to Maude is an option we're considering.

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