[Haskell-cafe] Can't cabal install darcs because hashed-storage needs 'System'

[Daniel McAllansmith]

Hello.


Short story:

$ cabal install --global --constraint="old-time>=1.0.0.3.1" --reinstall -v 
darcs


/tmp/hashed-storage-0.4.71127/hashed-storage-0.4.7/Setup.hs:13:7:
Could not find module `System':
  Use -v to see a list of the files searched for.


This is using GHC 6.12.1, cabal-install 0.8.0 and Cabal 1.8.0.2

How do I get darcs installed?


Longer story:

I've been trying to install darcs 2.4 built against a patched version of old-
time, 1.0.0.3.1 is effectively 1.0.0.4 just that it's patched locally because 
1.0.0.4 hasn't been released to hackage yet.

I ran into various problems with global vs. user packages, no version of base 
being valid and a few other bits and pieces.  So I am trying a global install 
and have had to reinstall Cabal (and various other packages), presumably 
because it was built against old-time 1.0.0.3.

Looking at the hashed-storage code it imports System (system, exitWith).  Is 
that old base-3 code?

The debug messages show:

selecting base-3.0.3.2 (installed) and 4.2.0.0 (installed)

and

/usr/local/bin/ghc --make /tmp/hashed-storage-0.4.71127/hashed-
storage-0.4.7/Setup.hs -o /tmp/hashed-storage-0.4.71127/hashed-
storage-0.4.7/dist/setup/setup -odir /tmp/hashed-storage-0.4.71127/hashed-
storage-0.4.7/dist/setup -hidir /tmp/hashed-storage-0.4.71127/hashed-
storage-0.4.7/dist/setup -i -i/tmp/hashed-storage-0.4.71127/hashed-
storage-0.4.7 -package Cabal-1.8.0.2

so I'm not really sure what version of base it's actually trying to compile 
hashed-storage against.

Any further information I can provide?


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

Re: [Haskell-cafe] Can't cabal install darcs because hashed-storage needs 'System'

[Daniel McAllansmith]

On Sat, 13 Mar 2010 Daniel McAllansmith wrote:
> Hello.
> 
> 
> Short story:
> 
> $ cabal install --global --constraint="old-time>=1.0.0.3.1" --reinstall -v
> darcs
> 
> 
> /tmp/hashed-storage-0.4.71127/hashed-storage-0.4.7/Setup.hs:13:7:
> Could not find module `System':
>   Use -v to see a list of the files searched for.
> 
> 
> This is using GHC 6.12.1, cabal-install 0.8.0 and Cabal 1.8.0.2
> 
> How do I get darcs installed?

I managed to get hashed-storage installed by patching Setup.hs replacing:

import System( system, exitWith )

with:

import System.Process( system )
import System.Exit( exitWith )

and adding process>=1.0.1.1 to the build-depends.


I also needed to replace:

import System( system )
import System.Process ( ProcessHandle,
runInteractiveProcess, waitForProcess,
getProcessExitCode )

with:

import System.Process ( ProcessHandle,
runInteractiveProcess, waitForProcess,
getProcessExitCode, system )

in darcs' Distribution/ShellHarness.hs to get it to compile.


I don't know whether these changes would let these packages continue to build 
against older versions of GHC/base but if anyone wants them I can create 
proper darcs patches if they're useful.


Cheers
Dan

> 
> Longer story:
> 
> I've been trying to install darcs 2.4 built against a patched version of
> old- time, 1.0.0.3.1 is effectively 1.0.0.4 just that it's patched locally
> because 1.0.0.4 hasn't been released to hackage yet.
> 
> I ran into various problems with global vs. user packages, no version of
> base being valid and a few other bits and pieces.  So I am trying a global
> install and have had to reinstall Cabal (and various other packages),
> presumably because it was built against old-time 1.0.0.3.
> 
> Looking at the hashed-storage code it imports System (system, exitWith). 
> Is that old base-3 code?
> 
> The debug messages show:
> 
> selecting base-3.0.3.2 (installed) and 4.2.0.0 (installed)
> 
> and
> 
> /usr/local/bin/ghc --make /tmp/hashed-storage-0.4.71127/hashed-
> storage-0.4.7/Setup.hs -o /tmp/hashed-storage-0.4.71127/hashed-
> storage-0.4.7/dist/setup/setup -odir /tmp/hashed-storage-0.4.71127/hashed-
> storage-0.4.7/dist/setup -hidir /tmp/hashed-storage-0.4.71127/hashed-
> storage-0.4.7/dist/setup -i -i/tmp/hashed-storage-0.4.71127/hashed-
> storage-0.4.7 -package Cabal-1.8.0.2
> 
> so I'm not really sure what version of base it's actually trying to compile
> hashed-storage against.
> 
> Any further information I can provide?
> 
> 
> Thanks
> Dan
> ___
> 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] Data.Map and strictness (was: Is Haskell aGoodChoice for WebApplications?(ANN: Vocabulink))

[Daniel McAllansmith]

On Fri, 08 May 2009 00:30:34 Claus Reinke wrote:
> > seq something like size map that will force a traversal of the entire
> > tree, and ensure that the result is actually demanded, ..
> > (Not tested)
>
> and not recommended, either, I'm afraid!-)
>
> |> Actually, I'm unsure how to fix this. For an expression like this:
> |>
> |>Data.Map.delete key map
> |>
> |> how can I use seq (or something else) to sufficiently evaluate the above
> |> to ensure that the value associated with key can be garbage collected?

[snip]

> Anyway;-) You can see that size is actually pre-computed, so there's
> no guarantee that asking for it will traverse the internal representation,

Presumably seq'ing the Maybe you get from looking up the key will be 
sufficient to dereference the key, and will avoid unnecessary traversal of 
unrelated parts of the map.

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

[Haskell-cafe] Finding points contained within a convex hull.

[Daniel McAllansmith]

Hello.

I've got a system of linear inequalities representing half-spaces.  The 
half-spaces may or may not form a convex hull.

I need to find the integral coordinates that are contained within the convex 
hull, if there is one.

For example, given
0 <= x <= 4
0 <= y <= 3
0 <= 2x - y
0 <= 1.2y - x

I want the following (x,y) coordinates
[(0,0),(1,1),(1,2),(2,2),(2,3),(3,3)]


Anybody have any suggestions, or libraries, for solving this in many 
dimensions and equations?


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

Re: [Haskell-cafe] Finding points contained within a convex hull.

[Daniel McAllansmith]

Thanks for the responses everyone.

On Thursday 07 June 2007 00:37, [EMAIL PROTECTED] wrote:
> Simon Brenner wrote:
> > Do you simply want the set of coordinates, or do you want to do
> > something smart with the them (i.e. optimize a function value etc)?

Ultimately optimise several functions over the feasible coordinates, however 
the functions to optimise are complicated, definitely non-linear, and the 
linear constraints are already a simplification of non-linear constraints.

I was hoping to get a superset of coordinates, filter with the real 
constraints then optimise each of the target functions.


> > Oh, and BTW, isn't any intersection of half-spaces always a convex
> > hull? In which case is it not?

Inconsistent constraints, e.g. x>5, y>5, x+y<10

>
> If one transforms to get all the extreme vertexes, then you can easily
> bound each coordinate by the min and max values of that coordinate in the
> set of vertexes.  These bounds on each coordinate give you a large
> "rectangular" box that contains your polyhedra.

Since Ilya pointed out that integer linear programming is NP-complete I've 
been thinking of determining the bounding-box and doing a branch-and-bound 
search.  My idea was to solve the linear constraints twice for each 
dimension, to maximise and minimise the variable in that dimension.
From there I can divide and conquer, hopefully discarding/fixing whole 
dimensions and reducing the proportion of invalid coordinates.  If need be I 
could even randomly sample the remaining coordinates to keep things 
tractable.

I guess that's not much different from what I was orginally planning - 
superset, filter, optimise... the superset is just bigger now.

How would you go about finding extreme vertices?  Would it be quicker than 
solving the constraints for each max/min?

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

Re: [Haskell-cafe] folds with escapes

[Daniel McAllansmith]

On Thursday 05 July 2007 11:20, Michael Vanier wrote:
> Again, I'm sure this has been done before (and no doubt better); I'd
> appreciate any pointers to previous work along these lines.

Takusen is, if I recall correctly, based around a generalised fold supporting 
accumulation and early termination.  Maybe have a look at that.

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

Re: [Haskell-cafe] Clearly, Haskell is ill-founded

[Daniel McAllansmith]

On Monday 09 July 2007 17:42, Thomas Conway wrote:
> I don't know if you saw the following linked off /.
>
> http://www.itwire.com.au/content/view/13339/53/
>
> An amazon link for the book is here:
>
> http://www.amazon.com/Computer-Science-Reconsidered-Invocation-Expression/d
>p/0471798142
>
> The basic claim appears to be that discrete mathematics is a bad
> foundation for computer science. I suspect the subscribers to this
> list would beg to disagree.

I wouldn't want to comment on the validity of his claim, maybe he's wrong, or 
maybe he's... well, anyway... what I will say is I got a chuckle out of 
the 'Citations' that Amazon lists.

I especially like it that Mr. Fant's book is apparently cited in 'The 
Essential Guide to Psychiatric Drugs: Includes The Most Recent Information 
On: Antidepressants, Tranquilizers and Antianxiety Drugs, 
Antipsychotics, ...'

I shudder to think of the creative processes involved in the creation of the 
book.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] problem with IO, strictness, and "let"

[Daniel McAllansmith]

On Saturday 14 July 2007 11:29, Michael Vanier wrote:
> Albert,
>
> Thanks for the very detailed reply!  That's the great thing about this
> mailing list.
>
> I find your description of seq somewhat disturbing.  Is this behavior
> documented in the API?  I can't find it there.  

As I understand it seq is well-behaved.  Though there is the x `seq` x = id 
trickiness and maybe some trickiness around undefined.

The disturbing behaviour is a consequence of the inherent unsafeness of 
hGetContents.  seq is being used to try and mitigate some of this unsafeness 
but that's not really the purpose of seq so you still have to be careful.

> It suggests that perhaps 
> there should be a
> really-truly-absolutely-I-mean-right-now-seq function that evaluates the
> first argument strictly no matter what (not that this should be something
> that gets used very frequently).  Or are there reasons why this is not
> feasible?

Albert mentioned "return $! length c", that forces the whole lot because it's 
all needed to calculate the length.

You could also look at Control.Parallel.Strategies.  (I think) that it has 
classes and functions that let you define how to reduce to other than WHNF.

>
> Sorry to belabor this.  Learning to think lazily is IMO one of the hardest
> aspects of learning Haskell.

Like any unsafe operation if you can convince yourself that it will actually 
be safe go ahead and use it.  But as Albert has pointed out there can be 
hidden complexity in proving this to yourself.


There have been discussions on haskell-cafe previously about the risks of 
getContents, safe alternatives, whether it should be renamed 
unsafeGetContents, etc.  Sorry I can't dredge up exact dates/subjects, maybe 
someone else can recall.


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

Re: [Haskell-cafe] Re: Is this haskelly enough?

[Daniel McAllansmith]

On Wednesday 18 July 2007 21:16, Johan Tibell wrote:
> It would be nice if it was possible to capture this kind of behavior in a
> high order function just like map though. I guess the problem is that the
> function to map will take different number of arguments depending on the
> use case.
>
> lookAtTwo a b = ...
>
> lookAtThree a b c = ...
>
> map' :: (a -> ... -> b) -> [a] -> [b]
>
> The parameter take a variable number of parameters.
>
> Note: I don't know if there is a sensible way to write map' at all. Perhaps
> explicit recursion is better in this case.

Oleg (unsurprisingly) has some type-class hackery for polyvariadic/keyword 
functions.  Probably do what you need, possibly be overkill for what you 
want... here it is anyway.

http://okmij.org/ftp/Haskell/keyword-arguments.lhs
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Backpatching

[Daniel McAllansmith]

On Wednesday 01 August 2007 17:44, Thomas Conway wrote:
> This sounds like a common problem type. Is there a well known solution
> to this sort of problem?

Have you looked into Tying the Knot?
http://www.haskell.org/haskellwiki/Tying_the_Knot


A simple example:

module Knot where

import Data.Char
import Data.Maybe

type Input = String
type Output = [(Char, Int)]
type Resolver = (Char -> Int)

resolvingError c = error ("Couldn't resolve: " ++ [c])

parseInput :: Resolver -> Input -> Output
parseInput _ [] = []
parseInput resolve (c:cs) | isUpper c = ((c, fromEnum c) : parseInput f cs)
  | otherwise = ((c, resolve c) : parseInput f cs)

makeResolver :: Output -> Resolver
makeResolver o c = fromMaybe (resolvingError c) (lookup (toUpper c) o)

foo :: Input -> Output
foo i = let o = parseInput (makeResolver o) i in o

testGood = foo "CaBcbA"
testBad = foo "CaBcb"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hawiki articles

[Daniel McAllansmith]

On Tuesday 04 September 2007 08:29, Neil Mitchell wrote:
> Hi
>
> There are two entirely separate issues in this thread - let's not confuse
> them.
>
> 1) The old HaWiki content is good and unavailable. I want it made
> available, in whatever form is appropriate. Please :-)
>
> 2) Licensing - the old content cannot be dumped onto the new wiki. My
> personal view is "who cares". There are numerous license violations
> within the Haskell community (I can think of 4 off the top of my
> head), but in general everyone is working for the same purpose, and
> its just pesky laws getting in the way - not violating peoples intent.
> I realise that this will be a minority opinion, and that its probably
> a bad idea to follow my opinion on this.


HaskellWiki states "Recent content is available under a simple permissive 
license."  That implies to me that there may be old content that isn't under 
a simple permissive licence, so users of the wiki should have an eye out for 
licencing issues.

Could the hawiki content not be slapped in at .../haskellwiki/OldContent/... 
read-only with big, red, flashing, 'licence unknown, get contributor 
consents, etc, etc' warning?  At least it can then be migrated easily if the 
rights-holder agrees, or be referenced by original works on haskellwiki.

That seems a satisfactory attempt to honour the letter/intent of the 
law/contributor.  If someone complains the offending content can be removed.

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

Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Daniel McAllansmith]

On Tuesday 16 October 2007 11:45, Claus Reinke wrote:
> >> how about using a provides/expects system instead of betting on
> >> version numbers? if a package X expects the functionality of base-1.0,
> >> cabal would go looking not for packages that happen to share the name,
> >> but for packages that provide the functionality.
> >
> > Using the version number convention mentioned earlier, "base-1.0"
> > funcionality is provided by base-1.0.* only.  A package can already
> > specify that explicitly.
>
> not entirely correct. you said that major versions implied api changes.
> that does not imply that the api is no longer backwards compatible,
> only that there are sufficiently substantial new features that a version
> naming them seems called for. while base breaks backwards
> compatibility, other packages might not do so.
>
> and cabal does not allow me to specify anything but a name and a
> range of numbers as dependencies (there is exposed-modules:, but
> no imported-modules:), so i can't say which parts of base-1.0 my
> package depends on, and cabal can't decide which versions of
> base might be compatible with those more specific dependencies.

