Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Peter Gammie
Ben,

On 29/04/2010, at 6:16 AM, Ben wrote:

> [...]
> 
> newtype STAuto s a b = STAuto { unSTAuto : (a, s) -> (b, s) }

As Felipe observes in detail, this can be made to work. He uses Read and Show 
for serialisation, but clearly you can use whatever you like instead.

I just wanted to add that one can go to town with the approach: after you 
understand Felipe's stuff, take a look at Caspi and Pouzet's coalgebraic 
streams stuff. (I'd recommend looking at both the tech report and the published 
paper, and there is some Haskell code too.)

BTW I was referring (off-list) to the original Arrows paper by John Hughes.

cheers
peter

-- 
http://peteg.org/

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


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Felipe Lessa
On Wed, Apr 28, 2010 at 04:16:08PM -0700, Ben wrote:
> so i tried state machines of a sort
>
> newtype STAuto s a b = STAuto { unSTAuto : (a, s) -> (b, s) }
>
> where the interruptibility would come from being able to save out the
> state s.  i was not successful, unfortunately, in this level of
> generality.  the fully-polymorphic state doesn't work, because one
> needs to be able to compose arrows, which means composing state, so
> like Hughes (see below) one needs some way of nesting states inside
> one another.  also, to implement delay in ArrowCircuit, one needs to
> be able to store in the state s something of type a.  this is a
> dependency i was not able to model right.

You may try encapsulating the state within an existential:

  {-# LANGUAGE GADTs #-}

  import Prelude hiding ((.), id)
  import Control.Category
  import Control.Arrow

  data SFAuto a b where
  SFAuto :: (Read s, Show s) => s -> ((a, s) -> (b, s)) -> SFAuto a b

  instance Category SFAuto where
  id = SFAuto () id
  (SFAuto s f) . (SFAuto r g) = SFAuto (s, r) h
  where h (x, (s, r)) = let (gx,  r') = g (x,  r)
(fgx, s') = f (gx, s)
in (fgx, (s', r'))

  instance Arrow SFAuto where
  arr f = SFAuto () (\(x, _) -> (f x, ()))

  first (SFAuto s f) = SFAuto s f'
  where
f' ((x, y), s1) = let (fx, s2) = f (x, s1)
  in ((fx, y), s2)

  instance ArrowChoice SFAuto where
  left (SFAuto s f) = SFAuto s f'
  where
f' (Right x, s1) = (Right x, s1)
f' (Left x,  s1) = first Left $ f (x, s1)

  instance ArrowLoop SFAuto where
  loop (SFAuto s f) = SFAuto s f'
  where
f' (b, s1) = let ((c, d), s2) = f ((b, d), s1)
 in (c, s2)

Now, if you want to serialize an (SFAuto a b), you may if you
know where the original arrow is.  I mean, if you have

  something :: SFAuto a b
  something = ...

and you want to apply it to a huge list, you may

  A1) 'applyN k', where k is adjustable.

  A2) Save the results so far, the remaining input and the
  current state (which is Showable and Readable in my
  example, but could be an instance of Binary, for example).

  A3) Go to A1.

If anything bad happens, to recover:

  B1) Read results, input, and last state.

  B2) 'changeState something stateThatWasRead'

  B3) Go to A1.

Helper functions mentioned above:

  applyN :: Int -> SFAuto a b -> [a] -> ([b], (SFAuto a b, [a]))
  applyN 0 sf   xs = ([], (sf, xs))
  applyN _ sf   [] = ([], (sf, []))
  applyN n (SFAuto s f) (x:xs) =
  let (fx, s') = f (x,s)
  in first (fx :) $ applyN (n-1) (SFAuto s' f) xs

  changeState :: SFAuto a b -> String -> SFAuto a b
  changeState (SFAuto _ f) str = SFAuto (read str) f

I don't have any idea if this is what you're looking for, but I
hope it helps :).

Cheers,

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Duncan Coutts
On Wed, 2010-04-28 at 09:55 -0700, Rogan Creswick wrote:
> On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts
>  wrote:
> >
> > Yes, it means the testing agent (cabal-install or some other
> > program/system) can do more than simply run all the tests. It means it
> > can enumerate them and not run them (think a GUI or web interface), run
> > a subset of tests, run them in parallel etc.
> >
> 
> I'm not convinced that this should be cabal's responsibility.

"Cabal" should define the interface between testsuite and test runner.
Nothing more.

Packages should provide collections of tests.

Testing agents should provide a test runner to actually run the tests
and do something with the results.

See for example test-framework which has exactly this decomposition
between testsuites (a collection of tests) and a test runner. They are
mediated by a common interface. The test-framework package provides both
the interface, some adapters for QC/HUnit to provide tests, and also a
sample test runner that prints results to the console.

Tools like cabal-install that use the interface defined by Cabal can
provide a test runner (almost certainly implemented in some other
package) and then do something interesting with the results like showing
them to the user or uploading them to hackage.

Other tools can use other test runners and do other interesting things.

> I think we would be better served by leaving this up to the test
> frameworks (indeed, test-framework has test filtering capabilities
> already).  If 'cabal test' simply acts as a thin layer between the
> user/invoking system and the test framework, then we could pass
> arguments through to the underlying test binary and perform these
> tasks using whatever interface that test binary provides.  This will
> buy us more flexibility in the long run.  (I think this is at least a
> good place to start -- and matches my interpretation of Thomas's
> proposal.)
> 
> If Cabal takes on these responsibilities, then the testing api will be
> more constrained -- we won't be able to experiment with new test
> formats/methodologies as easily, since any tests will have to meet a
> specific API.

It is exactly defining this API that should allow flexibility. It means
packages can provide tests and have them be used in multiple different
ways by different test runners with different purposes and capabilities.

If all you can do is run the testsuite and collect the results, that's
much more constrained.

Note that we're also proposing a lowest-common-denominator testsuite
interface that gives all the control to the package author, but means
the test runner cannot interpret the results in any interesting way. The
main point is to wrap any existing testsuite in a way that allows it to
be run automatically and non-iteractively for e.g. hackage testing.

Duncan

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


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Ben
thanks for the comments, i'll try to respond to them all.  but to
start off with, let me mention that my ultimate goal is to have a way
of writing down causal and robust (restartable) computations which
happen on infinite streams of data "in a nice way" -- by which i mean
the declarative / whole-meal style ala Bird.  loosely, these are
functions [a] -> [b] on infinite lists; the causal constraint just
means that the output at time (index) t only depends on the inputs for
times (indices) <= t.

the catch is the robust bit.  by robust, i mean i need to be able to
suspend the computation, and restart it where it left off (the data
might be only sporadically or unreliably available, the computation
needs to be able to survive machine reboots.)  unfortunately the
obvious way (to me) of writing down such suspendible computations is
to use explicit state-machines, e.g. to reify function computation as
data, and save that.  this is unfortunately very piece-meal and
imperative.

so i tried to turn state-machine computations on streams into an
arrow.  as an exercise for myself i tried to implement instances of
ArrowChoice, ArrowLoop, and ArrowCircuit for other various versions of
"stream arrows."  i was successful with automatons / mealy machines

newtype Auto a b = Auto { unAuto : a -> (b, Auto a b) }

functions on infinite lists (Data.Stream)

newtype InfSF a b = ISF { unISF : Stream a -> Stream b }

and length-preserving functions on finite lists

newtype SF a b = SF { unSF : [a] -> [b] }

this was promising, if elementary (these are all well-known.)  but
none of these are particularly interruptible, at least in GHC -- i
can't save a mealy machine, and the list versions are not particularly
causal.  so i tried state machines of a sort

newtype STAuto s a b = STAuto { unSTAuto : (a, s) -> (b, s) }

where the interruptibility would come from being able to save out the
state s.  i was not successful, unfortunately, in this level of
generality.  the fully-polymorphic state doesn't work, because one
needs to be able to compose arrows, which means composing state, so
like Hughes (see below) one needs some way of nesting states inside
one another.  also, to implement delay in ArrowCircuit, one needs to
be able to store in the state s something of type a.  this is a
dependency i was not able to model right.

perhaps i have entirely the wrong approach -- if anyone can think of a
way of writing such a robust program in a declarative style, i would
love to know it!  of interest are the coalgebraic / comonadic
approaches, and the CCA stuff of liu et al.

Peter G : i have looked at the original CGI Arrow, it's a nice paper.
i don't think i understand all the subtleties, but my impression is
that he has a less polymorphic state type, and i don't know if he
addressed ArrowCircuit.  also he was unable to get it to work,
entirely, at least in that paper -- there were some type issues iirc.

Chris H : in my state-machine setup, saving the "state" of pure
functions is not exactly necessary -- as stream arrows, pure functions
lift to stateless gadgets, e.g. lift = map.  on the other hand, if i
was able to save functions / closures, or whole state of the program,
it would certainly suffice (i could use mealy machines or the
continuation monad), but is probably more than i need.

Peter V, Chris E : the CGI Arrow paper that Peter G mentioned may be
of interest to you.

the rest of you haskellers -- sorry, this is like the tenth time i've
posed this question, in one form or another!  i keep on feeling like
i've made a little progress, but then

Best, Ben

On Wed, Apr 28, 2010 at 11:49 AM, Chris Eidhof  wrote:
> I agree. This would be an extremely useful feature, not only for game 
> development, but also for web development. We often use continuations as a 
> way to add state to the web, but this fails for two reasons: whenever the 
> server restarts, or when we scale to multiple machines.
>
> However, I think it is not easy to do this: traversing the heap should be 
> relatively simple, however: what if a function implementation changes?
>
> An interesting approach is taken by the Clean guys: they use dynamics, which 
> can store a function, a type representation and the heap to disk. See also 
> this old thread: 
> http://www.mail-archive.com/haskell-cafe@haskell.org/msg34054.html
>
> -chris
>
> On 28 apr 2010, at 19:50, Peter Verswyvelen wrote:
>
>> Interesting topic. I find it a bit annoying that Haskell doesn't
>> provide support to save functions. I understand this is problematic,
>> but it would be very nice if the Haskell runtime provided a way to
>> serialize (part of) the heap, making sure that pointers to compiled
>> functions get resolved correctly.
>>
>>
>>
>> On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson
>>  wrote:
>>>
>>> On Wed, 28 Apr 2010, Ben wrote:
>>>
 I want to save the state of the system to disk, I want to be able to
 play the game, pick a point to stop, freeze it and turn off the
 comp

Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Christopher Lane Hinson


I think y'all are talking past each other, a little bit.  There are two ways to 
serialize a function:

1) Serialize the bytecode for the function.
2) Serialize a persistant reference to a function that resides inside the 
executable.