I've been giving only cursory attention to this thread so I might have the 
wrong end of the stick, or indeed the entirely wrong shrub.

If the convention for modifying package versions of form x.y.z is:
 - increment z for bugfixes/changes that don't alter the interface
 - increment y for changes that consist solely of additions to the interface, 
parts of the interface may be marked as deprecated
 - increment x for changes that include removal of deprecated parts of the 
interface
 - (optionally) x == 0 => no guarantee

and package maintainers are rigorous in following these rules then specifying 
dependencies as foo-x, foo-x.y, foo-x.y.z should be sufficient.  This rigour 
could largely be enforced by hackage or an automated build system.

foo-x is a shortcut for foo-x.0.0
foo-x.y is a shortcut for foo-x.y.0
foo-x.y.z is satisfied by any foo-i.j.k where i=x, j.k>=y.z

The 'foo' package name is just an indicator of lineage.
foo-2.xxx is not the same package as foo-1.xxx, it's interface is missing 
something that foo-1.xxx's interface provided.

Dependencies of "foo" shouldn't appear in published cabal files.  There is a 
case for their use in development where you are specifying that you want to 
depend on the very latest version of foo available, perhaps from darcs.  When 
you publish that latest version number gets burned in, eg "foo-2.1.20071016".


As for provides/expects and imported-modules instead, isn't that just an 
arbitrary line drawn in the granularity sand?
Perhaps package versions could be expanded to include the type of every 
function they expose, plus more information to indicate which bugfix version 
of those functions is present.  That's maybe the Right Way... and probably a 
lot of work.

A more convenient place to draw the line seems to be at the package level.

>
> > I think what you're asking for is more than that: you want us to provide
> > base-1.0, base-2.0 and base-3.0 at the same time, so that old packages
> > continue to work without needing to be updated.  That is possible, but
> > much more work for the maintainer.  Ultimately when things settle down it
> > might make sense to do this kind of thing, but right now I think an
> > easier approach is to just fix packages when dependencies change, and to
> > identify sets of mutually-compatible packages (we've talked about doing
> > this on Hackage before).
>
> yes. it's called automatic memory management!-) as long as there's
> a package X depending on package Y-a.b, package Y-a.b should
> not disappear. not having to waste time on such issues is one reason
> why programmers are supposed to prefer haskell over non-functional
> languages, right?-)

I think it's a no-brainer that old versions of packages should remain 
available for people to use for 'a long time'.  If their dependencies are 
specified properly they should continue building successfully as time passes.

Isn't the main problem the use of "foo" dependencies and the resulting version 
guessing/ambiguity?

Presumably it's not usually a problem if indirect package dependencies require 
incompatible versions of a package.  Is this a problem with base because it 
implicitly has a dependency on a particular version of the GHC internals?


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

Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Daniel McAllansmith]

On Tuesday 16 October 2007 21:16, Simon Marlow wrote:
> > - when GHC 6.8 comes out containing base-3, will it be possible to
> >   additionally install something calling base-2 with both being
> >   available to packages?
>
> In theory yes - the system was designed to allow this.  In practice we've
> never tried it, and base-2 might not compile unmodified with GHC 6.8.
>
> > - If so, will existing Cabal packages automatically pick up the
> >   compatible base-2 despite base-3 being available?
>
> Only if they specify an upper bound on the base dependency, which most
> don't, but it's an easy change to make.

It seems more sensible to me for dependencies to always have an upper bound of 
the next major version.  foo-3.y.z won't satisfy foo-2.3.4.

If it so happens that a package depends on the subset of foo's interface that 
was retained from foo-2.3.4 through to foo-3.0.0 then the dependency can be 
changed to foo-2.3.4,3.0.0 (modulo syntax) once it has been tested.

If dependencies on foo often end up like this due to use of a distinct subset 
of the interface it's probably a good sign that foo is too coarse-grained.


If a major version increment, by definition, implies a removal of 
functionality from a package then having no upper bound on the dependency 
pushes work out to the user that would be better done by the maintainer.  
With an upper bound users are still able to try and get the package going 
with a later version of a dependency if they want.

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

[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Daniel McAllansmith]

Following is a summary of my thoughts on the matter, in large part so I can 
figure out what I'm thinking... apologies if it's a bit of a ramble.  All 
comments welcome.


Basically
 - version numbering which differs from Simon's proposal
 - precise dependencies, I think the same as Simon is proposing
 - 'permanent' availability of compatible package versions
 - never a need to update working cabal files
 - a cabal file installs exactly one version of a package


1)
Package version numbers are of the form x.y.z


2)
There are version-segment ordering functions cmpX, cmpY, and cmpZ.

cmpX and cmpY are globally defined and operate over non-negative integers.  
Perhaps cmpZ is globally defined, or could be defined per package, or be 
lexicographic, or... something else.  cmpZ could even be a partial ordering I 
suppose.


3)
A cabal file specifies how to build a single version of a package.
name: foo
version: 2.12.5

This cabal file will build version 2.12.5 of package foo.


4)
The dependencies in a cabal file define baseline versions of required 
packages.
depends: bar [3.4]
 baz [1.2.6, 3]

Version 2.12.5 of foo requires a version of bar that is API-compatible with 
3.4.0 and a version of baz that is API-compatible with 1.2.6 _or_ 
API-compatible with 3.0.0.
Note that this doesn't imply that baz 3.0.0 is API-compatible with baz 1.2.6 
(by definition it is not), it implies that foo is using a subset of the 
intersection of those two baz APIs.
Note that baz 2.y.z would not satisfy the dependency.  Perhaps a function was 
removed with the bump to 2 and restored only with the bump to 3.


5)
Package version numbers encode whether one version of a package is 
API-compatible with another version of the package.

Given two versions x.y.z and i.j.k of a package:

 - x == i && y == j
==> x.y.z is API-identical (hence API-compatible) with i.j.k, cmpZ can be 
used to determine preferred version

 - x == i && y > j
==> x.y.z is API-compatible with i.j.k, it has undergone 
compatibility-preserving changes, x.y.z is preferred to i.j.k

 - x > i
==> x.y.z is not API-compatible with i.j.k, it has undergone 
non-compatibility-preserving changes

 - otherwise
==> x.y.z is not API-compatible with i.j.k, it is a lower version that has 
less functionality


6)
A compatibility-preserving change is generally a change which just adds to the 
API.  Ross Paterson points out adding extra data constructors or instances 
may not be compatibility-preserving.

A non-compatibility-preserving change is generally a change which includes the 
removal of some part of the API.  It might also include changes which leave 
the API unmodified but significantly degrade usability, e.g. worse time or 
space performance.


7)
Once a version of a package is building successfully it remains available for 
a 'long time'.  If sufficient versions of a package remain available then 
API-compatible versions of required packages are always available, so the 
building of packages should never break.  An uploaded cabal file should never 
need to be changed, regardless of what happens to the packages it depends 
upon.


8)
If a version of a package is discovered to have security flaws or serious bugs 
it should remain available in a quarantined state until a fixed 
API-compatible version is available.


9)
Something (hackage?) could enforce adherence to version numbering policy.  At 
the least any new version uploaded that claims to be API-compatible can be 
test compiled against packages which depend on it.

Something (hackage?) could assist package maintainers in releasing a new 
version of their package with updated dependency information.  Hackage could 
attempt to compile against non API-compatible versions and report the 
outcome, for example foo 2.12.5 compiles with the new baz 3.0.0 but not the 
latest baz 2.y.z


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

[Haskell-cafe] Re: Proposal: register a package as providing several API versions

[Daniel McAllansmith]

On Wednesday 17 October 2007 01:32, ChrisK wrote:
> Simon Marlow wrote:
> > Several good points have been raised in this thread, and while I might
> > not agree with everything, I think we can all agree on the goal: things
> > shouldn't break so often.
>
> I have another concrete proposal to avoid things breaking so often.  Let us
> steal from something that works: shared library versioning on unixy
> systems.
>
> On Max OS X, I note that I have, in /usr/lib:
> > lrwxr-xr-x1 root  wheel15 Jul 24  2005 libcurl.2.dylib ->
> > libcurl.3.dylib lrwxr-xr-x1 root  wheel15 Jul 24  2005
> > libcurl.3.0.0.dylib -> libcurl.3.dylib -rwxr-xr-x1 root  wheel   
> > 201156 Aug 17 17:14 libcurl.3.dylib lrwxr-xr-x1 root  wheel15
> > Jul 24  2005 libcurl.dylib -> libcurl.3.dylib
>
> The above declaratively expresses that libcurl-3.3.0 provides the version 3
> API and the version 2 API.
>
> This is the capability that should be added to Haskell library packages.
>
> Right now a library can only declare a single version number.  So if I
> update hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the
> version 3 API is a superset of (backward compatible with) the version 2
> API.

If 3.0.0 is a superset of 2.1.1 why was it necessary to bump to 3.0.0?  Why 
not 2.2.0?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Daniel McAllansmith]

On Thursday 18 October 2007 00:54, Simon Marlow wrote:
> I've written down the proposed policy for versioning here:
>
>http://haskell.org/haskellwiki/Package_versioning_policy


Is there technical reason for the major version number to consist of 2 
components?  Why not 3, 17 or (my preference) 1?


Using major.minor instead of A.B.C, and interpreting MUST, SHOULD, MAY as 
specified by whatever RFC it is that specifies them, I'd write the change 
rules as:

1. If any entity was removed, or the types of any entities or the definitions 
of datatypes or classes were changed, or instances were added or removed, 
then the new major MUST be greater than the previous major (other version 
components MAY change).

2. Otherwise, if only new bindings, types or classes were added to the 
interface, then major MUST remain the same and the new minor MUST be greater 
than the old minor (other version components MAY change).

3. Otherwise, major.minor MUST remain the same (other version components MAY 
change).


Why?

 - It gives the reader of the version numbers more information, which in turn 
may allow hackage to do more automated enforcement/testing/upgrading.

 - To safely specify dependencies you must use an upperbound of the next major 
version.  The stricter change rules make it less likely that a package will 
miss out on the use of a new version of a dependency that is actually 
compatible but had it's version bumped anyway.



The proposal isn't clear on whether this is allowed or not, but I think sets 
of version bounds are needed.

Using A.B.C <==> major.minor.patch and interval notation for brevity:
build-depends: foo [2.1, 3) U [3.3, 3.4)


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

Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Daniel McAllansmith]

On Thursday 18 October 2007 21:15, you wrote:
> Daniel McAllansmith <[EMAIL PROTECTED]> writes:
> > 3. Otherwise, major.minor MUST remain the same (other version components
> > MAY change).
>
> Is it an option to say SHOULD rather than MUST here?

Of course, SHOULD is an option just like MAY is.  But both SHOULD and MAY 
reduce what you can reliably infer from a version number in the same way.

If the rule is SHOULD or MAY, and the freedom is exercised, compatible 
versions of a package will differ in major[.minor] and dependent packages 
will be unable to benefit from their release.  You'll need more maintenance 
work on package dependencies if you want to use the latest and greatest 
versions.

In a similar way, if packages are being retained for a 'long time' to ensure 
dependent packages remain buildable, you are losing garbage collection 
opportunities.


I'm pretty certain SHOULD will be far more socially acceptable than MUST.  I 
can appreciate the fact that people are accustomed to incrementing version 
numbers in liberal ways.

But if you look at version numbers dispassionately in the context of "The goal 
of a versioning system is to inform clients of a package of changes to that 
package that might affect them..." MUST seems a better choice.

Maybe the Right Way of informing clients is full-on metadata and typing of 
packages and maybe we'll have that soon, so maybe a socially acceptable, 
weaker versioning scheme is acceptable.

> There are 
> other reasons for a version bump than breaking compatibility.

Technical reasons?

In some cases a major bump would just be devolving to a minor bump.

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

[Haskell-cafe] Using type-level programming to tag functions with time and space complexity

[Daniel McAllansmith]

I was wondering if anyone had done work on tagging functions at the type level 
with their time or space complexity and, if it's even feasible, calculating 
the complexity of compound functions.

Any pointers?

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

Re: [Haskell-cafe] GHC 6.10.1 and cabal[-install]

[Daniel McAllansmith]

On Wed, 19 Nov 2008 21:27:36 Duncan Coutts wrote:
> It's even easier than that! Someone has done it already :-)
>
> http://hackage.haskell.org/trac/hackage/ticket/261
>
> Thu Aug 28 16:55:16 CEST 2008  Chry Cheng <[EMAIL PROTECTED]>
>   * Marking packages deprecated
>   Fixes ticket no. 261 as discussed in its annotations.  Packages with
> "deprecated" "true" are excluded from the package list.  Packages with
> "superseded by" tags provide links to their superseding packages in the
> package page.

Does "excluded from the package list" mean that deprecated packages won't show 
up on http://hackage.haskell.org/packages/archive/pkg-list.html ?

If so, how does one go about finding and downloading deprecated packages?  
Rely on the search function to find the package page?
How do you get a comprehensive list of the deprecated packages that have 
existed?

Perhaps there should be a deprecated-pkg-list.html page.
If being superseded implies deprecation this page is also where the superseded 
packages would go, with appropriate supersedes/superseded-by links between 
them.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] accessible layout proposal?

[Daniel McAllansmith]

On Wed, 23 Sep 2009 15:06:25 Daniel Fischer wrote:
> Am Mittwoch 23 September 2009 04:06:11 schrieb Jimmy Hartzell:
> > Daniel Fischer wrote:
> > > Or, what I do:
> > >
> > > concat
> > > [ "("
> > > , str
> > > , ")"
> > > ]
> >
> > This is a lot better, true, but it still takes a lot of typing, and the
>
> Huh? Per line it's two keystrokes more than with the accessible layout
> proposal. That's not a lot.
>
> > first element is now special-cased, preventing easy copy-and-paste
>
> Making it slightly harder. Copy-Paste-Cursor to beginning-delete-comma.
> No big deal. Besides, how often does one need to copy the beginning of one
> list into the middle of another?

Or you could use:

concat (
  : "("
  : str
  : ")"
  :[])

Though you do sometimes have to bracket an element that you wouldn't otherwise 
have to, eg

concat (
  : "("
  : str
  : ('a':'b':[])
  : ")"
  :[])
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GHCi and HXT

[Daniel McAllansmith]

On Tuesday 28 November 2006 20:50, Alexis Hazell wrote:
>   let contact = mkelem "stream:stream" [ sattr "xmlns:stream"
> "http://etherx.jabber.org/streams";, sattr "xmlns" "jabber:client", sattr
> "to" "livejournal.com" ] [] :: ArrowXml a => a XmlTree XmlTree
>
> And got:
>
>   :1:14:
>   Ambiguous type variable `a' in the constraint:
>   `ArrowXml a'
>   arising from instantiating a type signature at :1:14-194
>   Probable fix: add a type signature that fixes these type variable(s)
>
> i don't understand why i need to specify type signatures when they should
> already be in scope?

Is this a result of the monomorphism restriction?

> And if i /do/ need to specify the type signatures for 
> some reason, how do i do so in a manner that works?

You need to add a type signature that specifies a specific arrow data type 'a' 
that is an instance of ArrowXml.

There are many instances of ArrowXml provided in HXT, eg LA, IOSArrow, 
IOSLArrow, etc

so try something like:

let contact = mkelem "stream:stream" [ sattr "xmlns:stream" 
"http://etherx.jabber.org/streams";, sattr "xmlns" "jabber:client", sattr "to" 
"livejournal.com" ] [] :: IOSArrow XmlTree XmlTree

By the way, once you have the declaration of contact in a source file, and it 
is being used by a function in which the ArrowXml instance is not ambiguous 
eg:

foo = runX contact

the type checker will be able to infer the type and you don't have to include 
the type signature.

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

Re: [Haskell-cafe] GADTs vs arrows/typeclasses

[Daniel McAllansmith]

On Thursday 07 December 2006 09:44, S. Alexander Jacobson wrote:
> I guess I'm also not sure what belongs in a GADT and what belongs in a
> typeclass e.g. here is an Arrow GADT
>
>data Arrow b c where
>  Arr::(b->c) -> Arrow b c
>  Compose::Arrow b c -> Arrow c d -> Arrow b d
>  First::Arrow a b -> Arrow (a,c) (b,c)
>
> When Arrow is defined like this, rather than write instances you just
> various evaluation functions for the Arrow GADT.

How would the GADT solution handle the behaviours captured in the other Arrow 
classes, eg ArrowIf, ArrowLoop etc?

It doesn't seem right to just add constructors for all those extra functions.

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

Re: [Haskell-cafe] Cannot understand liftM2

[Daniel McAllansmith]

On Tuesday 12 December 2006 08:57, Nicola Paolucci wrote:
> - How do I know - or how does the interpreter know - that the "m" of
> this example is an instance of type ((->) e) ?
> - Is it always like that for liftM2 ? Or is it like that only because
> I used the function (-) ?

It's the snd that forces the interpreter to infer the ((->) e) monad.

You can guess from the type of liftM2 that the (-) won't supply any more 
information/constraints about m because m is is only mentioned in the snd and 
fst parts.

If you use different monadic values, instead of snd and fst, then the m will 
end up constrained to a different monad

Try these commands in GHCi to see what happens if you use something in the 
Maybe monad:

Prelude> :m + Control.Monad

Prelude Control.Monad> :t liftM2
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r

Prelude Control.Monad> :t liftM2 (-)
liftM2 (-) :: (Num a1, Monad m) => m a1 -> m a1 -> m a1

Prelude Control.Monad> :t liftM2 (-) (Just 5)
liftM2 (-) (Just 5) :: (Num a1) => Maybe a1 -> Maybe a1

Prelude Control.Monad> :t liftM2 (-) (Just 5) Nothing
liftM2 (-) (Just 5) Nothing :: (Num a1) => Maybe a1

Prelude Control.Monad> liftM2 (-) (Just 5) Nothing
Nothing


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

Re: [Haskell-cafe] GHC package lang not found

[Daniel McAllansmith]

On Saturday 16 December 2006 15:08, Aditya Siram wrote:
> Hi all,
> I am trying to install Hare but I cannot build it. GHC complains that
> package lang is not found. Here is the output:
[snip]
> ghc-6.6: unknown package: lang
>

I think that what use to be provided by lang is now part of ghc 6.6's base.  
I've got older cabalised stuff to build by just removing the dependency on 
lang.

You could try just removing any references to lang in the makefile, or 
whatever is invoking ghc.

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

Re: [Haskell-cafe] partial functions / failure, Maybe and MonadError and good style

[Daniel McAllansmith]

On Saturday 23 December 2006 14:21, Stefan O'Rear wrote:
> On Fri, Dec 22, 2006 at 08:05:08PM -0500, Steve Downey wrote:
> > Although terse, the subject really says it all.
> > If i've a partial function, like a parser, what is considered good
> > style for a library. The tradeoffs that I can see are that Maybe is a
> > binary operation, while Error can communicate more information in the
> > type  of the error case.
> > Is there some way to defer the error handling Monad to the calling
> > context?
>
> Your title answers the question. :)
>
> All monads provide a "fail" operation, and any function that uses fail will
> be able to work with any monad's error handling mechanism.

Though this obviously forces you to encode your library's error information 
into a String, which is a serious limitation in my book.

If your library is in an Error monad it seems straight forward for a consumer 
to get the fail behaviour, or even provide a wrapper in the library.  Going 
the other way and having to decode Strings into richer error constructs may 
or may not be straight forward. 

I recall there has been previous (lengthy) discussion on errors and fail in 
this list.  It might be worth having a trawl to get the different points of 
view.

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

Re: [Haskell-cafe] Simple HTTP lib for Windows?

[Daniel McAllansmith]

On Sunday 28 January 2007 09:14, Neil Mitchell wrote:
> Hi Alistair,
>
> > > Is there a simple way to get the contents of a webpage using Haskell on
> > > a Windows box?
> >
> > This isn't exactly what you want, but it gets you partway there. Not
> > sure if LineBuffering or NoBuffering is the best option. Line
> > buffering should be fine for just text output, but if you request a
> > binary object (like an image) then you have to read exactly the number
> > of bytes specified, and no more.
>
> This works great for haskell.org, unfortunately it doesn't work as
> well with the rest of the web universe.
>
> With www.google.com I get: Program error: : IO.hGetChar:
> illegal operation
>
> With www.slashdot.org I get: 501 Not Implemented returned
>
> www.msnbc.msn.com works fine.
>
> Any ideas why? 

At the very least it's missing the HTTP version on the request line, and you 
almost always need to send a Host header.

For a start you could try changing client to:

client server port page = do
  h <- connectTo server (PortNumber port)
  hSetBuffering h NoBuffering
  putStrLn "send request"
  hPutStrLn h ("GET " ++ page ++ " HTTP/1.1\r")
  hPutStrLn h ("Host: " ++ server ++ "\r")
  hPutStrLn h "\r"
  hPutStrLn h "\r"
  putStrLn "wait for response"
  readResponse h
  putStrLn ""

Note that I haven't tried this, or the rest of Alistair code at all, so the 
usual 30 day money back guarantee doesn't apply.  It certainly won't handle 
redirects.


> Are there any alternatives to read in a file off the 
> internet (i.e. wget but as a library)

The http library sort of works most of the time, but there are several bugs 
that cause it to fail on many 'in the wild' webservers.

HXT has a wrapper around a command line invocation of cURL.  It works better.  
There is still a problem with redirects, but thats an easy enough fix.
I doubt that it would be very easy to extract it from the surrounding HXT 
framework though.
It would be nice to have a binding to libcurl.

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

Re: [Haskell-cafe] Simple HTTP lib for Windows?

[Daniel McAllansmith]

On Sunday 28 January 2007 10:53, Neil Mitchell wrote:
> Thanks, it certainly gets more things, but has a nasty habit of taking
> a very long time in Hugs on certain URLs:
>
> research.microsoft.com/, 

Looks like IIS is waiting until it receives a Connection header, a bit of a 
variation from spec I think...
Adding in 
  hPutStrLn h ("Connection: close\r\n")
or
  hPutStrLn h ("Connection: keep-alive\r\n")
as appropriate should sort that.


> www.cs.york.ac.uk/ 

This is responding with a 302, the resource has been found but is temporarily 
at another location indicated in the responses Location header.
So, now you'll have to start parsing responses.
In this case the Location header is www.cs.york.ac.uk/public.php

>
> And on some urls, ie http://research.microsoft.com/~simonpj/, it still
> ends up with IO.hGetChar: illegal operation
>
> Any ideas why?

Hmmm, if you putStrLn the values of closed and eof it looks to be hanging 
during the eof check.  Don't know why.

Oh yeah, all the carriage-returns should be carriage-return line-feeds from 
memory.  Not that that seems to help with this problem.


The cheap and cheerful solution might be to invoke cURL.


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

Re: [Haskell-cafe] Simple HTTP lib for Windows?

[Daniel McAllansmith]

I've fallen off the pace on this thread so this is a composite reply, mainly 
to Bjorn, Brad and Yitzchak... 


I would also like to express my gratitude for the work that Bjorn, and all the 
others involved, have done on the http library.  I certainly appreciated 
having it available for use.


I agree that a full-featured HTTP library is important for Haskell.  And 
resource loading and serving as separate concerns on top of this.

The HTTP protocol is reasonably straight forward, and pretty well specified, 
so standards compliance should be achievable.  But to actually be useful in a 
lot of situations standards compliance is insufficient, many HTTP 
applications seem to be pretty poor efforts at compliance and being able to 
handle quirks is a necessity.

I think any library also needs to be robust in the face of malicious input.

One of the things that makes HTTP useful is that it is extendable.  Any 
library should expose this in a principled manner.


A wrapper around, say, cURL or a binding to libcurl is not a great solution in 
my opinion.  It would be cheap and provides more functionality than the 
current Haskell http library but lacks the separation of protocol and 
processing and lacks the extension aspects of HTTP.  And obviously it has 
foreign dependencies.

So I'd really like to see a pure Haskell option.  Unfortunately I don't agree 
that we are close to one now.  I'm not enthused about http being the basis 
for 'the feature-complete' library.


I'd like a library that at least has more static checks, is open to extension 
according to the protocol, allows subversion of standards compliance for case 
by case quirk handling and can be tuned to handle malicious input.


I would also like to contribute, and could enumerate my (half-baked) ideas and 
opinions if they are of interest.


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

[Haskell-cafe] Replacing [a] with (Set c a) in Monad instance.

[Daniel McAllansmith]

Hello.

Given:

newtype Dist a = D {unD :: [(a,Int)]}

instance Monad Dist where
  return x = D [(x,1)]
  d >>= f  = D [(y,q*p) | (x,p) <- unD d, (y,q) <- unD (f x)]
  fail _   = D []


How would one change Dist to wrap an instance of the (Data.Edison.Set c a) 
typeclass so that the Monad instance could be implemented in terms of e.g. 
singleton, unionWith, empty, etc?


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

Re: [Haskell-cafe] Replacing [a] with (Set c a) in Monad instance.

[Daniel McAllansmith]

On Wednesday 31 January 2007 22:36, Robert Dockins wrote:
> On Tuesday 30 January 2007 20:06, Bryan Donlan wrote:
> If you instead want to replace your list with one of the Edison sequence
> implementations, that should be possible.  However, I'm not really sure
> that it's going to buy you a lot.  From a quick glance, it looks like the
> regular list type is going to be the best datastructure for the
> computational pattern of this monad, as long as your computations are
> sufficiently lazy.

Currently some external code is not lazy so the stack gets blown.  My 
knee-jerk reaction was to try and reduce the state space by exploiting 
symmetries.  I'll try sticking with the list and making things more lazy, and 
hopefully still be able to collapse the symmetric cases.

>
> > However, Roberto Zunino
> > came up with a clever way to bypass this problem with GADTS:
> > http://article.gmane.org/gmane.comp.lang.haskell.cafe/18118
> >
> > You may be able to apply this to your situation, using various Edison
> > collections depending on which typeclasses your monad argument
> > implements.

Thanks for the links, I'll have a look at them if I have no luck with 
increasing the laziness.


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

Re: [Haskell-cafe] Extracting structured data in XML into records

[Daniel McAllansmith]

On Saturday 24 February 2007 21:22, Johan Tibell wrote:
> So my question is. How can I write the function
> 'extractElementsIntoRecords' below. Or, perhaps HXT is the wrong tool
> for the job and I should be trying to walk the DOM tree instead?
>
> > module HCard where
> >
> > import Text.XML.HXT.Arrow
> >
> > data HCard = HCard
> > {
> >   familyName :: String,
> >   givenName :: String
> >   org :: Maybe String
> >   url :: Maybe String
> > } deriving Show
> >
> > parseHCards xml = runX $ parseXml xml
> >
> > parseXml xml =
> > readString [(a_parse_html, v_1)] xml >>>
> > deep (hasClassName "vcard") >>>
> > extractElementsIntoRecords
> >
> > extractElementsIntoRecords = undefined

Perhaps something like the following (which is likely to be wrong seen I'm 
adlibing):

extractElementsIntoRecords = findFName <+> findGName <+> findOrg <+> findURL
where
findX c = deep (hasName "span" >>> hasAttrValue "class" (== c)) >>> 
getChildren >>> getText
findFName = findX "family-name" >>> arr Just
findGName = findX "given-name" >>> arr Just
findOrg   = (findX "org" >>> arr Just) `withDefault` Nothing
findURL   = (deep (hasName "a" >>> hasAttrValue "class" (== "url)) >>> 
getAttrValue "href" >>> arr Just) `withDefault` Nothing

and use the following at an appropriate place:

composeHCard (Just fn:Just gn:morg:murl:xs) = (HCard fn gn morg murl):(compose 
xs)
composeHCard _ = []

There's several other possibilities for dealing with bad data and 
simplifications you could do of course.


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

Re: [Haskell-cafe] IO and lazyness.

[Daniel McAllansmith]

On Wednesday 07 March 2007 10:22, D.V. wrote:
> On 3/6/07, mm <[EMAIL PROTECTED]> wrote:
> > I cannot help you with your question more than pointing you to
> >
> > http://bugs.darcs.net/issue391
> >
> > where Simon Marlow explains how to avoid "IO.bracket".
>
> I'm using Control.Exception's bracket.
>
> Also, following Jeremy's advice, I replaced the last line of rechf2
> with   return $! rech r $ lines f   and indeed it works.
>
> I don't understand why it doesn't without the !
>
> The documentation for hGetContents says the items are read on demand.
> the function rech needs the strings so they should be read on demand.
> This confuses me :(

The problem is that hGetContents only reads the contents of the file on demand 
and, without the 'return $!' you don't demand the value until somewhere 
outside of rechf.  By this point the hClose has happened and hGetContents has 
no access to the file => no lines => no result.

Using 'return $!' is demanding the value of rech r $ lines f immediately so 
hGetContents accesses the file before the hClose.


hGetContents is implemented using unsafePerformIO so, unless you're very 
careful, you could get other weird behaviours.


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

Re: [Haskell-cafe] IO and lazyness.

[Daniel McAllansmith]

On Wednesday 07 March 2007 10:56, D.V. wrote:
> > The problem is that hGetContents only reads the contents of the file on
> > demand and, without the 'return $!' you don't demand the value until
> > somewhere outside of rechf.  By this point the hClose has happened and
> > hGetContents has no access to the file => no lines => no result.
>
> I must be really dumb but I don't get why 'at this point the hClose
> has happened'

Not at all.  Mixing laziness and unsafe IO can be tricksie little devils.  A 
bit like vinegar and baking soda, or, perhaps more accurately, nitric acid 
and a bale of cotton.

My general advice would be to stay away from hGetContents (which is unsafe) 
and just use explicit mechanisms, at least until your more familiar with 
haskell.

>
> It seemed to me that when I typed at ghci's promptrechf ""  it
> tries to evaluate it.

As an aside ghci is actually executing something like 
putStrLn . show $ rechf ""
as a convenience for you.  It's demanding the value of rechf "" so that it 
can print it out.

> that makes it perform the IO action of opening the file, then
> performing the IO action of evaluating ( since I need the result )
> rechf2 "" and *lastly* performing the IO action of closing the
> file.

Your program actually says:
1) open file handle
2) create a String that will be read _on demand_ from file handle
3) close file handle
4) print the value which is computed from the String