Personally, I think that either strategy is dubious.  If you really need this, 
I would recommend building a DSL to support your specific needs.  When I was 
working in Java I trusted the default serializer about as far as I could 
physically throw it, and IIRC my associates at the time had the same instinct.

Functions in general can contain references to any data, including objects such 
as MVar's who's behavior is actually determined by unreachable entities.

There's no amount of type system magic that can hold off monsters like _|_ or 
things like lazy bytestrings that are finite but never intended to be fully 
resident in memory.  Or do we intend to serialize unevaluated thunks?

Friendly,
--Lane




On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson
 wrote:


On Wed, 28 Apr 2010, Ben wrote:


I want to save the state of the system to disk, I want to be able to
play the game, pick a point to stop, freeze it and turn off the
computer, and then come back later and resume.  Why is that unwise?
What are the alternatives?

B


On Tue, 27 Apr 2010, Ben wrote:


slightly off topic, but how does one handle pausing / saving /
restarting in the FRP framework, especially the arrowized version?


If we're about Arrow FRP, remember that the arrow typeclass includes a
function, 'arr', that admits any function as a parameter, and these are in
general impossible to serialize to disk. Since Arrow FRP ends up roughly in
a form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually the
state of the system.  There are a few tactics that would get us around this
limitation, but they are rather severe.   You could render 'arr' useless in
several ways, or you could save all the input to a system and replay it.

But I would argue that even if you wanted to do this, "saving an FRP system"
is, to me, like "saving a system in the IO monad," (which, there are tactics
that would let you do this, too).  It's probablematic in part because the
FRP system probably has active hooks into the user interface, such as
windows and other widgits that it owns, and possibly other devices (such as
physical rocket engines).  Even if the FRP system is completely pure and can
be referenced by a single pointer, it is easily and rightfully aware of
specific details of the hardware it is embedded in.

So it seems to me that what we actually want, to do complex simulations with
persistance, is not an FRP system that interacts with the outside world, but
a "self-contained, self-interacting, differential equation hairball."  Such
a system would be very cool, but I think that the numerical algorithms
needed exceed what an FRP system should try to provide.

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





On Wed, 28 Apr 2010, Peter Verswyvelen wrote:


As a side note, it's interesting that C# doesn't allow serialization
of closures (anonymous delegates). The compiler-generated name
assigned to an anonymous delegate can be different after each
re-compilation. This is also really annoying in C#/.NET, since one
must explicitly add a named method if serialization is needed. So I
wander how Clean solves this. I mean, consider


data MyData = MD (Int->Int)

myFunc x = x+1
myState1 = MyData myFunc
myState2 = MyData (\x -> x+1)

I can imagine that serializing myState1 is not too difficult, since it
should be possible to lookup the name of the compiled function
"myFunc".

However, what about serializing myState2? The lambda function has no
name, and it is not obvious to me how to give it a name that is unique
enough to survive a couple of iterations of source code modifications.





On Wed, Apr 28, 2010 at 9:56 PM, Gregory Crosswhite
 wrote:


On Apr 28, 2010, at 3:41 PM, Limestra?l wrote:


I think the problem with function serialization is that unlike languages which 
run over a virtual machine, bytecode generated by GHC is platform-specific 
(just as compilated C or C++) and therefore can run directly on top of the 
system, which is far faster but less portable.


Is this true?  I thought that ghc has separate machine code and byte-code 
modes, and inferred that the latter was platform-independent.  Is the latter 
platform-specific because it is just a different way of organizing different 
ways of (unlinked) machine code, or because parts of the byte-code depend on 
things like the size of integers in the compilation machine that are 
platform-dependent?

Also, it is worth noting that Clean supports serialization of values including 
closures.  It's not entirely clear to me how they do this, but looks like some 
combination of seeing whether a referenced routine is already in the curre

Re: [Haskell-cafe] ANN: CPSA - Cryptographic Protocol Shapes Analyzer

2010-04-28 Thread John D. Ramsdell
>> We are working towards a version of CPSA with the property that
>> whenever it successfully terminates, every possible execution is
>> described by its output.  However, the current implementation
>> occasionally fails to find some executions.
>
> That is concerning - is it due to ...

We have formally specified the algorithm, but we haven't been able to
prove the algorithm finds all solutions.  In fact, we now have an
example in the test suite that shows it misses an answer.  The example
is in the source distribution in tst/missing-contraction.scm.  There
should be two answers, but CPSA only finds one.  We have a fix you can
try out in 2.0.4.  In src/CPSA/Lib/Strand.hs, you can change the flag
useDisplacement from False to True, and CPSA will find both answers.
We don't know if this fix is all one needs to ensure CPSA finds every
answer.

By the way, the algorithm is in doc/cpsaspec.pdf, which can be build
from a source distribution of CPSA.

> What is the current status of development both wrt openness and future 
> direction?

Our highest priority is to resolve the correctness issue you just
raised.  As for openness, the sources are available to you.  We
haven't thought about other forms of openness.

> I'm wondering if you plan to add MQV or other non-trivial primitives.

I don't know what MQV is, so I can't say.

Thanks for your interest, Thomas.

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


Re: [Haskell-cafe] Lazy Parsing (ANN: vcd-0.1.4)

2010-04-28 Thread Jason Dusek
2010/04/28 S. Doaitse Swierstra :
> On 27 apr 2010, at 22:12, Jason Dusek wrote:
> > So UU parsers can construct input?
>
> The perform an editing action on the input so it becomes a
> sentence of the language recognised.

  My questions betray a fundamental misunderstanding on my part;
  reading the above, its clear the parser is constructing
  strings that match the language, not values that are of the
  type.

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


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Peter Verswyvelen
As a side note, it's interesting that C# doesn't allow serialization
of closures (anonymous delegates). The compiler-generated name
assigned to an anonymous delegate can be different after each
re-compilation. This is also really annoying in C#/.NET, since one
must explicitly add a named method if serialization is needed. So I
wander how Clean solves this. I mean, consider


data MyData = MD (Int->Int)

myFunc x = x+1
myState1 = MyData myFunc
myState2 = MyData (\x -> x+1)

I can imagine that serializing myState1 is not too difficult, since it
should be possible to lookup the name of the compiled function
"myFunc".

However, what about serializing myState2? The lambda function has no
name, and it is not obvious to me how to give it a name that is unique
enough to survive a couple of iterations of source code modifications.





On Wed, Apr 28, 2010 at 9:56 PM, Gregory Crosswhite
 wrote:
>
> On Apr 28, 2010, at 3:41 PM, Limestraël wrote:
>
>> I think the problem with function serialization is that unlike languages 
>> which run over a virtual machine, bytecode generated by GHC is 
>> platform-specific (just as compilated C or C++) and therefore can run 
>> directly on top of the system, which is far faster but less portable.
>
> Is this true?  I thought that ghc has separate machine code and byte-code 
> modes, and inferred that the latter was platform-independent.  Is the latter 
> platform-specific because it is just a different way of organizing different 
> ways of (unlinked) machine code, or because parts of the byte-code depend on 
> things like the size of integers in the compilation machine that are 
> platform-dependent?
>
> Also, it is worth noting that Clean supports serialization of values 
> including closures.  It's not entirely clear to me how they do this, but 
> looks like some combination of seeing whether a referenced routine is already 
> in the current executable, then seeing whether it is in a nearby library, and 
> then finally just-in-type compiling the serialized platform-independent 
> bytecode into native code.
>
> Cheers,
> Greg
>
> ___
> 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] Re: Control.Exception try and catch

2010-04-28 Thread Simon Marlow

On 28/04/10 14:45, Mads Lindstrøm wrote:

Hi

From
http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Exception.html#3

"... The difference between using try and catch for recovery is that in
catch the handler is inside an implicit block (see "Asynchronous
Exceptions") which is important when catching asynchronous
exceptions ..."

However, 'try' is implemented by calling catch
http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/src/Control-Exception-Base.html#try:

try :: Exception e =>  IO a ->  IO (Either e a)
try a = catch (a>>= \ v ->  return (Right v)) (\e ->  return (Left e))

Thus, I wonder, why do 'try' not "inherit" the implicit block mentioned above?


There's nothing magic going on - the "handler" in the case of try is 
just (return . Left), and that does indeed get executed with an implicit 
block.



Looking at catch:

catch   :: Exception e
 =>  IO a -- ^ The computation to run
 ->  (e ->  IO a)  -- ^ Handler to invoke if an exception is raised
 ->  IO a
catch io h = H'98.catch  io  (h . fromJust . fromException . toException)


I see no call to 'block'. But maybe it is hidden in H'98.catch? And is 
H'98.catch == Prelude.catch ?


The block is implicit (it's built into the implementation of catch, in 
fact).


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


[Haskell-cafe] Re: Benchmarks game updated to ghc 6.12.2

2010-04-28 Thread Simon Marlow

On 28/04/10 21:05, Don Stewart wrote:

The benchmarks game has been updated to use 6.12.2

Please dive in and help tweak/improve/spot any regressions.
Esp. with respect to multicore flags/options/...


chameneos is using -N5, which is probably killing it.

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


[Haskell-cafe] Benchmarks game updated to ghc 6.12.2

2010-04-28 Thread Don Stewart
The benchmarks game has been updated to use 6.12.2

Please dive in and help tweak/improve/spot any regressions.
Esp. with respect to multicore flags/options/...


- Forwarded message from Isaac Gouy -

Subject: fyi benchmarks game updated to ghc 6.12.2

http://shootout.alioth.debian.org/u64q/haskell.php

best wishes, Isaac

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Richard G.
I like this.  One area that would be helpful is the ability to run the 
tests when different compile flags are used.  E.g., the HUnit tests have 
different behaviors when compiled with and without optimization; it 
would be very handy if I could automate the testing of both cases.


I don't believe that testing of multiple compile flags should be done 
inside Cabal.  Instead, the arguments that are passed to `cabal 
configure' should also be used to build the test programs.  This would 
allow a simple script, or a more complex build system, to handle the 
testing of both cases.


Richard

On 10-04-28 9:19 AM, Duncan Coutts wrote:

I have previously advocated a library interface as a detailed
testsuite interface (in addition to a lowest common denominator
interface of stdio+exitcode). That is a test stanza in a package
.cabal file would specify a module containing an entry point of the
right type (like main but using a more interesting type).

That way, cabal or any other tool could run the testsuite and produce
results in whatever format it likes.


I appreciate the elegance of this method, but it seems to me that it
requires dynamic loading, which is currently in a sorry state.


Actually it doesn't require dynamic loading. It just requires compiling
a stub program that imports the user's library and some test-runner
code. Cabal is good at doing that kind of thing already (eg Setup.hs
scripts).


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


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Gregory Crosswhite

On Apr 28, 2010, at 3:41 PM, Limestraël wrote:

> I think the problem with function serialization is that unlike languages 
> which run over a virtual machine, bytecode generated by GHC is 
> platform-specific (just as compilated C or C++) and therefore can run 
> directly on top of the system, which is far faster but less portable.

Is this true?  I thought that ghc has separate machine code and byte-code 
modes, and inferred that the latter was platform-independent.  Is the latter 
platform-specific because it is just a different way of organizing different 
ways of (unlinked) machine code, or because parts of the byte-code depend on 
things like the size of integers in the compilation machine that are 
platform-dependent?

Also, it is worth noting that Clean supports serialization of values including 
closures.  It's not entirely clear to me how they do this, but looks like some 
combination of seeing whether a referenced routine is already in the current 
executable, then seeing whether it is in a nearby library, and then finally 
just-in-type compiling the serialized platform-independent bytecode into native 
code.

Cheers,
Greg

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


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Limestraël
I think the problem with function serialization is that unlike languages
which run over a virtual machine, bytecode generated by GHC is
platform-specific (just as compilated C or C++) and therefore can run
directly on top of the system, which is far faster but less portable.

It wouldn't make much sense if, when sending functions through network, the
receiver had to have the exact same system as the sender.

Back to FRP, now. I was wondering, Ben, which FRP framework you were using.
I'm trying to get into the whole FRP stuff, but I don't know which one is
better/simpler when you have almost no knowledge about the field.


2010/4/28 Chris Eidhof 

> I agree. This would be an extremely useful feature, not only for game
> development, but also for web development. We often use continuations as a
> way to add state to the web, but this fails for two reasons: whenever the
> server restarts, or when we scale to multiple machines.
>
> However, I think it is not easy to do this: traversing the heap should be
> relatively simple, however: what if a function implementation changes?
>
> An interesting approach is taken by the Clean guys: they use dynamics,
> which can store a function, a type representation and the heap to disk. See
> also this old thread:
> http://www.mail-archive.com/haskell-cafe@haskell.org/msg34054.html
>
> -chris
>
> On 28 apr 2010, at 19:50, Peter Verswyvelen wrote:
>
> > Interesting topic. I find it a bit annoying that Haskell doesn't
> > provide support to save functions. I understand this is problematic,
> > but it would be very nice if the Haskell runtime provided a way to
> > serialize (part of) the heap, making sure that pointers to compiled
> > functions get resolved correctly.
> >
> >
> >
> > On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson
> >  wrote:
> >>
> >> On Wed, 28 Apr 2010, Ben wrote:
> >>
> >>> I want to save the state of the system to disk, I want to be able to
> >>> play the game, pick a point to stop, freeze it and turn off the
> >>> computer, and then come back later and resume.  Why is that unwise?
> >>> What are the alternatives?
> >>>
> >>> B
> >>>
>  On Tue, 27 Apr 2010, Ben wrote:
> 
> > slightly off topic, but how does one handle pausing / saving /
> > restarting in the FRP framework, especially the arrowized version?
> >>
> >> If we're about Arrow FRP, remember that the arrow typeclass includes a
> >> function, 'arr', that admits any function as a parameter, and these are
> in
> >> general impossible to serialize to disk. Since Arrow FRP ends up roughly
> in
> >> a form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually
> the
> >> state of the system.  There are a few tactics that would get us around
> this
> >> limitation, but they are rather severe.   You could render 'arr' useless
> in
> >> several ways, or you could save all the input to a system and replay it.
> >>
> >> But I would argue that even if you wanted to do this, "saving an FRP
> system"
> >> is, to me, like "saving a system in the IO monad," (which, there are
> tactics
> >> that would let you do this, too).  It's probablematic in part because
> the
> >> FRP system probably has active hooks into the user interface, such as
> >> windows and other widgits that it owns, and possibly other devices (such
> as
> >> physical rocket engines).  Even if the FRP system is completely pure and
> can
> >> be referenced by a single pointer, it is easily and rightfully aware of
> >> specific details of the hardware it is embedded in.
> >>
> >> So it seems to me that what we actually want, to do complex simulations
> with
> >> persistance, is not an FRP system that interacts with the outside world,
> but
> >> a "self-contained, self-interacting, differential equation hairball."
>  Such
> >> a system would be very cool, but I think that the numerical algorithms
> >> needed exceed what an FRP system should try to provide.
> >>
> >> Friendly,
> >> --Lane
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Broken ghc documentation links

2010-04-28 Thread Neil Mitchell
Hi,

I have recently updated Hoogle so it points at specific documentation.
If anyone finds any further bugs, please let me know.

I'm hoping to go through Hoogle and revise much of it in the near
future, and intend to put things in place to stop this happening again
(and keep it up to date).

Thanks, Neil

On Mon, Apr 26, 2010 at 2:15 PM, Ivan Lazar Miljenovic
 wrote:
> Daniel Fischer  writes:
>
>> Am Montag 26 April 2010 13:36:22 schrieb Ivan Lazar Miljenovic:
>>> So, the problem is that there are broken links _in Hoogle_;
>>
>> No, hoogle just sends you to
>> http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelude.html#t%3AIO
>> , which does exist. It's the 'Source' link in the haddocks that sends you
>> to the 404 Not Found.
>> It's the same with my local docs, I think it's haddock that got confused by
>> the move of the IO definition from base to ghc-prim.
>
> Yeah, as I've said I mis-read the initial problem (I've fielded a few
> queries recently regarding Hoogle not pointing to the 6.12.2 docs and
> initially thought this was another one).
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Chris Eidhof
I agree. This would be an extremely useful feature, not only for game 
development, but also for web development. We often use continuations as a way 
to add state to the web, but this fails for two reasons: whenever the server 
restarts, or when we scale to multiple machines.

However, I think it is not easy to do this: traversing the heap should be 
relatively simple, however: what if a function implementation changes?

An interesting approach is taken by the Clean guys: they use dynamics, which 
can store a function, a type representation and the heap to disk. See also this 
old thread: http://www.mail-archive.com/haskell-cafe@haskell.org/msg34054.html

-chris

On 28 apr 2010, at 19:50, Peter Verswyvelen wrote:

> Interesting topic. I find it a bit annoying that Haskell doesn't
> provide support to save functions. I understand this is problematic,
> but it would be very nice if the Haskell runtime provided a way to
> serialize (part of) the heap, making sure that pointers to compiled
> functions get resolved correctly.
> 
> 
> 
> On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson
>  wrote:
>> 
>> On Wed, 28 Apr 2010, Ben wrote:
>> 
>>> I want to save the state of the system to disk, I want to be able to
>>> play the game, pick a point to stop, freeze it and turn off the
>>> computer, and then come back later and resume.  Why is that unwise?
>>> What are the alternatives?
>>> 
>>> B
>>> 
 On Tue, 27 Apr 2010, Ben wrote:
 
> slightly off topic, but how does one handle pausing / saving /
> restarting in the FRP framework, especially the arrowized version?
>> 
>> If we're about Arrow FRP, remember that the arrow typeclass includes a
>> function, 'arr', that admits any function as a parameter, and these are in
>> general impossible to serialize to disk. Since Arrow FRP ends up roughly in
>> a form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually the
>> state of the system.  There are a few tactics that would get us around this
>> limitation, but they are rather severe.   You could render 'arr' useless in
>> several ways, or you could save all the input to a system and replay it.
>> 
>> But I would argue that even if you wanted to do this, "saving an FRP system"
>> is, to me, like "saving a system in the IO monad," (which, there are tactics
>> that would let you do this, too).  It's probablematic in part because the
>> FRP system probably has active hooks into the user interface, such as
>> windows and other widgits that it owns, and possibly other devices (such as
>> physical rocket engines).  Even if the FRP system is completely pure and can
>> be referenced by a single pointer, it is easily and rightfully aware of
>> specific details of the hardware it is embedded in.
>> 
>> So it seems to me that what we actually want, to do complex simulations with
>> persistance, is not an FRP system that interacts with the outside world, but
>> a "self-contained, self-interacting, differential equation hairball."  Such
>> a system would be very cool, but I think that the numerical algorithms
>> needed exceed what an FRP system should try to provide.
>> 
>> Friendly,
>> --Lane
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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


Re: [Haskell-cafe] Problem about pattern matching.

2010-04-28 Thread Henning Thielemann
minh thu schrieb:
> 2010/4/28 Magicloud Magiclouds :
>> Hi, I have code as below. How come "case" version works wrong and
>> gives me "overlap" compiling warning? Thanks.
>>  if dayOfMonth == firstDayOfMonth
>>then v day (x, y)
>>else if dayOfMonth == lastDayOfMonth
>>  then not_ $ v day (x, y)
>>  else Mider day (x, y)
>>
>>  case dayOfMonth of
>>firstDayOfMonth -> v day (x, y)
>>lastDay -> not_ $ v day (x, y)
>>_ -> Mider day (x, y)
> 
> Hi,
> 
> firstDayIfMonth and lastDay are new variables, not previously bound
> variable. This means that trying to pattern match (the value of)
> dayOfMonth will always succeed with the first alternative.

You can however simulate a 'case' with predefined variables:
   http://haskell.org/haskellwiki/Case
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Peter Verswyvelen
Interesting topic. I find it a bit annoying that Haskell doesn't
provide support to save functions. I understand this is problematic,
but it would be very nice if the Haskell runtime provided a way to
serialize (part of) the heap, making sure that pointers to compiled
functions get resolved correctly.



On Wed, Apr 28, 2010 at 6:42 PM, Christopher Lane Hinson
 wrote:
>
> On Wed, 28 Apr 2010, Ben wrote:
>
>> I want to save the state of the system to disk, I want to be able to
>> play the game, pick a point to stop, freeze it and turn off the
>> computer, and then come back later and resume.  Why is that unwise?
>> What are the alternatives?
>>
>> B
>>
>>> On Tue, 27 Apr 2010, Ben wrote:
>>>
 slightly off topic, but how does one handle pausing / saving /
 restarting in the FRP framework, especially the arrowized version?
>
> If we're about Arrow FRP, remember that the arrow typeclass includes a
> function, 'arr', that admits any function as a parameter, and these are in
> general impossible to serialize to disk. Since Arrow FRP ends up roughly in
> a form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually the
> state of the system.  There are a few tactics that would get us around this
> limitation, but they are rather severe.   You could render 'arr' useless in
> several ways, or you could save all the input to a system and replay it.
>
> But I would argue that even if you wanted to do this, "saving an FRP system"
> is, to me, like "saving a system in the IO monad," (which, there are tactics
> that would let you do this, too).  It's probablematic in part because the
> FRP system probably has active hooks into the user interface, such as
> windows and other widgits that it owns, and possibly other devices (such as
> physical rocket engines).  Even if the FRP system is completely pure and can
> be referenced by a single pointer, it is easily and rightfully aware of
> specific details of the hardware it is embedded in.
>
> So it seems to me that what we actually want, to do complex simulations with
> persistance, is not an FRP system that interacts with the outside world, but
> a "self-contained, self-interacting, differential equation hairball."  Such
> a system would be very cool, but I think that the numerical algorithms
> needed exceed what an FRP system should try to provide.
>
> Friendly,
> --Lane
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Thomas Tuegel
On Wed, Apr 28, 2010 at 12:55 PM, Rogan Creswick  wrote:
> On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts
>  wrote:
>>
>> Yes, it means the testing agent (cabal-install or some other
>> program/system) can do more than simply run all the tests. It means it
>> can enumerate them and not run them (think a GUI or web interface), run
>> a subset of tests, run them in parallel etc.
>>
>
> I'm not convinced that this should be cabal's responsibility.
>
> I think we would be better served by leaving this up to the test
> frameworks (indeed, test-framework has test filtering capabilities
> already).  If 'cabal test' simply acts as a thin layer between the
> user/invoking system and the test framework, then we could pass
> arguments through to the underlying test binary and perform these
> tasks using whatever interface that test binary provides.  This will
> buy us more flexibility in the long run.  (I think this is at least a
> good place to start -- and matches my interpretation of Thomas's
> proposal.)

That is more or less how I intended my proposal to be read, the caveat
being that I intentionally said very little about the detailed test
suite interface.  I agree that we should leave much up to the testing
frameworks.

If we start implementing facilities in Cabal to pick and choose
specific tests from inside test suites, we're essentially writing yet
another test framework into Cabal; I've been specifically discouraged
from doing that since I began discussing this proposal on the list.  I
am increasingly of the opinion that we should just provide a simple,
stdout/exit code interface and let test frameworks handle the rest:

If developers want continuous integration with existing testing tools,
the can use a framework that supports the output format those tools
use, and pipe that output to stdout to be captured by Cabal.  Then
they can turn whichever tool they want loose on the output file.

If developers want to independently run subsets of their tests, they
can give them independent test stanzas in the .cabal file.  Either
they put the tests in different executables, or the test framework can
provide command-line options for turning tests on and off.

Those are the big two usage scenarios we've discussed for the detailed
test interface, and I think these examples demonstrate why I think it
may be unnecessary.

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Gregory Crosswhite
If the goal is continuous integration, perhaps it would be sufficient to 
require "cabal test" to return an error code of 0 if all tests succeed, and 
something else if any of them fail;  it can additionally print whatever output 
it wants in either case.  The continuous integration system would then run 
"cabal test" after the build, and if it succeeded (error code 0) say nothing, 
and if it failed (error code something else) it would report that the build 
failed and show the output from "cabal test" to give details to the developer.

Cheers,
Greg

On Apr 28, 2010, at 12:55 PM, Rogan Creswick wrote:

> On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts
>  wrote:
>> 
>> Yes, it means the testing agent (cabal-install or some other
>> program/system) can do more than simply run all the tests. It means it
>> can enumerate them and not run them (think a GUI or web interface), run
>> a subset of tests, run them in parallel etc.
>> 
> 
> I'm not convinced that this should be cabal's responsibility.
> 
> I think we would be better served by leaving this up to the test
> frameworks (indeed, test-framework has test filtering capabilities
> already).  If 'cabal test' simply acts as a thin layer between the
> user/invoking system and the test framework, then we could pass
> arguments through to the underlying test binary and perform these
> tasks using whatever interface that test binary provides.  This will
> buy us more flexibility in the long run.  (I think this is at least a
> good place to start -- and matches my interpretation of Thomas's
> proposal.)
> 
> If Cabal takes on these responsibilities, then the testing api will be
> more constrained -- we won't be able to experiment with new test
> formats/methodologies as easily, since any tests will have to meet a
> specific API.
> 
> While I agree that we need standardization, I think that we should
> achieve that by using compatible output formats and compatible (user)
> interfaces (and enforcing those with tests, schema checkers, etc..).
> I don't see many benefits to baking this functionality into cabal when
> it could be done separately.
> 
> --Rogan
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Henning Thielemann
Richard G. schrieb:
> I think that formatted plain-text output would be much better than XML,
> something that is human-readable and relatively easy to parse via
> machine.  Something similar to the GHC error output would work well
> because developers are familiar with it.
> 
> Test :
> 
> 
> 
> E.g.,
> 
> Test 1:Passed
> src/Some/File.hs:23
> 
> Test 2:Failed
> src/Some/File.hs:27
> Expecting `4'; received `5'.
> 
> Test 3:Error
> src/Some/OtherFile.hs:39

This is the format Emacs parses and lets you jump right to the according
file and position.

> Unexpected exception.
> 
> This would keep the complexity low in Cabal and allow for easy
> transformation to XML.

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Rogan Creswick
On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts
 wrote:
>
> Yes, it means the testing agent (cabal-install or some other
> program/system) can do more than simply run all the tests. It means it
> can enumerate them and not run them (think a GUI or web interface), run
> a subset of tests, run them in parallel etc.
>

I'm not convinced that this should be cabal's responsibility.

I think we would be better served by leaving this up to the test
frameworks (indeed, test-framework has test filtering capabilities
already).  If 'cabal test' simply acts as a thin layer between the
user/invoking system and the test framework, then we could pass
arguments through to the underlying test binary and perform these
tasks using whatever interface that test binary provides.  This will
buy us more flexibility in the long run.  (I think this is at least a
good place to start -- and matches my interpretation of Thomas's
proposal.)

If Cabal takes on these responsibilities, then the testing api will be
more constrained -- we won't be able to experiment with new test
formats/methodologies as easily, since any tests will have to meet a
specific API.

While I agree that we need standardization, I think that we should
achieve that by using compatible output formats and compatible (user)
interfaces (and enforcing those with tests, schema checkers, etc..).
I don't see many benefits to baking this functionality into cabal when
it could be done separately.

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


[Haskell-cafe] Re: Installing ghc in an OpenSolaris Zone

2010-04-28 Thread Günther Schmidt

Hello Christin,


http://www.haskell.org/ghc/download_ghc_6_10_4.html#x86solaris
is supposed to work under open solaris, too.


it does actually, quite nicely too, in the *global* zone.

It's just when I try to install it into a separate zone the install fails.

Have you managed to install it into a zone yourself?

Best regards

Günther


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


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Christopher Lane Hinson


On Wed, 28 Apr 2010, Ben wrote:


I want to save the state of the system to disk, I want to be able to
play the game, pick a point to stop, freeze it and turn off the
computer, and then come back later and resume.  Why is that unwise?
What are the alternatives?

B


On Tue, 27 Apr 2010, Ben wrote:


slightly off topic, but how does one handle pausing / saving /
restarting in the FRP framework, especially the arrowized version?


If we're about Arrow FRP, remember that the arrow typeclass includes a 
function, 'arr', that admits any function as a parameter, and these are in 
general impossible to serialize to disk. Since Arrow FRP ends up roughly in a 
form of: FRP a b c = a b (c, FRP a b c), an Arrow instance is actually the 
state of the system.  There are a few tactics that would get us around this 
limitation, but they are rather severe.   You could render 'arr' useless in 
several ways, or you could save all the input to a system and replay it.

But I would argue that even if you wanted to do this, "saving an FRP system" is, to me, 
like "saving a system in the IO monad," (which, there are tactics that would let you do 
this, too).  It's probablematic in part because the FRP system probably has active hooks into the 
user interface, such as windows and other widgits that it owns, and possibly other devices (such as 
physical rocket engines).  Even if the FRP system is completely pure and can be referenced by a 
single pointer, it is easily and rightfully aware of specific details of the hardware it is 
embedded in.

So it seems to me that what we actually want, to do complex simulations with persistance, 
is not an FRP system that interacts with the outside world, but a "self-contained, 
self-interacting, differential equation hairball."  Such a system would be very 
cool, but I think that the numerical algorithms needed exceed what an FRP system should 
try to provide.

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Rogan Creswick
On Wed, Apr 28, 2010 at 1:24 AM, Richard G.  wrote:
> I think that formatted plain-text output would be much better than XML,
> something that is human-readable and relatively easy to parse via machine.
>  Something similar to the GHC error output would work well because
> developers are familiar with it.

I don't think we need to be limited to a single output format.  It's a
simple thing to have continuous integration (or cabal) invoke tests
with a flag/option to output in a specific format.  XML is useful
because there are a number of mature tools that already expect xml --
we don't need to reinvent the wheel to get some of the capabilities
that  developers in other languages are enjoying if our tools use some
of the same formats (despite the issues that may exist with those
formats..).

I like your suggestion for an emacs/dev-readable format, and it can
coexist with xml and other "snazzier" outputs (such as the default
format for test-framework, which uses many little tricks to draw and
erase progress bars / etc.)

--Rogan

>
> Test :
>    
>    
>
> E.g.,
>
> Test 1:Passed
>    src/Some/File.hs:23
>
> Test 2:Failed
>    src/Some/File.hs:27
>    Expecting `4'; received `5'.
>
> Test 3:Error
>    src/Some/OtherFile.hs:39
>    Unexpected exception.
>
> This would keep the complexity low in Cabal and allow for easy
> transformation to XML.
>
> Richard G.
>
> On 10-04-08 8:30 PM, Rogan Creswick wrote:
>>
>> On Thu, Apr 8, 2010 at 5:53 AM, Duncan Coutts
>>   wrote:
>>>
>>> I think it's important to be able to convert into standard or custom
>>> formats. I've no idea if JUnit XML would make sense as the native
>>> format. It's plausible.
>>>
>>
>> I hadn't really thought about cabal, itself, being a consumer for test
>> results -- but I like your (Duncan's) points about defining a testing
>> interface, and keeping it extensible.
>>
>> For the record: I don't think junit xml is a good choice for a native
>> format :), but I do think it's a good format to start with simply
>> because there are many tools that can consume it already.
>>
>> --Rogan
>>
>>
>>> Duncan
>>>
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Duncan Coutts
On Wed, 2010-04-28 at 10:42 -0400, Thomas Tuegel wrote:
> On Wed, Apr 28, 2010 at 4:54 AM, Duncan Coutts
>  wrote:
> > On 28 April 2010 09:24, Richard G.  wrote:
> >> I think that formatted plain-text output would be much better than XML,
> >> something that is human-readable and relatively easy to parse via machine.
> >>  Something similar to the GHC error output would work well because
> >> developers are familiar with it.
> >
> > I have previously advocated a library interface as a detailed
> > testsuite interface (in addition to a lowest common denominator
> > interface of stdio+exitcode). That is a test stanza in a package
> > .cabal file would specify a module containing an entry point of the
> > right type (like main but using a more interesting type).
> >
> > That way, cabal or any other tool could run the testsuite and produce
> > results in whatever format it likes.
> 
> I appreciate the elegance of this method, but it seems to me that it
> requires dynamic loading, which is currently in a sorry state.

Actually it doesn't require dynamic loading. It just requires compiling
a stub program that imports the user's library and some test-runner
code. Cabal is good at doing that kind of thing already (eg Setup.hs
scripts).

> One way or another, cabal will need to provide a data structure it expects
> test suites to use for results.  Is there a substantial advantage to a
> library interface, versus providing Read/Show instances for the test
> result data structure?

Yes, it means the testing agent (cabal-install or some other
program/system) can do more than simply run all the tests. It means it
can enumerate them and not run them (think a GUI or web interface), run
a subset of tests, run them in parallel etc.

Duncan

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


Re: [Haskell-cafe] Seeking the correct quote

2010-04-28 Thread Jacques Carette

Bradford Larsen wrote:

I don't have the book handy (it was from the library), but I seem to
remember reading something along those lines in ``Datatype-Generic
Programming:  International Spring School, SSDGP 2006, Nottingham, UK,
April 24-27, 2006, Revised Lectures'', edited by Backhouse, Gibbons,
Hinze, and Jeuring.
  

The spirit is there in quotes like

"The term ‘generic programming’ means different things to different people,
because they have different ideas about how to achieve the common goal 
of combining

flexibility and safety. To some people, it means parametric polymorphism;
to others, it means libraries of algorithms and data structures; to 
another group,
it means reflection and meta-programming; to us, it means polytypism, 
that is,

type-safe parametrization by a datatype "

and

"Moreover, a parametrization is usually only called ‘generic’ 
programming if it
is of a ‘non-traditional’ kind; by definition, traditional kinds of 
parametrization

give rise only to traditional programming, not generic programming.
Therefore, ‘genericity’ is in the eye of the beholder, with beholders 
from different

programming traditions having different interpretations of the term."

But nothing 'snappy'. Ah well.

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Thomas Tuegel
On Wed, Apr 28, 2010 at 4:54 AM, Duncan Coutts
 wrote:
> On 28 April 2010 09:24, Richard G.  wrote:
>> I think that formatted plain-text output would be much better than XML,
>> something that is human-readable and relatively easy to parse via machine.
>>  Something similar to the GHC error output would work well because
>> developers are familiar with it.
>
> I have previously advocated a library interface as a detailed
> testsuite interface (in addition to a lowest common denominator
> interface of stdio+exitcode). That is a test stanza in a package
> .cabal file would specify a module containing an entry point of the
> right type (like main but using a more interesting type).
>
> That way, cabal or any other tool could run the testsuite and produce
> results in whatever format it likes.

I appreciate the elegance of this method, but it seems to me that it
requires dynamic loading, which is currently in a sorry state.  One
way or another, cabal will need to provide a data structure it expects
test suites to use for results.  Is there a substantial advantage to a
library interface, versus providing Read/Show instances for the test
result data structure?

> As you suggest in your other post, it would make sense to adapt
> test-framework to implement the interface specified by Cabal.

I agree, as well; this is essentially the approach I took in my proposal.

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


Re: [Haskell-cafe] Re: FRP for game programming / artifical life simulation

2010-04-28 Thread Ben
I want to save the state of the system to disk, I want to be able to
play the game, pick a point to stop, freeze it and turn off the
computer, and then come back later and resume.  Why is that unwise?
What are the alternatives?

B

On Tue, Apr 27, 2010 at 9:28 PM, Christopher Lane Hinson
 wrote:
>
> I'm not sure exactly what you want to do.  It should certainly be easy to
> "freeze" an FRP program by lying about the amount of time that is passing
> and witholding all events.  Do you want to save an FRP system instance to
> disk (generally unwise), or something else (what?).
>
> Friendly,
> --Lane
>
> On Tue, 27 Apr 2010, Ben wrote:
>
>> slightly off topic, but how does one handle pausing / saving /
>> restarting in the FRP framework, especially the arrowized version?
>> i've only been able to do this via explicit (or monadic)
>> state-passing, e.g. imperative / piecemeal versus declarative /
>> wholemeal, which seems against the spirit of FRP.
>>
>> b
>> ___
>> 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] Control.Exception try and catch