Step 2 doesn't read anything from the file because it is lazy.
Step 4 the putStrLn that ghci added for you needs the String, which needs to 
read from the file, but it's too late.

When you insert the print that you originally had commented out you're adding 
a step 2.5 which needs value of the String which causes the file to be read.

As Matthew Brecknell shows it can be difficult to write a 'Step 2.5' that 
fixes the problem.



>
> So to me either I'm just too confused to understand or something
> doesn't work as it should be.

It's working as expected, the expectation being that the mixing of laziness 
and unsafe IO is likely to give you a headache unless you really know what 
you're doing.

The documentation of hGetContents could make this clearer, I think.

>
> I also tried using readFile ( again following Jeremy's suggestion )
>
> and it works :
> > rechf r = do
> >   f <- readFile "liste"
> >   return $ rech r $ lines f

Yeah, my advice is to use the explicit mechanisms, which aren't difficult, at 
least until you know enough not to blow your fingers off.

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

Re: [Haskell-cafe] Haskell File reading

[Daniel McAllansmith]

On Wednesday 07 March 2007 17:16, cornmouse wrote:
> I have a txt file, which contains a paragraph. I am trying to read the
> file, and pass the contents of the file as a string to another function
> called "createIndex". "createIndex" is a function to generate index of the
> input string.
>
> Below is my code to read the file :
>
> main :: IO ()
> main
>  = do
>  putStr "Enter input file name.txt: "
>  filename <- getLine
>  content <- readFile filename
>  createIndex content
>
> createIndex  ::  String  ->  [ ([Int], String) ]
> createIndex
>{- contents of the function... -}
>
> I am using Hugs compiler, when i execute, i got an error
> Type error in generator
> *** Term   : showString content
> *** Type   : [Char] -> [Char]
> *** Does not match : IO a
>
> IO>
>
> I know the data type doesn't match. How do i go about this?

What do you want to do with the index?

Maybe you want to print the index out, in which case change
createIndex content
to
putStrLn (show (createIndex content))

That'll work because

show :: (Show a) => a -> String

turns your index into a string, and then

putStrLn :: String -> IO ()

takes the string and carries out an IO computation, that has a side effect of 
putting some text on screen, and returns a value of (), which matches the 
type of main.

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

Re: [Haskell-cafe] Poor first impression

[Daniel McAllansmith]

http://www.google.com/search?hl=en&q=fedora+haskell+libreadline.so.4&btnG=Search&meta=

gives:
http://www.nabble.com/-Haskell--Re:-kernel-2.6.11-and-readline.so-t577156.html

as the first result, which appears to give a solution


and, in fact, if I look at:
http://haskell.org/ghc/download_ghc_661.html

which is where I presume you got the rpm from it states that:

"Note: You need the libreadline.so.4 and libncurses.so.5 libraries to use 
this. Newer Linux distributions come with libreadline.so.5 only (e.g. SuSE 
9.2), so we have provided a readline4 compatiblity RPM for this case."

I've got a sneaking suspicion that the 'readline4 compatibility RPM' linked to 
would solve your problem.


Or maybe the fedora package manager chases dependencies?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Silly mail client

[Daniel McAllansmith]

On Sunday 06 May 2007 21:15, Andrew Coppin wrote:
> OK, this is hacking me off now... Does ANYBODY know how I can convince
> Thunderbird to send replies to Haskell Cafe rather than sending them to
> the original poster? This is really becoming tiresome...

Looks like you're on windows so maybe this is worthless information, but...

There seems to be an extension to add a Reply-To-List feature.  Apparently it 
requires a patch that has been applied by Debian, Suse and Gentoo.  Dunno 
whether you can get it to work with windows.

Heres a link:
http://alumnit.ca/wiki/index.php?page=ReplyToListThunderbirdExtension
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Darcs annotate denies all knowledge of files...

[Daniel McAllansmith]

On Friday 18 May 2007 09:42, Dougal Stanton wrote:
> I just did a fresh pull of hpodder to see if there was still a bug in
> it that I just found in the feisty version. I ran
>
> > $ darcs get --partial http://darcs.changelog.org/hpodder
> > $ darcs annotate Commands/SetTitle.hs
> >
> > darcs failed:  There is no file or directory named 'Commands/SetTitle.hs'
>
> What gives?

Maybe because you did a partial get?  

Though you'd hope that darcs would complain in a clearer manner if there are 
no patches to process.


I can't seem to resolve darcs.changelog.org at the moment so couldn't try it 
out myself.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] New book: Real-World Haskell!

[Daniel McAllansmith]

On Wednesday 23 May 2007 19:01, Donald Bruce Stewart wrote:
> Bryan O'Sullivan, Don Stewart and John Goerzen are pleased, and frankly,
> very excited to announce that were developing a new book for O'Reilly, on
> practical Haskell programming. The working title is Real-World Haskell.

That's good news, Don.  I look forward to it.

> You can find more details and updates at the following locations:
>
> * The web site, http://www.realworldhaskell.org/blog/welcome/
> * The authors,  http://www.realworldhaskell.org/blog/about/
> * The blog, http://www.realworldhaskell.org/blog/

It might just be me, but I think there's something up with a redirect or 
something...

I went to 

http://book.realworldhaskell.org/ 

then clicked the link to go to 

http://www.realworldhaskell.org/book/ 

I end up at

http://book.realworldhaskell.org//

the extra forward slash isn't a typo.


No biggie, but I thought I'd let you know.


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

Re: [Haskell-cafe] Stack overflow

[Daniel McAllansmith]

On Friday 25 May 2007 06:50, Grzegorz wrote:
> Hi all,
> I have a simple piece of code which is giving me stack overflow. I guess I
> need to make it stricter sowhere but I can't figure out extactly where. So
> I thought I'd ask the experts.

I'm not sure.  A real expert from the list will probably tell you what the 
cause of the overflow is.

As for finding the mean hamming distance, have you considered something like 
the following:

hammingDistance xs ys = length (filter not (zipWith (==) xs ys))

meanHammingDistance xss yss = sumHDs / cntHDs
where
hds = map (uncurry hammingDistance) [(xs, ys) | xs <- xss, ys <- yss]
sumHDs = fromIntegral (sum hds)
cntHDs = fromIntegral (length hds)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] The C Equiv of != in Haskell

[Daniel McAllansmith]

On Tuesday 29 May 2007 13:20, PR Stanley wrote:
> >Hi
> >
> >>What is the C equivalent of the inequality operator in Haskell?
> >
> >/=
> >
> >You can answer these sorts of questions yourself using Hoogle:
>
> And what makes you think I haven't tried Google already?
> Unlike you I only write to the list when I have a legitimate reason to do
> so.

Just in case there was some sort of miscommunication, the actual answer to 
your question is (/=) :: a -> a -> Bool, as Neil said.

The /= wasn't some sort of frowny, quit-wasting-my-time emoticon.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: HXT 7.4/7.5 leaking TCP connections

[Daniel McAllansmith]

Hello all.

On Wed, 09 Apr 2008 05:36:40 Paul Brown wrote:
> Hi, Bjorn and Uwe --
>
> >  >  this is a known problem with HTTP package (version 3001.0.4).
> >  >  Paul Brown has described this somewere in his blog.
> >  >  (http://mult.ifario.us/t/haskell), but my firefox only shows
> >  >  an incomplete page of this blog, the solution is missing.
> >  >  Paul promissed in his blog to send a patch to Björn Bringert.

I'm not so sure it's due to the bug that Paul has patched.

http was my first suspect and I managed to find a google cache of Paul's page, 
which wouldn't load for me.

I've tried patching http with both patches on that page (one by Paul, one 
suggested in a comment).
I then incremented http's version and rebuilt, changed the dependencies to 
require that version of http in HXT 7.5 and rebuilt, then required those 
versions in my test program.
It still leaks TCP connections.

I think that means that everything is using the patched http.  Can I query 
what installed packages are linked against somehow?


Paul's patch looks to ensure connections are closed when there is an 
exception, I'm leaking (I think) every TCP connection.  Here's the test code 
again for the -cafe.  Is there something obvious wrong with it?


module Main where

import Control.Exception (bracket)
import Control.Monad (unless)
import Text.XML.HXT.Arrow
import System.IO (IOMode(..), hClose, hGetLine, hIsEOF, openFile)

--/tmp/list.txt is a list of files on a local webserver.
main = bracket (openFile "/tmp/list.txt" ReadMode) hClose processAll

processAll hdl = do
  b <- hIsEOF hdl
  if b
then return "done"
else processNext hdl

processNext hdl = hGetLine hdl >>= process >> processAll hdl

process s = runX (getXmlPageBad (buildURL s))
--process s = runX (getXmlPageOK (buildURL s))

buildURL = ("http://localhost.localdomain/"; ++)

getXmlPageOK = readDocument [
(a_use_curl, "1"),
(a_parse_html, "1"),
(a_encoding, isoLatin1),
(a_issue_warnings, "0")
]

getXmlPageBad = readDocument [
(a_parse_html, "1"),
(a_encoding, isoLatin1),
(a_issue_warnings, "0")
]
===


A related question is: what does an open TCP connection that gets garbage 
collected turn into?  I've been seeing lines like the following is lsof, and 
they still count toward the open file limit, I suspect they're garbage 
collected connections.

test 28300 daniel 1023u  sock 0,4 13900773 can't identify protocol

>
> Here's the link to the article about SimpleHTTP; for some reason, it
> wasn't showing up.  (Guess I have a bug to fix there...)
>
> http://mult.ifario.us/p/a-short-adventure-with-simplehttp
>
> >  >  P.S. to Björn: It would be nice, if you could include this change
> >  > into the HTTP module and upload a new version to hackage.
> >
> >  Thank you Daniel and Uwe for reporting this (again). Strangely, I
> >  thought that I had already applied Paul's patch, but it seems I
> >  haven't. Paul: I seem to recall us talking about this, but can't
> >  remember the conclusion, nor find any e-mail about it. Do you remember
> >  anything about this?
>
> I can't remember either; I'm sure that the darcs patch is lurking on
> one of my boxes.  I'll track it down and send it your way so we can
> squash this one.

As I said, I've patched the latest darcs code with both the suggested patches 
on Pauls page, I can send either/both through to you if you would like Björn.


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

[Haskell-cafe] http: Network.Browser leaks TCP connections

[Daniel McAllansmith]

I've looked into this further and I believe the leaked connections are due to 
Network.Browser, this is a separate issue from that identified by Paul Brown.

The BrowserState in Network.Browser has a connection pool of up to five 
connections.  When a sixth is opened the oldest connection is closed.  This 
looks to be the only time that a connection is closed.
BrowserState's internals are not exported so there is no way for a user to 
close them.

The net effect for HXT is that every time readDocument is called, using native 
http, a single TCP connection is leaked.

I've attached a patch against the darcs version of http that cures my test 
programs leak.

Cheers
Daniel

New patches:

[Make browse close pooled connections to prevent them leaking.
'Daniel McAllansmith <[EMAIL PROTECTED]>'**20080411025515
 The closing of the connections needs to be made exception safe.  Should try to
 close every connection before breaking out with an exception.  Currently an
 exception may allow connections to leak.
] {
hunk ./Network/Browser.hs 656
-browse act = do x <- lift act defaultBrowserState
-return (snd x)
+browse act = do (bs, x) <- lift act defaultBrowserState
+closePooledConnections bs
+return x
hunk ./Network/Browser.hs 675
+-- |
+-- Close all connections that are in bs' connection pool.
+-- This should have some sort of exception handling, soldier on until
+-- all the connections have been closed.  Not sure about portability
+-- issues.
+closePooledConnections :: BrowserState -> IO ()
+closePooledConnections = mapM_ close . bsConnectionPool
+
}

Context:

[Bump version number to 3001.1.0. Incremented minor number since the patch from Eric Mertens extends the API.
[EMAIL PROTECTED] 
[Export getRequestHead and processRequest, add support for custom RequestMethods
Eric Mertens <[EMAIL PROTECTED]>**20080305190759] 
[Include uriQuery in request line.
[EMAIL PROTECTED] 
[Send abs_path as Request-URI to comply with HTTP 1.1 spec.
'Daniel McAllansmith <[EMAIL PROTECTED]>'**20080128053024
 RFC2616 Section 5.1.2 specifies that abs_path MUST be used to identify a resource on a origin server or gateway, not absoluteURI which is for use with proxies.
 
 Change Request's Show instance to use /path/to/resource rather than
 http://server/path/to/resource.
] 
[Bump version to 3001.0.4
[EMAIL PROTECTED] 
[Expose Network.HTTP.Headers in cabal file
Eric Mertens <[EMAIL PROTECTED]>**20071212220235
 
 Failure to do this breaks :browse functionality in GHCi
 as well as makes these useful functions unavailable
] 
[Resolved conflicts in Network.Stream.
[EMAIL PROTECTED] 
[Resolve conflict in HTTP.cabal.
[EMAIL PROTECTED] 
[Split Header functionality into Network.HTTP.Headers module.
[EMAIL PROTECTED] 
[Added files to .cabal file, made deps explicit in Network.TCP module.
[EMAIL PROTECTED] 
[Refactored Network.Stream.
[EMAIL PROTECTED] 
[Made more deps explicit.
[EMAIL PROTECTED] 
[Made dependencies explicit in import statements.
[EMAIL PROTECTED] 
[Bumped version number to 3001.0.3.
[EMAIL PROTECTED] 
[Change myrecv to allow a 0 length. Suggested by Eric Mertens.
[EMAIL PROTECTED]
 On Wed, 2007-08-15 at 23:25 +0200, Bjorn Bringert wrote:
 Why doesn't the existing code work? Does recv fail when given 0?
 
 On Nov 30, 2007, at 23:36 , Eric Mertens wrote:
 Yes, recv can not cope with an argument of 0
 
 http://darcs.haskell.org/packages/network/Network/Socket.hsc
 
 recv :: Socket -> Int -> IO String
 recv sock l = recvLen sock l >>= \ (s,_) -> return s
 
 recvLen :: Socket -> Int -> IO (String, Int)
 recvLen sock@(MkSocket s _family _stype _protocol status) nbytes 
  | nbytes <= 0 = ioError (mkInvalidRecvArgError "Network.Socket.recv")
 
] 
[Set version number to 3001.0.2.
[EMAIL PROTECTED] 
[Change version to 3001.0.1.
[EMAIL PROTECTED] 
[Don't treat any chunk size starting with '0' as a 0 chunk size.
[EMAIL PROTECTED]
 Radosław Grzanka reported that Network.HTTP can't get http://www.podshow.com/feeds/gbtv.xml, see http://article.gmane.org/gmane.comp.lang.haskell.cafe/31783
 
 This turned out to be a bug in how Network.HTTP handled Chunked Transfer Encoding. The web server sent the chunk size as "4000" (according to RFC 2616 this can be non-empty sequence of hex digits). However, Network.HTTP treated any chunk size starting with '0' as a chunk size of 0, which indicates the end of the chunked encoding. 
] 
[TAG 3001.0.0
Duncan Coutts <[EMAIL PROTECTED]>**20071021133823] 
Patch bundle hash:
2606de184a3abe46c8095959a11a2f60575ceada
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

[Daniel McAllansmith]

On Mon, 14 Apr 2008 11:06:43 Adam Langley wrote:
> On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <[EMAIL PROTECTED]> 
wrote:
> >  * Using a different set of data types would work better.
>
> Give that this is Haskell, I'd suggest more types ;)
>
> HTTP headers aren't just strings and, at the risk of tooting my own
> horn, I'll point to the Headers structure in [1]. 

And it could go further.  The use of a given header is often valid only in 
certain requests or responses.  Perhaps sprinkling some phantom types or type 
classes around could represent that.

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

[Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)

[Daniel McAllansmith]

On Mon, 14 Apr 2008 13:32:07 Chris Smith wrote:
> On Sun, 13 Apr 2008 16:06:43 -0700, Adam Langley wrote:
> > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <[EMAIL PROTECTED]>
> >
> > wrote:
> >>  * Using a different set of data types would work better.
> >
> > Give that this is Haskell, I'd suggest more types ;)
> >
> > HTTP headers aren't just strings and, at the risk of tooting my own
> > horn, I'll point to the Headers structure in [1].
>
> Wait, I'm not sure I agree here.  How are headers not just strings?  

Headers, at least their values, aren't strings.  The specification says so.
I think headers should be represented by something more specific than a string.

> By 
> assuming that, are we guaranteeing that anything using this interface
> cannot respond gracefully to a client that writes malformed headers?

Having explicit types for headers doesn't preclude trying to handle messages 
with malformed headers.  Soldiering on in the face of malformed messages as a 
general strategy is pretty dubious in my opinion.  In the specific cases where 
you've determined it is necessary you want to be able to register a work-around 
parser for that section of the message, and be able to tell that it has been 
used.  A decent framework can supply a catalogue of commonly required 
work-arounds.

>
> Another perspective: there is unnecessary variation there in how
> interfaces are represented.  If I'm looking for a header, and I know its
> name as a string, how do I look for it?  Well, apparently it's either a
> named field (if it's known to the interface) or in the "other" section
> (if not).  So I write a gigantic case analysis?  But then suppose the
> interface is updated later to include some headers that popped up
> unofficially but then are standardized in a future RFC.  (This is not too
> odd; lots of REST web services invent new headers every day, many of
> which do things that make sense outside of the particular application.)
> Does old code that handled these headers stop working, just because it
> was looking in the "other" section, but now needs to check a field
> dedicated to that header?

I don't like the idea of having a fixed enumeration of methods or headers.

You need to be able to define new methods and headers at will, and ideally have 
the usage of headers constrained to valid contexts.

This suggests to me type classes that establish a 'can occur in' relationship 
between request/response, method and a given general/request/response/entity 
header.  

By importing new method or header data type, appropriate type class instances 
and registering an appropriate message parser extension you can mix and match 
which headers and methods you support.  GET and HEAD are the only ones that 
MUST be supported after all.

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

Re: [Haskell-cafe] HTTP package: connection closing bug?

[Daniel McAllansmith]

On Fri, 22 Aug 2008 11:12:08 Arjun Guha wrote:
> > Aha, I knew I wasn't dreaming!
> >
> > 
> >
> > Paul Brown posted this discussion back in February. It looks like the
> > same thing. Has there been an update of HTTP since then?
>
> Nope, it hasn't been updated.  I'm just running a locally patched
> version.  This is the same issue, thanks!

Beware of the browse function in Browser, there is a connection leak in there 
as well, at least there was back in March or April.  Not sure if it has been 
fixed in the official repos.

I seem to recall the sockets getting put into some half-closed state, 
presumably when GHC GC'd them, eventually exhausting limits.  That may be 
particular to running on Linux, I guess.

Dan

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

Re: [Haskell-cafe] HTTP package: connection closing bug?

[Daniel McAllansmith]

On Fri, 22 Aug 2008 14:15:48 Duncan Coutts wrote:
> On Thu, 2008-08-21 at 19:12 -0400, Arjun Guha wrote:
> > > Aha, I knew I wasn't dreaming!
> > >
> > > 
> > >
> > > Paul Brown posted this discussion back in February. It looks like the
> > > same thing. Has there been an update of HTTP since then?
> >
> > Nope, it hasn't been updated.  I'm just running a locally patched
> > version.  This is the same issue, thanks!

Looks like there is a patch committed to http's darcs repo, 3rd May, from prb 
to address this problem.

>
> If someone could figure out the right fix and send it to the maintainer
> that'd be great. We do need a decent working pure-haskell http package.

Agreed.  I think http needs serious work before it would fit the bill though.

> For one thing cabal-install uses the HTTP package and it has to work for
> downloading dozens or hundreds of packages in a single session.
>
> As an aside, cabal-install could use the Network.Browser module better,
> by using a single call to browse for all downloads rather than one per
> download. As I understand it, that'd allow it to re-use a single
> connection.

It's quite likely you are leaking a connection on every call to browse.  I 
recall someone asking about how to configure hackage's Apache to handle more 
than 1000 open connections... maybe cabal-install is the reason for it 
needing so many concurrent connections.

I've sent a patch for Network.Browser.browse to Bjorn.


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

Re: [Haskell-cafe] Error in HTTP 4.004 + CouchDB?

[Daniel McAllansmith]

On Sat, 24 Jan 2009 14:18:24 Tristan Seligmann wrote:
> * Alex Ott  [2009-01-22 20:32:26 +0100]:
> > PUT http://127.0.0.1:5984/test1/Users_ott_tmp_1_tst HTTP/1.1
> > Content-Type: ...
> > ...
> > Host: 127.0.0.1:5984
> > ...
>
> Note that this is a valid HTTP request, according to my reading of RFC2616.

Depends what you mean by valid.  Yes it's a valid request to receive, no an 
implementation is not compliant with RFC2616 if it issues a request like this 
to an origin server.

Have a look at section 5.1.2.  An implementation is REQUIRED to issue requests 
like this to proxies, an implementation MUST handle receiving requests like 
this, an implementation MUST use the abs_path form in requests to origin 
servers and gateways, ie

PUT /test1/Users_ott_tmp_1_tst HTTP/1.1
Host: 127.0.0.1:5984

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

Re: [Haskell-cafe] Correct usage of MonadError, ErrorT?

[Daniel McAllansmith]

On Tuesday 31 January 2006 16:32, Andrew Pimlott wrote:
> On Tue, Jan 31, 2006 at 03:00:41PM +1300, Daniel wrote:
> > I've got some functions in MonadError with different Error types.  I
> > would like to map errors of one Error type onto the other Error type.
> >
> > It seems that the only facility for doing this is mapErrorT, but that
> > seems to force me to work in ErrorT rather than any old instance of
> > MonadError.
>
> What type would your mapError have?  The first idea that comes to mind
> is
>
> mapError :: (MonadError e1 m1, MonadError e2 m2) =>
> (e1 -> e2) -> m1 a -> m2 a
>
> The problem here is that m1 and m2 have no relation--m1 could be IO and
> m2 (Either e2)!  Not surprisingly, we can't implement that.  

Yeah, I expected that would be difficult.
Is it actually impossible or does it just result in an explosion of code in 
the implementation, needing a clause to map each instance of MonadError to 
each other instance on MonadError?
Not that I'm suggesting that solution, it's just that I'm new to this stuff 
and don't immediately see why it's impossible (as opposed to impractical).

> So what 
> relation do you want between m1 and m2?  The only one I can think of is
> that m1 and m2 are ErrorT transforms of the same inner monad.

Yep.  That's what I was thinking of.

> In this 
> case mapErrorT fits the bill, though it would probably be more
> convenient to define your own version that maps only the error:
>
> mapErrorTE :: (e1 -> e2) -> ErrorT e1 m a -> ErrorT e2 m a

Ok, so mapErrorT, or a convenient wrapper, is the right tool for this 
situation?

If so, doesn't using mapErrorT bind the general MonadError class to the 
specific ErrorT instance?
So,
g :: (MonadError String m, MonadIO m) => Int -> m String
would have to become
g :: (MonadIO m) => Int -> ErrorT String (m String)
and that change will propagate out through any function which calls g.

It feels bad to me to lose that generality.  Is that just a hangover from 
other/weaker languages?
Is it good advice for a new haskeller to stick to ErrorT in functions with 
errors?

>
> Do you have an example where a more generic mapError would make sense?

Where the inner monad is changed as well?  No, but I can't say that I've tried 
very hard.  I'm finding that I have to take quite small bites of haskell so 
my brain doesn't get indigestion :)

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

[Haskell-cafe] GADTs and bar :: Foo t1 -> Foo t2

[Daniel McAllansmith]

Hello,

I have a recursive type 

> data Foo = A | B [Foo] | C [Foo]

that I would like to restrict so that a C can only contain Bs, and a B can 
only contain As.
If I use a GADT as follows the bar function, understandably, will not type 
check.

> data AType
> data BType
> data CType

> data Foo a where
> A :: Foo AType
> B :: [Foo AType] -> Foo BType
> C :: [Foo BType] -> Foo CType

> --get the successor of the Foo
> bar c@(C []   ) = c
> bar   (C (b:_)) = b
> bar b@(B []   ) = b
> bar   (B (a:_)) = a
> bar [EMAIL PROTECTED] = a

How do I achieve this restriction?  Do I need to have some sort of successor 
class with dependent types?

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

Re: [Haskell-cafe] GADTs and bar :: Foo t1 -> Foo t2

[Daniel McAllansmith]

My thanks for the responses received off-list.

Dimitrios pointed out that a 'successor' class solution would require the 
typechecking to depend somehow on whether the lists were empty or not.
Probably a clue that I was on the wrong track.

Both Cale and Dimitrios suggested better solutions involving different data 
types:

data FooA = A
data FooB = B [FooA]
data FooC = C [FooB]
data Foo = FA FooA | FB FooB | FC FooC

or

data Node a = N [a] deriving Show
data Tree a = Zero a | Succ (Tree (Node a)) deriving Show

or

data EXFoo where
  EXFoo :: Foo a -> EXFoo


Embarrassingly simple! :)

Thanks
Daniel


On Friday 17 February 2006 19:18, Daniel McAllansmith wrote:
> Hello,
>
> I have a recursive type
>
> > data Foo = A | B [Foo] | C [Foo]
>
> that I would like to restrict so that a C can only contain Bs, and a B can
> only contain As.
> If I use a GADT as follows the bar function, understandably, will not type
> check.
>
> > data AType
> > data BType
> > data CType
> >
> > data Foo a where
> > A :: Foo AType
> > B :: [Foo AType] -> Foo BType
> > C :: [Foo BType] -> Foo CType
> >
> > --get the successor of the Foo
> > bar c@(C []   ) = c
> > bar   (C (b:_)) = b
> > bar b@(B []   ) = b
> > bar   (B (a:_)) = a
> > bar [EMAIL PROTECTED] = a
>
> How do I achieve this restriction?  Do I need to have some sort of
> successor class with dependent types?
>
> Ta
> Daniel
> ___
> 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] Best representation of graph for use in a zipper?

[Daniel McAllansmith]

Hi

I've been having a look at zippers over homogenous tree data types, and was 
wondering how best to represent a heterogeneous graph for manipulation with a 
zipper.

The main example of zippers I've been looking at is
http://okmij.org/ftp/Computation/Continuations.html#zipper-fs
and
http://okmij.org/ftp/Computation/Continuations.html#zipper
from which I've included a small extract at the end of this email to provide 
extra context if necessary.


For contrived example, given a relational model:

.Album
.  |1
.  |
.  |
.  |1..n0..n   1
.PerformanceSong
. |0..n   |1
. |   |
. |   |0..n
. |1   WritingCredit
. Performer   |0..n
.  ^ ^|
.  | |--  |
.  |   |  |
.  |  1   1..n |  |1
.GroupArtist

I could write a data type:

> data MC
> = Album   {perfs ::[MC]}
> | Performance {album :: MC, song :: MC, performer :: MC}
> | Song{perfs :: [MC], artistCredits :: [MC]}
> | Group   {perfs ::[MC], artists :: [MC]}
> | Artist  {perfs :: [MC], songCredits :: [MC]}
> | Root{albums :: [MC]}

The first problem I have with this is that it doesn't enforce enough 
structural constraints.
Secondly, as I understand it, whilst zippers can handle cyclic structures they 
do so by doing a 'copy-on-write'.  I would like to maintain shared instances.

I could flatten the data type graph to a minimal spanning tree:

> data MCFK = MCFK
> data MC
> = Album   {fKey :: MCFK, perfs ::[MC]}
> | Performance {fKey :: MCFK, songFK :: MCFK, performer :: MCFK}
> | Song{fKey :: MCFK, artistCredits :: [MCFK]}
> | Group   {fKey :: MCFK, artists :: [MC]}
> | Artist  {fKey :: MCFK}
> | Root{albums :: [MC], songs :: [MC], groups :: [MC], 
soloArtists :: [MC]}

This seems a bit better.  The traversal function doesn't have to worry about 
cycles and there's less mainenance updates to do.  But it still doesn't offer 
any structural or foreign key guarantees.

I thought that I would be able to use a GADT to give structural guarantees, 
though not FK guarantees, but once I move to a GADT I don't know how to write 
a traversal function as the next node could be of several different types.

Any advice on how to get a safer data structure, and write the necessary 
traversal function, would be much appreciated.

Cheers
Daniel



Following is an extract from the links above.  Note that I have floated the 
functions local to traverse up to the top level to get at them with GHCi


> data Term = Var String | A Term Term | L String Term deriving (Show)
> 
> data Direction = Down | DownRight | Up | Next deriving (Eq, Show)
> 
> traverse :: (Monad m) => (Direction -> Term -> m (Maybe Term, Direction)) -> 
Term -> m Term
> traverse tf term = traverse' tf id Down term >>= maybeM term id
> 
> 
> traverse' tf next_dir init_dir term = do
> (term', direction) <- tf init_dir term
> let new_term = maybe term id term'
> select tf (next_dir direction) new_term >>= maybeM term' Just
> 
> next next_dir dir = if dir == Next then next_dir else dir
> 
> maybeM onn onj v = return $ maybe onn onj v
> 
> select tf Up t = return Nothing
> select tf Next t@(Var _) = return Nothing
> select tf dir t@(L v t1) | dir == Next || dir == Down = do
> t' <- traverse' tf id Down t1 >>= (return . fmap (L v))
> traverse' tf (next Up) Up (maybe t id t') >>= maybeM t' Just
> select tf DownRight t@(A t1 t2) = do
> t' <- traverse' tf id DownRight t2 >>=
> (return . fmap (\t2'->(A t1 t2')))
> traverse' tf (next Up) Up (maybe t id t') >>= maybeM t' Just
> select tf dir t@(A t1 t2) | dir == Next || dir == Down = do
> t' <- traverse' tf id Down t1 >>=
> (return . fmap (\t1'->(A t1' t2)))
> traverse' tf (next DownRight) Up (maybe t id t') >>=
> maybeM t' Just
> 
> 
> --Testing
> trav dir term = do print dir; print term; return (Nothing,Next)
> 
> 
> term1 = A (Var "v1") (L "l1" (A (Var "v2") (Var "v3")))
> 
> test1 = traverse trav term1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Building Monads from Monads

[Daniel McAllansmith]

Hi, I've got a few (9) random questions, mainly about monads and building 
monads from existing monads, partly trying to confirm conclusions I've come 
to through experimentation.

Any, and all, attempts to enlighten me will be much appreciated.

Thanks
Daniel

First, terminology.  In
StateT s (ReaderT r IO) ()
Q. 1) StateT is referred to as the outermost monad, and IO as the innermost 
monad, correct?



Using a monadic function, eg MonadReader.ask, in a monadic expression will 
access the outermost monad of the appropriate class.
Q. 2) Does this work for all monad classes in all expressions?



How does Control.Monad.Trans.lift work?  It seems that a single application of 
lift will find the next outermost monad of the appropriate class, but if you 
want to dig deeper into the nest you need to apply lift according to the 
monads actual depth in the nest.
Q. 3) Why the different behaviour?

Q. 4) Is it possible to give a type to the lifted function so that the monad 
of the correct class _and_ type is used?  E.g. dig into a String Reader 
rather than an Int Reader.

Defining an instance of MonadTrans for a monad instance seems universally 
useful.
Q. 5) Are there obvious situations where it's not useful or possible?



Carrying out IO in a nested monadic expression requires liftIO.  Apart from 
having to type an extra 7-9 characters it seems good to use liftIO even in 
plain IO monad expressions so they can become nested expressions with no 
trouble later on.
Q. 6) Is it safe to always use liftIO, even in plain IO monad?
Q. 7) If it's safe to do, why aren't functions in the IO monad just typed in 
the MonadIO class instead?



It looks to me like types with class constraints are better than types 
specifying nests of monad instances.  So
g :: (MonadReader String m, MonadState Int m, Monad m) => m ()
is better than
g :: StateT Int (Reader String) ()
because you can change the instance of the monadic class at will.  Also you 
can change the nesting order of the monads, though maybe that's not useful in 
practice.
The disadvantage seems to be that you can't use lift to access nested monads.
Q. 8) Is it possible to get access to nested monads when using class 
constraint types?