2010-04-28 Thread Mads Lindstrøm
Hi

From
http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Exception.html#3

"... The difference between using try and catch for recovery is that in
catch the handler is inside an implicit block (see "Asynchronous
Exceptions") which is important when catching asynchronous
exceptions ..."

However, 'try' is implemented by calling catch
http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/src/Control-Exception-Base.html#try:

try :: Exception e => IO a -> IO (Either e a)
try a = catch (a >>= \ v -> return (Right v)) (\e -> return (Left e))

Thus, I wonder, why do 'try' not "inherit" the implicit block mentioned above?

Looking at catch:

catch   :: Exception e
=> IO a -- ^ The computation to run
-> (e -> IO a)  -- ^ Handler to invoke if an exception is raised
-> IO a
catch io h = H'98.catch  io  (h . fromJust . fromException . toException)


I see no call to 'block'. But maybe it is hidden in H'98.catch? And is 
H'98.catch == Prelude.catch ?

/Mads




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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Thomas Tuegel
On Wed, Apr 28, 2010 at 4:30 AM, Richard G.  wrote:
> I think that, rather than having Cabal try to combine the results of
> different frameworks, Cabal should specify interfaces that frameworks need
> to conform to.
>
> E.g., rather than integrating test-framework into Cabal so that HUnit works
> with it, modify HUnit so it emits the format that Cabal wants. And modify
> test-framework to emit the format that Cabal wants so, if someone can't
> convert their test suite to the CabalTest format, test-framework can act as
> an intermediary and handle the conversion of output.

I think this is what we've ultimately decided to do, although we have
yet to decide exactly what format Cabal should expect test results to
be in.

I realize that it's a little difficult to follow this discussion,
since the proposal was in a state of flux.  I think you can read my
proposal at the GSoC site, but the proposal submission form kinda
mangled my formatting.  There is a public Google Documents version of
my proposal at

https://docs.google.com/Doc?docid=0AZzNFnSY9FOeZGd6MnQ4cWNfM2Q2N2J0OWZn&hl=en

which should be up-to-date and contain all the information you need.

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


Re: [Haskell-cafe] Is XHT a good tool for parsing web pages?

2010-04-28 Thread Uwe Schmidt
Hi Ivan,

> Uwe Schmidt  writes:
> > The HTML parser in HXT is based on tagsoup. It's a lazy parser
> > (it does not use parsec) and it tries to parse everything as HTML.
> > But garbage in, garbage out, there is no approach to repair illegal HTML
> > as e.g. the Tidy parsers do. The parser uses tagsoup as a scanner.
>
> So what is parsec used for in HXT then?

for the XML parser. This XML parser also deals with DTDs. This parser only 
accepts well formed XML, everything else gives an error (not just a warning 
like HTML parser). tagsoup and the HTML parser do not deal with DTDs,
so they can't be used for a full (validating) XML parser.

Regards,

   Uwe

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


Re: [Haskell-cafe] What do _you_ want to see in FGL?

2010-04-28 Thread Ivan Lazar Miljenovic
Henning Thielemann  writes:

> Ivan Miljenovic schrieb:
>
>> So you don't want the labels to be part of the actual datatype?  And
>> for users to then have to deal with any labels they want themselves?
>
> No, you would continue to provide labelled and unlabelled graphs, where
> unlabelled graphs (or just Graphs) are the base type and labelled graphs are
>
> data LabelledGraph node edge =
>LabelledGraph Graph (Map Node node) (Map (Node,Node) edge)
>
> This is a matter of separation of concerns. Sure, it means that you need
> to split the graph algorithms into their parts: each algorithm into an
> unlabelled and a labelled part. If there are algorithms that make no
> sense on labelled graphs, then you need only the first part.

I'm hesitant to do such a thing for the simple reason that it will
involve duplicate work...

It might be possible, by having two classes that do the same thing (Foo
and FooLabelled), but I'm not sure how well this would scale.

>> If so, I don't think this is feasible; some of the nice parts of FGL
>> IMHO are how it deals with labels (admittedly, I've had to write and
>> use my own "((Int,a) -> a') -> g a b -> g a' b" function because it
>> doesn't have one...).  Removing this would be a step backwards.
>> 
>> How exactly is it bad/a pain to have to deal with specifying "g ()
>> ()", especially since there are some pre-defined "unlabelled" graph
>> type and function aliases?
>
> For problems that do not need labels, why shall I cope with them?

Ummm... I fail to see how having labels would make FGL harder to use
just because you have to do "gr () ()" rather than just "gr" in your
types.

> I expect that you quickly run into the need for type extensions,

I was planning on using associated types to state what the node type
was.

> if you define a graph type class that have only unlabelled graphs as
> instance.  For instance:
>
>> instance SpecialGraph (gr () ()) where
>
> is not Haskell 98, instead
>
>> instance (IsUnit a) => SpecialGraph (gr a a) where
>>
>> class IsUnit a where toUnit :: a -> ()
>> instance IsUnit () where toUnit = id
>
> would be Haskell 98, but is certainly more complicated.

Not sure what you're doing here...

But isn't that what newtypes are for?

> This may also answer your question, how hard you should try to stay
> Haskell 98. My experience is, that with a proper design of a library you
> can reduce the need for type extensions. This makes your code more
> portable and easier to understand.

I don't plan on going overboard, but I am not going to go out of my way
to avoid extensions (sane ones; there are no plans on using
IncoherentInstances or something like that!).

Yes, it means that it won't compile on a non-GHC Haskell implementation;
but how many people actually use any other compiler full time?  My
understanding was that the other Haskell compilers still being worked on
(JHC and UHC) didn't fully implement Haskell98 either.

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


Re: [Haskell-cafe] What do _you_ want to see in FGL?

2010-04-28 Thread Henning Thielemann
Ivan Miljenovic schrieb:

> So you don't want the labels to be part of the actual datatype?  And
> for users to then have to deal with any labels they want themselves?

No, you would continue to provide labelled and unlabelled graphs, where
unlabelled graphs (or just Graphs) are the base type and labelled graphs are

data LabelledGraph node edge =
   LabelledGraph Graph (Map Node node) (Map (Node,Node) edge)

This is a matter of separation of concerns. Sure, it means that you need
to split the graph algorithms into their parts: each algorithm into an
unlabelled and a labelled part. If there are algorithms that make no
sense on labelled graphs, then you need only the first part.

> If so, I don't think this is feasible; some of the nice parts of FGL
> IMHO are how it deals with labels (admittedly, I've had to write and
> use my own "((Int,a) -> a') -> g a b -> g a' b" function because it
> doesn't have one...).  Removing this would be a step backwards.
> 
> How exactly is it bad/a pain to have to deal with specifying "g ()
> ()", especially since there are some pre-defined "unlabelled" graph
> type and function aliases?

For problems that do not need labels, why shall I cope with them?
I expect that you quickly run into the need for type extensions, if you
define a graph type class that have only unlabelled graphs as instance.
For instance:

> instance SpecialGraph (gr () ()) where

is not Haskell 98, instead

> instance (IsUnit a) => SpecialGraph (gr a a) where
>
> class IsUnit a where toUnit :: a -> ()
> instance IsUnit () where toUnit = id

would be Haskell 98, but is certainly more complicated.

This may also answer your question, how hard you should try to stay
Haskell 98. My experience is, that with a proper design of a library you
can reduce the need for type extensions. This makes your code more
portable and easier to understand.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Haskell Weekly News?

2010-04-28 Thread minh thu
2010/4/28 Ivan Lazar Miljenovic :
> minh thu  writes:
>
>> 2010/4/28 Ivan Lazar Miljenovic :
>>> Joe Fredette  writes:
 That said, if any of you have time machines/time dilation devices in
 the works, I'm happy to beta test.
>>>
>>> Don't be silly, you don't need more time, you need more _you_
>>> (i.e. clones); after all, nothing ever goes wrong with clones! :p
>>
>> Don't want to dismiss your comment but about clones and time machines,
>> the only good source of information is their creators, Kelvin and
>> Hobbes.
>
> You mean Calvin?

Damn, of course.

> Anyway, the transmogrifier was _much_ better!

Cardboards and abstractions ... seems like programming :)

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


Re: [Haskell-cafe] Haskell Weekly News?

2010-04-28 Thread Ivan Lazar Miljenovic
minh thu  writes:

> 2010/4/28 Ivan Lazar Miljenovic :
>> Joe Fredette  writes:
>>> That said, if any of you have time machines/time dilation devices in
>>> the works, I'm happy to beta test.
>>
>> Don't be silly, you don't need more time, you need more _you_
>> (i.e. clones); after all, nothing ever goes wrong with clones! :p
>
> Don't want to dismiss your comment but about clones and time machines,
> the only good source of information is their creators, Kelvin and
> Hobbes.

You mean Calvin?

Anyway, the transmogrifier was _much_ better!

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


Re: [Haskell-cafe] Haskell Weekly News?

2010-04-28 Thread minh thu
2010/4/28 Ivan Lazar Miljenovic :
> Joe Fredette  writes:
>> That said, if any of you have time machines/time dilation devices in
>> the works, I'm happy to beta test.
>
> Don't be silly, you don't need more time, you need more _you_
> (i.e. clones); after all, nothing ever goes wrong with clones! :p

Don't want to dismiss your comment but about clones and time machines,
the only good source of information is their creators, Kelvin and
Hobbes.

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


Re: [Haskell-cafe] Haskell Weekly News?

2010-04-28 Thread Ivan Lazar Miljenovic
Joe Fredette  writes:
> That said, if any of you have time machines/time dilation devices in
> the works, I'm happy to beta test.

Don't be silly, you don't need more time, you need more _you_
(i.e. clones); after all, nothing ever goes wrong with clones! :p

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


Re: [Haskell-cafe] Is XHT a good tool for parsing web pages?

2010-04-28 Thread Ivan Lazar Miljenovic
Uwe Schmidt  writes:
> The HTML parser in HXT is based on tagsoup. It's a lazy parser
> (it does not use parsec) and it tries to parse everything as HTML.
> But garbage in, garbage out, there is no approach to repair illegal HTML
> as e.g. the Tidy parsers do. The parser uses tagsoup as a scanner.

So what is parsec used for in HXT then?

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


Re: [Haskell-cafe] Getting used and available memory

2010-04-28 Thread Mads Lindstrøm
Hi

On Tue, 2010-04-27 at 14:55 -0700, Don Stewart wrote:
> We could bind to Rts.c in the GHC runtime, and get all the stats
> programmatically that you can get with +RTS -s

That would be nice.


/Mads

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


Re: [Haskell-cafe] happstack/SOAP

2010-04-28 Thread Mads Lindstrøm
Hi

I do not have an example for you, but I do have some text conversion
functions you may find useful. I have attached the text conversion
functions in a file.

/Mads

On Mon, 2010-04-26 at 09:46 +, Johannes Waldmann wrote:
> Hi - I'm looking for an example/demo happstack server 
> that handles SOAP requests. - Thanks, J.W.
> 
> 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
{-# OPTIONS -Wall -XOverloadedStrings #-}
module TextConversion
( soapXmlUtf8, soapXmlToString
, soapContentType
, E.DecodingException
, E.EncodingException
)
where

import qualified Data.ByteString.Lazy as BS
import qualified Data.ByteString.Lazy.Char8 as BsC8

import qualified Data.Encoding as E
import qualified Data.Encoding.UTF8 as E

import Text.Regex
import Text.Parsec
import Text.Parsec.ByteString.Lazy

-- soapXmlUtf8, soapXmlToString, bsToUtf8, bsToString, StringToUtf8Bs may throw DecodingException
-- or EncodingException

-- |Converts a SOAP request to UTF8. If the request contains a XML header,
-- the text encoding is set to UTF8.
soapXmlUtf8 :: String-- ^The content type as seen in the HTTP header
-> BS.ByteString
-> BS.ByteString
soapXmlUtf8 contentType = bsToUtf8 (encoding contentType) . setUtf8EncodingInXmlHeader

-- |Converts a SOAP request to String. If the request contains a XML header,
-- the text encoding is set to UTF8.
soapXmlToString :: String-- ^The content type as seen in the HTTP header
-> BS.ByteString
-> String
soapXmlToString contentType = bsToString (encoding contentType) . setUtf8EncodingInXmlHeader

bsToUtf8 :: String -> BS.ByteString -> BS.ByteString
bsToUtf8 enc = stringToUtf8Bs . bsToString enc

bsToString :: String -> BS.ByteString -> String
bsToString enc bs = E.decodeLazyByteString (E.encodingFromString enc) bs

stringToUtf8Bs :: String -> BS.ByteString
stringToUtf8Bs = E.encodeLazyByteString E.UTF8

-- *** HTTP Header

-- |Produces a HTTP content type header from a charector encoding 
soapContentType :: Maybe String  -- ^ If nothing then it defaults to ISO-8859-1
-> String
soapContentType = maybe ("application/soap+xml;charset=" ++ httpDefaultEncoding) id

-- |Extracts charector encoding from a HTTP content type header
encoding :: String -> String
encoding httpContentType =
case matchRegex (mkRegex "charset=([^; ]*)") httpContentType of
  Just (x:_) -> x
  _  -> httpDefaultEncoding

-- Default charset=ISO-8859-1. See:
-- http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1
-- http://www.w3.org/International/O-HTTP-charset
httpDefaultEncoding :: String
httpDefaultEncoding = "ISO-8859-1"

-- *** XML Header

-- http://www.w3.org/TR/REC-xml/#TextEntities

setUtf8EncodingInXmlHeader :: BS.ByteString -> BS.ByteString
setUtf8EncodingInXmlHeader xml =
  let replaceEnc (name, value)
  | name == "encoding"  = (name, "UTF-8")
  | otherwise   = (name, value) 
  in case parse headerParser "" xml of
   Left _ -> xml
   Right (attrs, rest) -> BS.append (mkHeader $ map replaceEnc attrs) rest

mkHeader :: [(String, String)] -> BS.ByteString
mkHeader attrs =
  let mkAttr (name, value) = " " ++ name ++ "=\"" ++ value ++ "\""
  in BsC8.pack ("\n")

headerParser :: Parser ([(String, String)], BS.ByteString)
headerParser = do
  _ <- string ""
  endPos <- getInput
  return (attrs, endPos)

attrParser :: Parser (String, String)
attrParser = do
  name <- many1 letter
  spaces
  _ <- char '='
  spaces
  _ <- char '"'
  value <- many $ noneOf "\""
  _ <- char '"'
  spaces
  return (name, value)

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


Re: [Haskell-cafe] Problem about pattern matching.

2010-04-28 Thread minh thu
2010/4/28 Magicloud Magiclouds :
> Hi, I have code as below. How come "case" version works wrong and
> gives me "overlap" compiling warning? Thanks.
>  if dayOfMonth == firstDayOfMonth
>    then v day (x, y)
>    else if dayOfMonth == lastDayOfMonth
>      then not_ $ v day (x, y)
>      else Mider day (x, y)
>
>  case dayOfMonth of
>    firstDayOfMonth -> v day (x, y)
>    lastDay -> not_ $ v day (x, y)
>    _ -> Mider day (x, y)

Hi,

firstDayIfMonth and lastDay are new variables, not previously bound
variable. This means that trying to pattern match (the value of)
dayOfMonth will always succeed with the first alternative.

Think of parsing command line argument, using the last alternative as
a fall-through :
args <- getArgs
case args of
  ["--help"] -> ...
  ["--run-tests"] -> ...
  x -> putStrLn $ "unknow args " ++ concat x

What would happen if the last alternative (with the x) was put in
first position ?

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


Re: [Haskell-cafe] Is XHT a good tool for parsing web pages?

2010-04-28 Thread Uwe Schmidt
Hi John and Malcom,

> I know that the HaXml library has a separate error-correcting HTML
> parser that works around most of the common non-well-formedness bugs
> in HTML:
>  Text.XML.HaXml.Html.Parse
>
> I believe HXT has a similar parser:
>  Text.XML.HXT.Parser.HtmlParsec
>
> Indeed, some of the similarities suggest this parser was originally
> lifted directly out of HaXml (as permitted by HaXml's licence),
> although the two modules have now diverged significantly.

The HTML parser in HXT is based on tagsoup. It's a lazy parser
(it does not use parsec) and it tries to parse everything as HTML.
But garbage in, garbage out, there is no approach to repair illegal HTML
as e.g. the Tidy parsers do. The parser uses tagsoup as a scanner.

The table driven approach for inserting missing closing tags is indeed taken
from HaXml. Malcom, I hope you don't have a patent on this algorithm. 

Regards,

   Uwe



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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Duncan Coutts
On 28 April 2010 09:24, Richard G.  wrote:
> I think that formatted plain-text output would be much better than XML,
> something that is human-readable and relatively easy to parse via machine.
>  Something similar to the GHC error output would work well because
> developers are familiar with it.

I have previously advocated a library interface as a detailed
testsuite interface (in addition to a lowest common denominator
interface of stdio+exitcode). That is a test stanza in a package
.cabal file would specify a module containing an entry point of the
right type (like main but using a more interesting type).

That way, cabal or any other tool could run the testsuite and produce
results in whatever format it likes.

As you suggest in your other post, it would make sense to adapt
test-framework to implement the interface specified by Cabal.

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


[Haskell-cafe] Problem about pattern matching.

2010-04-28 Thread Magicloud Magiclouds
Hi, I have code as below. How come "case" version works wrong and
gives me "overlap" compiling warning? Thanks.
  if dayOfMonth == firstDayOfMonth
then v day (x, y)
else if dayOfMonth == lastDayOfMonth
  then not_ $ v day (x, y)
  else Mider day (x, y)

  case dayOfMonth of
firstDayOfMonth -> v day (x, y)
lastDay -> not_ $ v day (x, y)
_ -> Mider day (x, y)
-- 
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Richard G.
I think that, rather than having Cabal try to combine the results of 
different frameworks, Cabal should specify interfaces that frameworks 
need to conform to.


E.g., rather than integrating test-framework into Cabal so that HUnit 
works with it, modify HUnit so it emits the format that Cabal wants. 
And modify test-framework to emit the format that Cabal wants so, if 
someone can't convert their test suite to the CabalTest format, 
test-framework can act as an intermediary and handle the conversion of 
output.


Richard G.

On 10-04-06 5:03 PM, Gregory Crosswhite wrote:

Rather that starting from scratch, you should strongly consider adapting something like 
test-framework to this task, as it already has done the heavy work of creating a way to 
combine tests from different frameworks into a single suite and includes such features as 
displaying a progress bar during the QuickCheck tests.  Furthermore, it is easily 
extendable to support new kinds of tests;  for example, I found that it was relatively 
straightforward to add a new kind of "statistical" test to make sure that the 
average value of a function where where it should be.

Cheers,
Greg

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


Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support

2010-04-28 Thread Richard G.
I think that formatted plain-text output would be much better than XML, 
something that is human-readable and relatively easy to parse via 
machine.  Something similar to the GHC error output would work well 
because developers are familiar with it.


Test :



E.g.,

Test 1:Passed
src/Some/File.hs:23

Test 2:Failed
src/Some/File.hs:27
Expecting `4'; received `5'.

Test 3:Error
src/Some/OtherFile.hs:39
Unexpected exception.

This would keep the complexity low in Cabal and allow for easy 
transformation to XML.


Richard G.

On 10-04-08 8:30 PM, Rogan Creswick wrote:

On Thu, Apr 8, 2010 at 5:53 AM, Duncan Coutts
  wrote:


I think it's important to be able to convert into standard or custom
formats. I've no idea if JUnit XML would make sense as the native
format. It's plausible.



I hadn't really thought about cabal, itself, being a consumer for test
results -- but I like your (Duncan's) points about defining a testing
interface, and keeping it extensible.

For the record: I don't think junit xml is a good choice for a native
format :), but I do think it's a good format to start with simply
because there are many tools that can consume it already.

--Rogan



Duncan

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


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


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


Re: [Haskell-cafe] Lazy Parsing (ANN: vcd-0.1.4)

2010-04-28 Thread S. Doaitse Swierstra

On 27 apr 2010, at 22:12, Jason Dusek wrote:

>  So UU parsers can construct input?

The perform an editing action on the input so it becomes a sentence of the 
language recognised. 

> The presence of an
>  empty list in the 2nd slot of the tuple is the only
>  indicator of errors?

The parser wants to see a natural number, whch is a non-empty list of digits. 
So it inserts a single digit, which is any character from the range '0'-'9'. 
Since no default value is given here, it takes the first one from the range: 
'0'. Furthermore you get a list of errors, which tell you which correcting 
steps were taken. There is a special combinator with which you can ask for the 
errors produced since the last time you asked, and which you can use to control 
further parsing.

> 
>  For parsing datatypes without a sensible default value,
>  what happens?

If you do nothing you get a less sensible default value; 
you may however provide (lower costs) extra alternatives which will be taken by 
the correcting process. There is a cost model which can be used to control the 
correction process. Tokens have a specific insertion cost and a specific 
deletion cost with which you can play. Usually this is not necessary. The 
typical process is that at first you do not pay attention to the correction 
process, and once you see things you really do not want, you provide an extra 
alternative, or rule out some alternatives by increasuig costs. 

In the UHC token like "if" have a high cost, since we think there is very 
little chance that people will forget to write them. A ')' can have a lower 
insertion and deletion cost, since people are more likely to have too many or 
not enough of them.



 Doaitse




> 
> --
> Jason Dusek

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


[Haskell-cafe] Re: Haskell Weekly News?

2010-04-28 Thread Heinrich Apfelmus
David Sankel wrote:
> I'm wondering if a monetary incentive would keep the person who does this
> work more accountable. I personally would be willing to contribute to
> continue getting this service. I wonder if there are others as well.

Maybe Flattr  http://flattr.com/  fits the bill concerning monetary
appreciation.


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

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