In the following code, the test2 function is not valid because there is no 
instance for (MonadCounter (ReaderT [Char] (StateT Word IO))), which is a 
fair enough complaint.
Q. 9) What allows ReaderT and StateT to be nested in arbitrary order but not 
ReaderT and CounterT?  Especially given CounterT is actually a StateT.


class (Monad m) => MonadCounter m where
increment :: m Word
decrement :: Word -> m ()

type Counter = State Word

instance MonadCounter Counter where
increment = increment_
decrement = decrement_

runCounter :: Counter a -> a
runCounter c = evalState c 0

type CounterT m = StateT Word m

instance (Monad m) => MonadCounter (CounterT m) where
increment = increment_
decrement = decrement_

runCounterT :: (Monad m) => CounterT m a -> m a
runCounterT c = evalStateT c 0

increment_ :: (MonadState Word m) => m Word
increment_ = do
w <- get
put (w + 5)
return w

decrement_ :: (MonadState Word m) => Word -> m ()
decrement_ w = do
curW <- get
if w > curW
then put 0
else put (curW - w)
return ()

test1 :: IO ()
test1 = runReaderT (runCounterT bar) "blah"

--test2 :: IO ()
--test2 = runCounterT (runReaderT bar "blah")

bar :: (MonadReader String m, MonadCounter m, MonadIO m) => m ()
bar = do
w <- increment
s <- ask
liftIO $ putStrLn $ (show w) ++ s
return ()
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Positive integers

[Daniel McAllansmith]

Unless I've missed it, there is no typeclass for positive integers in GHC.
Is there any particular reason it doesn't exist?

Also, it seems Word would be a far better type in the likes of (!!), length, 
etc.  Is it just tradition that resulted in the use of Int?


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

Re: [Haskell-cafe] Re: Positive integers

[Daniel McAllansmith]

On Friday 24 March 2006 13:14, Aaron Denney wrote:
> On 2006-03-24, Daniel McAllansmith <[EMAIL PROTECTED]> wrote:
> > Unless I've missed it, there is no typeclass for positive integers in
> > GHC. Is there any particular reason it doesn't exist?
>
> The number of useable operations is small, and checks for leaving the
> domain would have to be done all the time.  It basically doesn't buy
> anything.

I can see the domain bounds check would be a problem in theory, but in 
practice doesn't the type enforce that?  Keeping Word positive costs nothing 
because it just overflows.  Wouldn't it be much the same?
Not that I'm really concerned about the absence, probably because of your 
other point.

>
> > Also, it seems Word would be a far better type in the likes of (!!),
> > length, etc.  Is it just tradition that resulted in the use of Int?
>
> No.  I'd like to be able to get the differences in length both positive
> and negative, for example.  (This could be fixed by making (+) and (-)
> instance of an MPTC, though, as additive torsors.)

An additive torsor is?

I'd maintain that the difference between two lengths is an entirely different 
quantity from the length of a list.  Though I'll admit the extra work 
converting to Integrals to get that quantity would be a pain, and probably 
not worth it.

I was more concerned about functions with Int as input, such as (!!), that can 
result in errors.
If practically feasible I would have preferred (!!) to take a Word rather than 
Int, even though you'd sometimes need bounds checks at fromInteger calls to 
be safe.


I suppose the 'correct' type for the index in (!!) would be
(Integral n, LowBounded n) => n
if such a low bound type class existed.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Positive integers

[Daniel McAllansmith]

On Friday 24 March 2006 14:37, you wrote:
> > An additive torsor is?
>
> Surprisingly, there is a page on MathWorld about Torsors but it is
> empty. Google turned up the following page with a good explanation.
>
> http://math.ucr.edu/home/baez/torsors.html

Nice clear explanation that.  Thanks for the link Jared.

>
> > I'd maintain that the difference between two lengths is an entirely
> > different quantity from the length of a list.
>
> (Maybe this is a good example of what the term torsor captures.)
>
> Thanks to Aaron for expanding our vocabulary.

Yep.  Now I agree with Aaron.
And now I won't get offended if someone calls me a closet torsor user! :)

>
>   Jared.
> --
> http://www.updike.org/~jared/
> reverse ")-:"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Positive integers

[Daniel McAllansmith]

On Friday 24 March 2006 16:16, Ben Rudiak-Gould wrote:
> Daniel McAllansmith wrote:
> > I can see the domain bounds check would be a problem in theory, but in
> > practice doesn't the type enforce that?  Keeping Word positive costs
> > nothing because it just overflows.  Wouldn't it be much the same?
>
> If you're planning wraparound semantics then you're better off with Int
> indexes. 

I wasn't really _planning_ wrap around semantics.
More just making the point that saying the cost of using Word is greater than 
the cost of using Int, due to the bounds checking required, seems unfair.
I see your point about quick detection of bad indices, though I'd still rather 
have the type document the fact that only positive integers are expected.

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

Re: [Haskell-cafe] Positive integers

[Daniel McAllansmith]

On Friday 24 March 2006 23:29, Malcolm Wallace wrote:
> Daniel McAllansmith <[EMAIL PROTECTED]> wrote:
> > Unless I've missed it, there is no typeclass for positive integers in
> > GHC. Is there any particular reason it doesn't exist?
> >
> > Also, it seems Word would be a far better type in the likes of (!!),
> > length,  etc.  Is it just tradition that resulted in the use of Int?
>
> There is a good argument that what you really want here is the lazy
> infinite natural numbers.  Think Peano:
>
> data Natural = Zero | Succ Natural
>
> The clear correspondance between lazy lists and the size/index of a lazy
> list makes this type fairly compelling.  It can be jolly useful,
> particularly with infinite streams, to be able to compute
> (length xs > n)
> without forcing the evaluation of the list to more than n places.
>
> Of course, if the naturals were actually represented in Peano (unary)
> form, that would be somewhat inefficient, but there are various
> strategies that can be used to make the representation smaller whilst
> retaining their nice properties.

I was thinking about several things in this thread, torsors, overflow 
semantics, bounds checking...
I wonder if there would be any merit in being able to define constrained 
subsets of integers and the semantics when/if they overflow.

For example, take UNIX nice levels -20 to 19.  You could have
  data ConstrainedInteger = CI {distToMax :: Natural, distToMin :: Natural}
this would ensure only the 40 integers can be represented.
Then you could have _something_ that defined what happened on overflow, 
whether it wraps, reflects, errors, truncates or whatever.

When it comes to compile, or source preprocessing, time these numbers could be 
realigned to a primitive Int or Word representation of suitable size and have 
the appropriate overflow code written in.  And, in the case of error or wrap 
overflow semantics on a set of the right size, the overflow checks could be 
disabled, like other assertions, at runtime.

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

Re: [Haskell-cafe] Building Monads from Monads

[Daniel McAllansmith]

On Friday 24 March 2006 16:42, Cale Gibbard wrote:

Excellent help thanks, Cale.

A lot of my misunderstandings stemmed from not finding any 'instance 
MonadState ReaderT' when reading the code in Reader.hs, not realising that 
there was an instance defined in State.hs, and yet being able to use get on 
what I thought would just be a Reader.
I think I will now have an enduring friendship with GHCi's ':info'.


>
> > Q. 4) Is it possible to give a type to the lifted function so that the
> > monad of the correct class _and_ type is used?  E.g. dig into a String
> > Reader rather than an Int Reader.
>
> I'm not completely sure what you're after here -- basically, you just
> lift things into whichever monad you're using. If you want to be
> polymorphic, but insist on a particular instance of MonadReader,
> that's easy enough, just put a constraint like (MonadReader String m)
> or something similar on your type.

Not really a valid question now that I've cleared up my misconceptions of 
lifting, but...
I meant something along the lines of
  i <- ((lift get) :: Int) --dig into the nearest Int state
  s <- ((lift get) :: String) --dig into the nearest String state

> > Q. 6) Is it safe to always use liftIO, even in plain IO monad?
>
> It's safe, sure, though a little awkward. It's easy enough to lift
> whole IO computations later on anyway. The only benefit would be if
> you wanted to later intersperse actions into the code which came from
> a transformed version.

Yeah, I meant being able to go back and intersperse the use of state, or 
whatever, in a monadic expression that had, until then, only done IO.


[snip various good suggestions and improved code]

Good advice, thanks.


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

Re: [Haskell-cafe] Building Monads from Monads

[Daniel McAllansmith]

On Friday 24 March 2006 16:49, Cale Gibbard wrote:
> Oh, and almost forgot, you can check out lots of examples of this not
> only in the mtl, but also on the (old) Haskell Wiki. I've written a
> lot of simple (sometimes trivial) examples for people to look at

I'll be sure to check them out.


> Last but not least, check out my Sudoku solver 

> (everyone has one of these nowadays).
Hey, easy does it.  I appreciate the help and all, but there's no need to 
bring up my sudoku solver inadequacies. :)


>
> hope this all helps :)

Sure does.

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

[Haskell-cafe] error vs. MonadError vs. fail

[Daniel McAllansmith]

Is there a consensus on how anticipatable failure situations should be 
handled?


There was a thread, "haskell programming guidelines", from 2006-02-25 where 
John Meacham and Cale Gibbard had a bit of back-and-forth about using 
Monad.fail or a purpose specific MonadFail class.

I believe a consensus was reached that using error should only be for 
'impossible' situations and signaling buggy code.
[Apologies if I've put words in anyones mouth.]


Using fail certainly seems quick and easy, but I find it a bit distasteful for 
a few different reasons:
 users of a library can't discriminate between a failure indicating they've 
supplied bad input and a failure indicating that teh library writer has got a 
bad pattern match somewhere,
 it doesn't seem to force the potential for failure to be explicit in the api 
of a library,
 it doesn't seem to allow distinct, and rich, failure constructs at system 
layer boundaries, or the containment of them.

Maybe the last two aren't a problem when programming in Haskell, but by itself 
the first seems pretty nasty.


Apparently the advantage of fail is that user of the library can choose to 
receive failures as eg Maybes, Eithers, [], or whatever they like.

But surely a MonadFail could allow the best of both worlds, letting the 
library throw as detailed an error construct as it can, and letting the 
library user choose MonadFail instance such that error constructs are turned 
into Maybes, Eithers, a new construct appropriate for a higher system layer, 
etc?


MonadError is not up to this task as far as I can tell.  Has anybody whipped 
up an alternative, or can explain why it can't be done?


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

[Haskell-cafe] Defining instance needs allow-undecidable-instance?

[Daniel McAllansmith]

Hi, folks.

I've got a working class and instances thereof.  I would now like to change 
the class such that error behaviour is specified by MonadError, for the 
moment throwing String errors.  When I try to add MonadError into the types I 
eventually hit the requirement for allow-undecidable-instances.  
Is there some way I can I avoid having to use this extension?


My starting point consists of:

class (Num i, Bounded i, Monad m) => MonadSource i m | m -> i where
...

newtype SourceT i m a = SourceT (StateT (Store i) m a)
deriving (Functor, Monad, MonadIO, MonadTrans)

instance (Num i, Bounded i, Monad m) => MonadSource i (SourceT i m) where
...

I changed it to:

class (Num i, Bounded i, Monad m, MonadError String m)
=> MonadSource i m | m -> i where


newtype SourceT i m a = SourceT (StateT (Store i) m a)
deriving (Functor, Monad, MonadIO, MonadTrans, MonadError e)

instance (Num i, Bounded i, Monad m, MonadError String m)
=> MonadSource i (SourceT i m) where
...



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

Re: [Haskell-cafe] Defining instance needs allow-undecidable-instance?

[Daniel McAllansmith]

On Tuesday 28 March 2006 11:12, Daniel McAllansmith wrote:
> Hi, folks.
>
> I've got a working class and instances thereof.  I would now like to change
> the class such that error behaviour is specified by MonadError, for the
> moment throwing String errors.  When I try to add MonadError into the types
> I eventually hit the requirement for allow-undecidable-instances.
> Is there some way I can I avoid having to use this extension?
>

I've received a link[1] off-list to a patch to GHC changing this behaviour, so 
it looks like in the future I'll be able to remove the 
allow-undecidable-instances flag and rely on just glasgow-exts.

> instance (Num i, Bounded i, Monad m, MonadError String m)
> => MonadSource i (SourceT i m) where
> ...

That aside, is what I have done, including a type in the context, considered 
an acceptable solution for this sort of problem?

Cheers
Daniel

[1] http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/13500
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] error vs. MonadError vs. fail

[Daniel McAllansmith]

On Tuesday 28 March 2006 07:29, Andrew Pimlott wrote:
> > MonadError is not up to this task as far as I can tell.
>
> Why not?  All that needs to be done is write the missing instances, eg
>
> instance MonadError () Maybe where
>   throwError x   = Nothing
>   Nothing `catchError` f = f ()
>   Just x `catchError` f  = Just x
>
> instance Error () where
>   noMsg  = ()
>   strMsg s   = ()
>

How would you go about writing the Maybe based analogue of ErrorT?  What do 
you give to the handler in the instance of MonadError?


newtype ErrMaybeT e m a = ErrMaybeT { runErrMaybeT :: m (Maybe a) }

instance (Monad m, Error e) => Monad (ErrMaybeT e m) where
return a = ErrMaybeT $ return (Just a)
m >>= k  = ErrMaybeT $ do
a <- runErrMaybeT m
case a of
Nothing -> return Nothing
Just r -> runErrMaybeT (k r)
fail msg = ErrMaybeT $ return Nothing

instance (Monad m, Error e) => MonadError e (ErrMaybeT e m) where
throwError l = ErrMaybeT $ return Nothing
m `catchError` h = ErrMaybeT $ do
a <- runErrMaybeT m
case a of
Nothing -> runErrMaybeT (h ???) --what to do here?
Just r -> return (Just r)

f :: (MonadError String m) => Bool -> m Int
f b = if b
then return 42
else throwError "The boolean was false."

test1 b = do
r <- runErrorT $ f b
putStrLn (show r) --Left "..." or Right 42
return ()

test2 b = do
r <- runErrMaybeT $ f b
putStrLn (show r) --Nothing or Just 42
return ()


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

Re: [Haskell-cafe] error vs. MonadError vs. fail

[Daniel McAllansmith]

On Wednesday 29 March 2006 09:49, Andrew Pimlott wrote:
> If you want to write a MonadError operation that can be used with Maybe
> or Either, it would look like
>
> f :: (MonadError e m, Error e) => Bool -> m Int
> f b = if b
> then return 42
> else throwError (strMsg "The boolean was false.")

As long as you're happy only using Strings for your error constructs.
Or you're willing to write a global construct<->String codec across all error 
constructs.  Doesn't sound very pleasant to me.

>
> But I see your point now about MonadFail (having throw but not catch)
> being perhaps preferable for this use.

My intuition is that you'd want three error related monads, Fail, Catch and 
Convert, to achieve what I'm after... don't know if that's a good intuition 
or not. :)

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

Re: [Haskell-cafe] Off-topic [was: Distributing monadic(?) functions across dyadic functions]

[Daniel McAllansmith]

On Monday 03 April 2006 08:09, David Menendez wrote:
> If you look at it in terms of folds over pairs,
>
> cata (&) (x,y) = x & y   -- corresponds to uncurry
> ana f g x = (f x, g x)   -- corresponds to (&&&)
>
> Then you can de-forest:
>
> hylo (&) f g x = f x & g x
>
> -- hylo (&) f g == cata (&) . ana f g
> --  == uncurry (&) . f &&& g
> --
> -- cata (&) == hylo (&) fst snd
> -- ana f g  == hylo (,) f g
>
> This seems remeniscent of pull-backs (or push-outs) in category theory,
> but I don't know enough to say for certain.

I especially like the above code after it has been automatically transformed 
to use the puppy operator by my email client.

Actually, the more I look at it... maybe the new crop of haskell editors 
should define some 'haskicon' replacements. :)

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

Re: [Haskell-cafe] web servers

[Daniel McAllansmith]

Following is a message I sent yesterday, sans attachment.  Looks like the code 
was too bloated to get through under the list size limit.

As I say in the original message , I'm keen for any feedback.  So let me know 
if anyone wants the actual code (20 KB, compressed) to have a look through.

Cheerio
Daniel


On Sunday 09 April 2006 06:24, Tim Newsham wrote:
> I found a copy of Simon Marlow's HWS on haskell.org's cvs 
> server.  I know there's a newer plugin version, but I cant find a working
> link to the actual code.

There's this link: http://www.mdstud.chalmers.se/~md9ms/hws-wp/
From memory I think there may have been a more recent version at 
scannedinavian.org (possibly only accessible with darcs?), but still a couple 
of years with no apparent activity.

> Besides HWS, what other web servers exist?  Does anyone actually use a
> haskell based web server in practice?  Which web server is considered the
> most mature?  stable?  fastest?
>
> I'm trying to decided if I should sink some time into HWS or if I should
> use another server.

Several months ago I had a bit of play-time available which I spent on writing 
a HTTP server in Haskell.
The goal was a HTTP 1.1 compliant server that could be embedded in a Haskell 
app, be reconfigured on the fly and have different request handlers 
added/removed.
I did have a quick look at HWS before I started but I seem to recall it was 
pretty basic (in terms of the amount of the HTTP spec. implemented).

In any event, I started from scratch.  It's certainly not finished, and it's 
the very first thing I wrote with Haskell so it's a bit of a dogs breakfast, 
but it might be of interest.
There's lots that needs doing but it should just be a case of writing a 
request handler to get it doing _something_ useful.


It's always been my intention to get back to it, clean it up a bit/lot and 
release it under a more liberal licence (currently 'all rights reserved'), 
but have had little time available.
Eventually I hope to actually use it in anger.

If anyone is interested in using it, contributing to it, or picking over it 
for use in an existing project, I'll try and find somewhere stable to host it 
and change the licence.
Feel free to ask questions on what it does/doesn't do.  You'll probably need 
to, given the documentation ;-)


Regardless of it's utility, any criticism or advice on the code would be 
appreciated.

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

Re: [Haskell-cafe] Counting bits: Sanity Check

[Daniel McAllansmith]

On Wednesday 12 April 2006 02:09, David F. Place wrote:
> If you'd like to give it a whirl on your fancy modern computers,

Averages of user time for three runs on an Athlon64 running 64bit linux:

kern0.29700
ones32  0.30733
table32 0.37333
table   0.38400

I ran a whole lot more of kern and ones32... kern was consistently faster than 
ones32.  Curious.

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

Re: [Haskell-cafe] Counting bits: Sanity Check

[Daniel McAllansmith]

On Thursday 13 April 2006 08:55, David F. Place wrote:
> On Apr 12, 2006, at 3:30 PM, Daniel McAllansmith wrote:
> > Averages of user time for three runs on an Athlon64 running 64bit
> > linux:
> >
> > kern0.29700
> > ones32  0.30733
> > table32 0.37333
> > table   0.38400
> >
> > I ran a whole lot more of kern and ones32... kern was consistently
> > faster than
> > ones32.  Curious.
>
> Yes, especially curious since the algorithm is taken from AMD's
> optimization guide for the Athlon and Opteron series.  I'm not good
> enough at reading core syntax to be able to see what GHC is doing
> with it.
>
> I wonder how this other crazy algorithm I found will work on your 64
> bit omputer.   It is much slower on my 32 bit PPC powerbook for
> obvious reasons.   If you'd like to try it, I'll include an updated
> BitTwiddle.hs .
>
> Usage:
> time ./bits 200 300 64

Averages of user time of five runs on an Athlon64 running 64bit linux:

64  0.1974
kern0.2980
ones32  0.3240
table32 0.3754
table   0.3798

64 looks to be a good bit faster.

You didn't change anything in the ones32 algorithm did you?  The other 
algorithms are taking roughly what they did last time, but ones32 seems 
consistently slower now.

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

Re: [Haskell-cafe] web servers

[Daniel McAllansmith]

On Wednesday 12 April 2006 22:52, Graham Klyne wrote:
> I'm interested, but I don't have the time to look right now (or in the next
> couple of months, as far as I can see).
>
> What would really interest me is a system that can provide the
> functionality of the Python packages I currently use (TurboGears [1], of
> which the web server/controller component is CherryPy [2]).  There's also
> some interesting recent CherryPy-related discussion about web dispatching
> that I think could translate very well to Haskell [3][4].

It's certainly nothing that grand.
It's intended scope was confined to accepting connections, decoding requests 
and handing them off to arbitrary request handlers which is where all that 
higher level stuff would come into play.

I just had a look at Network.HTTP, looks like there have been some recent 
changes to allow server-side uses.
Perhaps that could be a home for parts of it, though the two approaches seem a 
bit different.


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

[Haskell-cafe] Controlling scope using monadic classes

[Daniel McAllansmith]

Hi.

I'm trying to control the scope within which functions can be used by putting 
them in a type class.
Unfortunately I can't seem to figure out how to get it done.  Any advice would 
be much appreciated.

What I want is to start out in a certain scope, which restricts me to using 
functions in that scope or opening up a subsidiary scope at which point I'm 
restricted to functions in that scope or opening up an even deeper scope.

Hopefully a failed attempt will help explain what I'm trying to achieve... the 
following has trouble with the inScope{B,C} functions.

type AInfo = String
type BInfo = String
type CInfo = String

type BResult = Int
type CResult = Char

class (Monad m) => WithinA m where
askAInfo :: m AInfo

class (WithinA m) => WithinB m where
askBInfo :: m BInfo

class (WithinB m) => WithinC m where
askCInfo :: m CInfo

class (WithinA m) => ScopeA m where
getAInfo:: m AInfo
putAInfo:: AInfo -> m ()
updateAInfo :: BResult -> m ()
inScopeB:: (ScopeB m2) => m2 BResult -> m BResult

class (WithinB m) => ScopeB m where
getBInfo :: m BInfo
putBInfo :: BInfo -> m ()
inScopeC :: (ScopeC m2) => m2 CResult -> m CResult

class (WithinC m) => ScopeC m where
getCInfo :: m CInfo
putCInfo :: CInfo -> m ()

aScoped :: (ScopeA m) => m String
aScoped = do
bResult <- inScopeB bScoped
updateAInfo bResult
return "done"

bScoped :: (ScopeB m) => m BResult
bScoped = do
i1 <- b1
i2 <- b2
return (i1 + i2)

b1 :: (ScopeB m) => m Int
b1 = return 2

b2 :: (ScopeB m) => m Int
b2 = inScopeC cScoped >>= return . fromEnum

cScoped :: (ScopeC m) => m Char
cScoped = return '('


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

[Haskell-cafe] Re: Controlling scope using monadic classes

[Daniel McAllansmith]

On Wednesday 17 May 2006 19:55, [EMAIL PROTECTED] wrote:
> Daniel McAllansmith wrote:
> > I'm trying to control the scope within which functions can be used by
> > putting them in a type class.  Unfortunately I can't seem to figure
> > out how to get it done.  Any advice would be much appreciated.
>
> Hopefully the following is close to what you wanted. 

Excellent, looks like that'll do the trick.  Thanks, Oleg.
And I'll be sure to take a look at your monadic-regions examples.

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

Re: [Haskell-cafe] Editors for Haskell

[Daniel McAllansmith]

On Wednesday 31 May 2006 11:32, George Beshers wrote:
> Well, my thesis (many moons ago I assure you) was on syntax
> directed editors.  I came to the conclusion that letting the user
> do what they want is a requirement, but that "heuristics" and
> other "smarts" were to be avoided on the grounds that at least
> for my implementation they were more trouble than they were
> worth.  Thus I would avoid error correcting parsers unless you
> are very confident that the correction used is at least type-safe
> and that it is not "sticking things in" that are unwanted
> (or even more maddening removing what I just typed and
> which **was** what I wanted).

I certainly agree.  I've ended up loathing any editor which unilaterally 
decides to change what I've typed.  That _might_ be because they weren't done 
properly... maybe.

>
> So my recommendation is that pointing out where the syntax
> and typing errors are without having to leave the editor
> would be great.  Then the time required to actually make the
> corrections is minimal in terms of overall development time.

It might have been mentioned before but I think IntelliJ's 'Idea' does an 
excellent job as a java editor.  It'd be worth looking at for... ideas, as it 
were.
It doesn't automatically correct anything, when it detects an error it makes 
it obvious by highlighting the offending code, putting marks on the scrollbar 
and colouring an indicator.
When the cursor is on an error you can hit a key-combo to bring up a list of 
potential remedial actions.

>
> The "interesting" (graveyard laugh) problems revolve around
> editing a library and the program that uses it at the same time
> with a few obvious extensions.  The "graveyard laugh" is because
> I rapidly found I needed transactions and as the implementation
> was in C++ it had some very nasty pointer issues going to and
> from disk.  Performance was also an issue --- but that was a
> a pre-sparc  SUN, M68020 w/ 4Meg of RAM if memory serves
> me correctly.

Idea is, more or less, transactional.  It's 'refactorings' can affect multiple 
entities, and they're stored in a local history so you can rollback when you 
want to.
I'm not sure it'd run too well on that sort of machine though. :)

For what it's worth, I'd love a Haskell editor the likes of Idea (and better).  
Lots of refactory-goodness, auto-importing of functions, function suggestion 
from type, display of inferred types, etc, etc, etc

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

[Haskell-cafe] Breaking cycles in a directed graph.

[Daniel McAllansmith]

Hello.

I'm currently using Data.Graph.Inductive to represent a directed graph.  

I want to detect all cycles within the graph and 'break' them by inserting a 
minimal number of nodes that are labelled with a special cycle-breaker label.

Can anyone give me advice on a good algorithm for finding the cycles and 
finding the optimum edges to insert the cycle-breaking nodes on?


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

Re: [Haskell-cafe] Breaking cycles in a directed graph.

[Daniel McAllansmith]

On Wednesday 12 July 2006 19:19, Jens Fisseler wrote:
> R.C. Read, R.E. Tarjan. Bounds on Backtrack Algorithms for Listing
> Cycles, Paths and Spanning Trees. Networks 5: 237-252, 1975,
>
> section 8.3, "Cycles", of 
> Edward M. Reingold, Jurg Nievergelt, Narsing Deo. Combinatorial
> Algorithms: Theory and Practice. Prentice-Hall, Englewood Cliffs, 1977.
>
> You can also find a survey in
>
> Prabhaker Mateti, Narsing Deo. On Algorithms for Enumerating All
> Circuits of a Graph. SIAM Journal on Computing, 5(1): 90-99, 1976.

Hi, Jens.

You don't know if there is an overview, or implementation, of these algorithms 
online do you?  I don't have (easy) access to these references.

Another that might be applicable is:
Donald B. Johnson. Finding all the elementary circuits of a directed graph. 
SIAM J. Comput, 5:77--84, 1975.

Though I don't have access to that either.

Also I gather Combinatorica, a Mathematica module, has algorithms covering 
this sort of thing.  I understand it has a restrictive licence so I haven't 
looked at those either.

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

Re: [Haskell-cafe] Breaking cycles in a directed graph.

[Daniel McAllansmith]

On Wednesday 12 July 2006 21:11, Henning Thielemann wrote:
> On Wed, 12 Jul 2006, Daniel McAllansmith wrote:
> > Hello.
> >
> > I'm currently using Data.Graph.Inductive to represent a directed graph.
> >
> > I want to detect all cycles within the graph and 'break' them by
> > inserting a minimal number of nodes that are labelled with a special
> > cycle-breaker label.
> >
> > Can anyone give me advice on a good algorithm for finding the cycles and
> > finding the optimum edges to insert the cycle-breaking nodes on?
>
> There must be an algorithm for finding the minimal spanning tree or
> forest. The edges that do not belong to the tree should be the labelled as
> cycle-breakers.

I don't think that will give me the solution I'm looking for.

I'll try to rephrase my problem, I think it was a little unclear.


Given a directed graph I want to find the minimal set of edges such that 
deletion of those edges from the graph will result in a new graph with 0 
strongly connected components, ie no cycles, possibly disconnected.
Perhaps the correct term is the minimal _full_ disconnecting set of edges?


Once I've got that set of edges, instead of deleting them, I'll insert one of 
my special 'cycle-breaking' nodes, but that's nothing to do with the core 
graph analysis really.

Examples:

{(A->A)} => {(A->A)}
{(A->B), (B->C)} => {}
{(A->B), (B->C), (B->D), (C->A), (D->A)} => {(A->B)} because it is the least 
number of edges, other solutions would require deleting 2 edges.


A possible solution might be to recursively break the graph into strongly 
connected components, delete an edge from the component then break again 
until there are no more sub components.

That'll probably have pretty poor performance.
It could be made to provide a stable solution easily though which, as Jason 
Dagit points out, is useful for QuickChecking a more complex algorithm.


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

[Haskell-cafe] 'Compiling' expression graph into Arrows

[Daniel McAllansmith]

Hello,

I have a graph of function applications which I would like to 'compile' into 
an Arrow, specifically the SF Arrow from Yampa.

I'd appreciate any advice on how I might go about this.


The graphs, of which there will be many, will be constructed at runtime and 
will be executed for extended periods of time so execution time will dominate 
compilation time.
The graphs might also need to be passed around and executed 'elsewhere', 
where 'elsewhere' will almost certainly be the same GHC version but maybe on 
different architectures.


The hand-written 'compilation' in the attached file gives a rough idea of 
what I start with and what I need to end up with.


I could just automate the hand-written process by generating the SFs and 
arrow-syntax blocks, write them into a file then call GHC... seems a bit 
cowboyish.

Or, write the graph into a template file that has Template Haskell to generate 
the SFs and arrow-syntax blocks then call GHC... almost as cowboyish?

Or, fold the graph up using loop and arr... probably the simplest, once I get 
rid of my sugar dependency and figure out how to use loop that is ;).

Or, maybe I can actually get the expression graph into a GHC api 
representation somehow and let it work marvels of optimisation on the 
expression before turning it into an arrow.


Any idea on the relative merits of these, or other ideas?

Can GHC optimise arrow code much during compilation, or will code folded up at 
runtime using loop/arr be just as efficient?

Could GHC condense the functions of multiple graph nodes into a single 
function for conversion to an SF arrow?

Will the necessity of introducing delays rule out using GHC to simplify the 
raw expression?



Thanks
Daniel
{-# OPTIONS -farrows #-}

module ArrowTest where

import Data.Graph.Inductive
--AFRP stuff is from Yampa
import AFRP
import AFRPUtilities

type Delayed = Bool

data MyNode f = MyNode String (Func f)

data Func f
= Input
| Func f Delayed

rawNodes = [
(1, MyNode "A" Input),
(2, MyNode "B" Input),
(3, MyNode "C" (Func min True)),
(4, MyNode "D" (Func (-) False)),
(5, MyNode "E" (Func (+) True)),
(6, MyNode "F" (Func max False))
]

rawEdges = [
(1,3,"e1"),
(1,5,"e2"),
(2,4,"e3"),
(3,4,"e4"),
(4,3,"e5"),
(4,6,"e6"),
(5,6,"e7"),
(6,5,"e8")
]

rawGraph :: Gr (MyNode (Int -> Int -> Int)) String
rawGraph = mkGraph rawNodes rawEdges


compiledGraph = proc (a,b) -> do
d <- scc1 -< (a,b)
f <- scc2 -< (a,d)
returnA -< f

scc1 = proc (a,b) -> do
rec
c <- sfC -< (a,d)
d <- sfD -< (b,c)
returnA -< d

scc2 = proc (a,d) -> do
rec
e <- sfE -< (a,f)
f <- sfF -< (d,e)
returnA -< f

-- The graphs may be cyclic so delays are introduced such that the resulting
-- function is not infinitely recursive.

-- fby ('followed by'), which comes from Yampa, is used to introduce the delay

sfC = 0 `fby` mkArrow min
sfD = arr mkArrow (-)
sfE = 0 `fby` mkArrow (+)
sfF = arr mkArrow max

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

[Haskell-cafe] Deriving class instances using DrIFT

[Daniel McAllansmith]

Hi.

I'm trying to derive some instances using DrIFT, but it will only work for me 
when I'm deriving for types in the current file or in the prelude.

For example,

this works:

>module Test where
>
>{-! for Maybe derive : Haskell2Xml !-}


this works:

>module Test where
>
>data Foo = Foo
>
>{-! for Foo derive : Haskell2Xml !-}


but this doesn't:

>module Test where
>
>import Data.Word
>
>{-! for Word32 derive : Haskell2Xml !-}

It fails to load the first import, giving an error as follows:

{- Generated by DrIFT (Automatic class derivations for Haskell) -}
{-# LINE 1 "Test.hs" #-}
DrIFT: can't find module Data.Word

Any ideas as to why that is?


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

Re: [Haskell-cafe] Deriving class instances using DrIFT

[Daniel McAllansmith]

On Monday 30 October 2006 22:18, Einar Karttunen wrote:
> On 29.10 19:56, John Meacham wrote:
> > Since DrIFT can only understand haskell source code, it can't derive
> > instances for anything you don't have the original source to. 

Ahhh, ok.

> > such as 
> > things in the pre-compiled libraries that come with ghc. you will likely
> > have to write out those instances by hand.

Hmmm, seems strange that it can successfully derive for the Data.Maybe type 
but not the Data.Word32 type.  I didn't think it would have access to any 
original source from my ghc install, there only seems to be hi files.

> >
> > Another possibility is that you could replicate just the data
> > declarations by hand, and use DrIFT -r to just spit out the derivations
> > and put those in a file on their own.
>
> How about using Template Haskell for getting the definition and then
> giving that to DrIFT?


Thanks for the suggestions.
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Accumulating related XML nodes using HXT

[Daniel McAllansmith]

Hello.

I have some html from which I want to extract records.  
Each record is represented within a number of  nodes, and all records  
nodes are contained by the same parent node.

The things I've tried so far end up giving me the cartesian product of record 
fields, so for the html fragment included below I'd end up with:

[ Prod "Television" 17 "/prod17" "A very nice telly."
, Prod "Television" 17 "/prod17" "Mind your fillings."
, Prod "Cyclotron" 24 "/prod24" "A very nice telly."
, Prod "Cyclotron" 24 "/prod24" "Mind your fillings."
]

instead of:

[ Prod "Television" 17 "/prod17" "A very nice telly."
, Prod "Cyclotron" 24 "/prod24" "Mind your fillings."
]


How should I go about accumulating related  nodes into individual records?


Thanks
Daniel


HTML fragment follows:

...

  
Product:
Television (code: 17)
  
  
Description:
A very nice telly.
  

  

  

  
Product:
Cyclotron (code: 24)
  
  
Description:
Mind your fillings.
  

  

  

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

Re: [Haskell-cafe] Accumulating related XML nodes using HXT

[Daniel McAllansmith]

Apologies if this is a duplicate, the original appears to have gone astray.

On Wednesday 01 November 2006 10:57, Albert Lai wrote:
> Daniel McAllansmith <[EMAIL PROTECTED]> writes:
> > Hello.
> >
> > I have some html from which I want to extract records.
> > Each record is represented within a number of  nodes, and all records
> >  nodes are contained by the same parent node.
>
> This is very poorly written HTML.  The original structure of the data
> is destroyed - the parse tree no longer reflects the data structure.
> (If a record is to be displayed in several rows, there are proper
> ways.)  It is syntactically incorrect: nested , and color in .
> (Just ask http://validator.w3.org/ .)  

Indeed.  The original is even worse, with overlapping nodes and other such 
treasures which makes navigation in HXT tricky at times.

> I trust that you are parsing 
> this because you realize it is all wrong and you want to
> programmatically convert it to proper markup.

Yep!  I sure wouldn't be doing this if I had control of the the original HTML.

>
> Since the file is unstructured, I choose not to sweat over restoring
> the structure in an HXT arrow.  The HXT arrow will return a flat list,
> just as the file is a flat ensemble.

I was about to write a follow-up just as your mail came in... I've ended up 
with the same solution as you've kindly suggested.

Another option I came across is Control.Arrow.ArrowTree.changeChildren which 
could be used to restore a more normalised structure ready for more 
processing.


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

Re: [Haskell-cafe] Accumulating related XML nodes using HXT

[Daniel McAllansmith]

On Wednesday 01 November 2006 10:57, Albert Lai wrote:
> Daniel McAllansmith <[EMAIL PROTECTED]> writes:
> > Hello.
> >
> > I have some html from which I want to extract records.
> > Each record is represented within a number of  nodes, and all records
> >  nodes are contained by the same parent node.
>
> This is very poorly written HTML.  The original structure of the data
> is destroyed - the parse tree no longer reflects the data structure.
> (If a record is to be displayed in several rows, there are proper
> ways.)  It is syntactically incorrect: nested , and color in .
> (Just ask http://validator.w3.org/ .)  

Indeed.  The original is even worse, with overlapping nodes and other such 
treasures which makes navigation in HXT tricky at times.

> I trust that you are parsing 
> this because you realize it is all wrong and you want to
> programmatically convert it to proper markup.

Yep!  I sure wouldn't be doing this if I had control of the the original HTML.

>
> Since the file is unstructured, I choose not to sweat over restoring
> the structure in an HXT arrow.  The HXT arrow will return a flat list,
> just as the file is a flat ensemble.

I was about to write a follow-up just as your mail came in... I've ended up 
with the same solution as you've kindly suggested.

Another option I came across is Control.Arrow.ArrowTree.changeChildren which 
could be used to restore a more normalised structure ready for more 
processing.


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

Re: [Haskell-cafe] Re: Permutation with k levels

[Daniel McAllansmith]

On Wednesday 08 November 2006 05:41, DavidA wrote:
> To get the result you want, take the list of (letter, probability) pairs,
> and generate the Cartesian product of k copies of itself.
>
> cartProd 0 xs = [[]]
> cartProd k xs = [x:ys | x <- xs, ys <- cartProd (k-1) xs]
>
> The result is all sequences of k (letter,probability) pairs, allowing
> repetitions.
>
> Then you just need to unzip and multiply:
>
> (\lps -> let (ls,ps) = unzip lps in (concat ls, product ps))
>

It does the basically the same thing but, you might also want to check out the 
Probabilistic Functional Programming library by Martin Erwig at 
http://web.engr.oregonstate.edu/~erwig/pfp/
It's got all sorts of other probability goodies in it.

By importing the Probability module you can define your distribution and a 
permute as so

probDist = mkD [("A", 0.8), ("B", 0.2)]

permute 0 d = mkD []
permute 1 d = d
permute k d = mapD (uncurry (++)) (prod d (permute (k - 1) d))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Permutation with k levels

[Daniel McAllansmith]

On Wednesday 08 November 2006 08:23, Daniel McAllansmith wrote:

Ahhh, whoops.  It seems that lack of compilation errors is not a universal 
sign that a haskell program is correct.

> permute 0 d = mkD []

mkD doesn't allow distributions with 0 sum probabilities, so you'd need to 
restrict the range of k
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GHCi 6.6 tab-completion of source file paths not working.

[Daniel McAllansmith]

Hi.

I've just installed GHC 6.6 on an amd64 running a gentoo linux distribution.

With GHCi from 6.4.2 I could run "ghci" then do

Prelude> :l Foo/Bar.hs

by hitting tab after Foo to complete the path to Bar.hs

This no longer works, hitting tab only shows what's in the pwd.


If I run "ghci Foo/Bar.hs" then I can :r fine and I can do a :l Foo.Bar using 
tab-completion to complete the module name.
Tab completion of in-scope functions looks to be working fine.

Has anybody else experienced this problem?

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

Re: [Haskell-cafe] Re: Debugging partial functions by the rules

[Daniel McAllansmith]

On Saturday 18 November 2006 00:37, Neil Mitchell wrote:
> Hi
>
> > > How controversial would a proposal to {-# DEPRECATE fromJust #-} be, in
> > > favour of:
> > >
> > > Just _ = x  -- which will give you the precise line number
> > >
> > > It seems to me this is one cause of mysterious newbie errors we
> > > could easily discourage, with little harm.
> >
> > Btw, I'm not seriously suggesting removing it ;)
> > It could be discouraged ever so slightly in the haddocks though.
>
> I strongly disagree. If we are removing things that confuse newbies
> why not start with higher rank types, MPTC's and GADT's ;)
>
> fromJust is simple, useful and clear. What you mean is that
> implementations aren't very good at debugging this. It seems unfair to
> blame partial functions for the lack of a debugger. If a call stack
> was automatically output every time a fromJust failed would this even
> be something people complained about?

Well, I strongly disagree. :)

I suspect I would be classified as a newbie relative to most posters on this 
list but here's my thoughts anyway...

I chose to learn haskell largely because I thought the static type safety 
would help eliminate bugs, I've never once been happy when I've needed to 
fire up a debugger or add trace statements and I hoped they would become 
things of the past.

One of my initial responses to haskell was disappointment upon seeing head, 
fromJust and the like.  'Those look nasty', I sez to meself.
From day one I've tried to avoid using them.  Very occasionally I do use them 
in the heat of the moment, but it makes me feel unclean and I end up having 
to take my keyboard into the bathroom for a good scrubbing with the sandsoap.

The disappointment has pretty much changed to frustration since reading Oleg, 
and others, type-hackery work.  I realise the problems are just poor/limited 
usage of haskell, not inherent in the language.  Unfortunately I can 
understand the 'right' solutions but still have trouble formulating them 
myself.  I'm hoping that if I hang out in the type-hackery 'hot zone' long 
enough I'll start emitting enough picoOlegs myself to solve simple 
problems. ;)

My view is that if I can reason about my program and know a static property I 
want to be able to stamp this into the types and have my reasoning validated 
during compilation.  
But existing library code with weak typesafety is a large inertial mass, when 
trying to do something 'right' the interfacing is a daunting prospect.

In general I'd rather have effort go into promoting 'right' solutions, and 
making those solutions easier to express, than going into debuggers 
for 'wrong' solutions.



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