Re: [Haskell-cafe] Execution call graph pruning

[C K Kashyap]

Thanks Ivan.
Regards,
Kashyap

On Wed, Jun 9, 2010 at 4:40 AM, Ivan Lazar Miljenovic <
ivan.miljeno...@gmail.com> wrote:

> C K Kashyap  writes:
>
> > Hi,
> > I have a call grah which contains information of the edges in the
> following
> > format
> >
> > caller  callee  count   (time spent by the
> > caller)
> > ===
> > foo  bar  10100
> > xxx  yyy  2010
> > zzz  yyy  1010
> >
> > (I used pintool pintool.org to generate this call graph)
> >
> > Now, the problem is that the graph is huge and it take a long to render
> > using 'dot' or use any visualizing tool.
> > Even if they render, it's too cluttered to be useful.
> > I wanted to prune the graph in such a way that I'd have only the edges
> > corresponding to the top 10% of the
> > time consumers. What would be a good way to do such a thing? Has anyone
> > written some utility that I could use?
>
> Well, graphviz [1] lets you parse Dot code, so you could then do a
> filter on it (I'm currently working on ways of letting you interact with
> the Dot code better).
>
> [1]: http://hackage.haskell.org/package/graphviz
>
> Also, to let you skip a step prof2dot [2] will create the Dot code for you.
>
> [2]: http://hackage.haskell.org/package/prof2dot
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> IvanMiljenovic.wordpress.com
>



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

Re: [Haskell-cafe] Strange discrepancy between Emacs interpreter and command-line on windows

[Ivan Miljenovic]

On 10 June 2010 14:28, Arnaud Bailly  wrote:
> I did:
>
> ghc-pkg unregister bytestring-0.9.1.6
>
> then restarted emacs and it works now. Don't now if ther weill be
> side-effects on other packages...

"ghc-pkg check" will tell if you if there are any breakages.

-- 
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] Strange discrepancy between Emacs interpreter and command-line on windows

[Arnaud Bailly]

I did:

ghc-pkg unregister bytestring-0.9.1.6

then restarted emacs and it works now. Don't now if ther weill be
side-effects on other packages...

Thanks for the tip.

arnaud

On Thu, Jun 10, 2010 at 6:15 AM, Arnaud Bailly  wrote:
> Yes, I have two versions installed , 0.9.1.4 and 0.9.1.6. Here is the
> output of ghc-pkg -l:
>
> d:/Program Files/Haskell Platform/2009.2.0.2\package.conf:
>    Cabal-1.6.0.3, GLUT-2.1.1.2, HSlim-0.1, HTTP-4000.0.6,
>    HUnit-1.2.0.3, OpenGL-2.2.1.1, QuickCheck-1.2.0.0,
>    QuickCheck-2.1.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1,
>    base-4.1.0.0, bytestring-0.9.1.4, bytestring-0.9.1.6,
>    cgi-3001.1.7.1, containers-0.2.0.1, directory-1.0.0.3,
>    (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3),
>    (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3),
>    extensible-exceptions-0.1.1.0, fgl-5.4.2.2, filepath-1.1.0.2,
>    (ghc-6.10.4), ghc-prim-0.1.0.0, haddock-2.4.2, haskell-src-1.0.1.3,
>    haskell98-1.0.1.0, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1,
>    mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, old-time-1.0.0.2,
>    packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1,
>    pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1,
>    regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3,
>    rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1,
>    time-1.1.2.4, utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0
>
> However, I tried to force the version I use to be 0.9.1.6 and it does
> not work as ghc itself seems to require 0.9.1.4, as pointed out by
> Ivan. I did not try to remove one or the other however.
>
> Arnaud
>
> On Thu, Jun 10, 2010 at 12:13 AM, Ivan Lazar Miljenovic
>  wrote:
>> Don Stewart  writes:
>>
>>> arnaud.oqube:
 Hello,
 I have a strange issue which sprang today out of nowhere. When I load
 a certain file using bytestring package in Ghci using emacs, I got the
 following error:

 Couldn't match expected type `Data.ByteString.Internal.ByteString'
            against inferred type
 `bytestring-0.9.1.4:Data.ByteString.Internal.ByteString'
     In the second argument of `hPutStrLn', namely `(fromString msgs)'
     In a stmt of a 'do' expression: hPutStrLn cnx (fromString msgs)

 The same file compiles fine on the command-line. I have a single
 installation of haskell platform, using ghc 6.10.4, on windows XP.

>>>
>>> Looks like you might have two versions of bytestring installed (ghc-pkg
>>> list bytestring) and are attempting to combine them. The diamond
>>> dependency problem.
>>>
>>>     * delete the old version (ghc-pkg unregister)
>>
>> Isn't the old version likely to be the one that comes with GHC and hence
>> shouldn't be touched?
>>
>> --
>> 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] Strange discrepancy between Emacs interpreter and command-line on windows

[Arnaud Bailly]

Yes, I have two versions installed , 0.9.1.4 and 0.9.1.6. Here is the
output of ghc-pkg -l:

d:/Program Files/Haskell Platform/2009.2.0.2\package.conf:
Cabal-1.6.0.3, GLUT-2.1.1.2, HSlim-0.1, HTTP-4000.0.6,
HUnit-1.2.0.3, OpenGL-2.2.1.1, QuickCheck-1.2.0.0,
QuickCheck-2.1.0.3, Win32-2.2.0.0, array-0.2.0.0, base-3.0.3.1,
base-4.1.0.0, bytestring-0.9.1.4, bytestring-0.9.1.6,
cgi-3001.1.7.1, containers-0.2.0.1, directory-1.0.0.3,
(dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3),
(dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3),
extensible-exceptions-0.1.1.0, fgl-5.4.2.2, filepath-1.1.0.2,
(ghc-6.10.4), ghc-prim-0.1.0.0, haddock-2.4.2, haskell-src-1.0.1.3,
haskell98-1.0.1.0, hpc-0.5.0.3, html-1.0.1.2, integer-0.1.0.1,
mtl-1.1.0.2, network-2.2.1.4, old-locale-1.0.0.1, old-time-1.0.0.2,
packedstring-0.1.0.1, parallel-1.1.0.1, parsec-2.1.0.1,
pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1,
regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3,
rts-1.0, stm-2.1.1.2, syb-0.1.0.1, template-haskell-2.3.0.1,
time-1.1.2.4, utf8-string-0.3.6, xhtml-3000.2.0.1, zlib-0.5.0.0

However, I tried to force the version I use to be 0.9.1.6 and it does
not work as ghc itself seems to require 0.9.1.4, as pointed out by
Ivan. I did not try to remove one or the other however.

Arnaud

On Thu, Jun 10, 2010 at 12:13 AM, Ivan Lazar Miljenovic
 wrote:
> Don Stewart  writes:
>
>> arnaud.oqube:
>>> Hello,
>>> I have a strange issue which sprang today out of nowhere. When I load
>>> a certain file using bytestring package in Ghci using emacs, I got the
>>> following error:
>>>
>>> Couldn't match expected type `Data.ByteString.Internal.ByteString'
>>>            against inferred type
>>> `bytestring-0.9.1.4:Data.ByteString.Internal.ByteString'
>>>     In the second argument of `hPutStrLn', namely `(fromString msgs)'
>>>     In a stmt of a 'do' expression: hPutStrLn cnx (fromString msgs)
>>>
>>> The same file compiles fine on the command-line. I have a single
>>> installation of haskell platform, using ghc 6.10.4, on windows XP.
>>>
>>
>> Looks like you might have two versions of bytestring installed (ghc-pkg
>> list bytestring) and are attempting to combine them. The diamond
>> dependency problem.
>>
>>     * delete the old version (ghc-pkg unregister)
>
> Isn't the old version likely to be the one that comes with GHC and hence
> shouldn't be touched?
>
> --
> 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] Contacting Planet Haskell

[Jason Dagit]

Hello,

I recently tried to send an email to the planet Haskell admins.  The webpage
says to use pla...@community.haskell.org.  The mail was undelivered after
several days and the daemon gave up trying to deliver it.

My sending did overlap with the haskell.org downtown but I don't think that
should have been a problem because:
1) It looks like it retried after haskell.org was back up
2) I'm pretty sure community is a different host than haskell.org
3) Shouldn't a backup mx handle this?

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

Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[Ivan Miljenovic]

On 10 June 2010 12:38, sterl  wrote:
> There's a big range of issues here, and to be honest I'm not sure if our
> ability to distinguished between them is helped by the title of this thread,
> which somewhat begs the question. That is to say, it isn't clear to me that
> calling the proposed changes to the fgl "rewriting a library" is necessarily
> accurate -- it seems more the case that these are incremental improvements
> of a library that require breaking API changes.

Except it is a re-write in the truest sense of the word: we started
completely from scratch.  We did compare our API with the current API
(in an attempt to keep function names, etc. the same where possible
because I'm hopeless at choosing names) but we didn't exactly take the
class as-is and then change it.  On the other hand, we were both
familiar with the current version of FGL and how it's layed out, so
there's probably some implicit influences from there as well.

Oh the other hand, it can also be considered as incremental
improvements: we wanted to keep the terminology and fundamental
concepts as similar as possible to avoid having a jarrring change in
how its used.  Instead, we focused on improving the current version:
using explicit data types for Context and Edge (for why Edge needs a
data type of its own, read the Graph section of "Fun with type
functions" by Oleg, SPJ and Chung-chieh Shan) rather than tuple
aliases; allowing restrictions on the label types (though we've just
come across a problem where this doesn't play nicely with mapping
functions); increasing the scope for per-instance optimisations, etc.

So in a sense we did a re-write that happened to come close to the
current definition.  This is not to say that this is because the
current API is close to an ideal perfect API, but rather because we
were focussing on developing something _like_ the current version
without worrying about compatability too much.

> So on the concrete issue at hand, I'd be for the new fgl version being
> developed under some new provisional name, and taking pains to provide a
> compatibility layer where possible. Then, after we see what the changes
> really are, coming to some informed decision on whether to rebrand it as the
> real fgl version 6. If so, the old stable fgl can be put up on hackage as
> fgl98, which lets packages which want to stick with it do so while avoiding
> any possibility of the dread diamond dependency.

Considering the "rename the old version" issues first:

* It won't solve the problem of people not specifying correct
constraints on the version of fgl used, since it means they'd have to
edit their dependencies to use fgl98 or whatever anyway.

* Calling it "fgl98" is on a slippery slope: what happens when
GHC-6.14 comes out with Haskell2010 support?  Do we then release an
fgl2010 version as well? (I believe Ross brought this problem up
already).

* I'm wanting people to move _off_ of the old version of fgl.  The
only real advantage (though how practical this will be in the real
world is debateable IMHO) is that the current version doesn't use any
extensions whereas the new one does (and they're needed to provide the
asked-for functionality of letting instance writers constrain the
types of labels - i.e. the reason why Set isn't an instance of Functor
- and to have custom Node types).  Since (like it or not) for the most
part when people write Haskell code they use GHC and GHC supports
these extensions, I do not think this is that much of a problem (I am
open to being convinced otherwise about this though; I think it would
be _great_ if there were other Haskell compilers that were as good as
if not better than GHC in terms of runtime, etc. ... until I start
considering how to manage two different compilers in Gentoo, etc. :p).

As for having a temporary name for the testing releases, I am open to
doing so, but this in affect pollutes the package name-space with
packages that shouldn't/wouldn't be used.  I would prefer to host it
elsewhere and just tell people to grab a copy and see what they think
rather than use a temporary name and then change it later when its
"stabilised".  It would be preferable IMO that if we were going to
change package names then it should be done once and then not changed
again.

> More broadly, we have to accept that breaking API changes are an irritating
> but necessary fact of life. As much as the parsec and quickcheck issues have
> caused some modest pain, there's been equal hassle from things like the
> strictness behavior of binary, or even the type change in tagsoup. Splitting
> out Category from Arrow caused me probably the most hassle. In retrospect it
> was the right thing to do. But how it was done was particularly abrupt and
> painful. Exceptions got it right in pretty much every respect, but still
> migration necessarily took some work. We want our packages to grow,
> including our core packages. Otherwise we get fragmentation and duplicated
> effort. When we want to grow, but don

Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons

[sterl]

There's a big range of issues here, and to be honest I'm not sure if our 
ability to distinguished between them is helped by the title of this 
thread, which somewhat begs the question. That is to say, it isn't clear 
to me that calling the proposed changes to the fgl "rewriting a library" 
is necessarily accurate -- it seems more the case that these are 
incremental improvements of a library that require breaking API changes.


So on the concrete issue at hand, I'd be for the new fgl version being 
developed under some new provisional name, and taking pains to provide a 
compatibility layer where possible. Then, after we see what the changes 
really are, coming to some informed decision on whether to rebrand it as 
the real fgl version 6. If so, the old stable fgl can be put up on 
hackage as fgl98, which lets packages which want to stick with it do so 
while avoiding any possibility of the dread diamond dependency.


More broadly, we have to accept that breaking API changes are an 
irritating but necessary fact of life. As much as the parsec and 
quickcheck issues have caused some modest pain, there's been equal 
hassle from things like the strictness behavior of binary, or even the 
type change in tagsoup. Splitting out Category from Arrow caused me 
probably the most hassle. In retrospect it was the right thing to do. 
But how it was done was particularly abrupt and painful. Exceptions got 
it right in pretty much every respect, but still migration necessarily 
took some work. We want our packages to grow, including our core 
packages. Otherwise we get fragmentation and duplicated effort. When we 
want to grow, but don't know exactly how, then we get experimentation. 
But experimentation without some organization can lead to the wrong sort 
of fragmentation -- like the mtl mess, whose resolution now thankfully 
seems to be in hand.


Some lessons I think we can learn from the past about changes to 
widely-used stable APIs:

* Clear and documented upgrade paths.
* Preferably a compat layer (Exceptions and Parsec both did a killer job 
with this).

* No, or demonstrably minimal performance regressions.
* Strong release notes and other documentation, either duplicating or 
supplementing what existed prior.
* For particularly long-lived stable APIs, forking off a 
maintenance-mode-only version may make good sense, especially when the 
subset of language extensions used differs significantly.


Some lessons to us API consumers who write somewhat-less-core packages:
* Upper version bounds.
* If at all possible, don't move to the fancy new thing until the fancy 
new thing is fully baked, and on track to widespread adoption. (early 
adopters of new mtl implementations, I'm looking at you :-))
* If at all possible, try to stay compatible with at least the prior GHC 
version as well as the current.
* Don't pull in big packages for small reasons unless really necessary 
-- minor duplication of trivial code is often the lesser evil.


Some lessons for folks exploring new variants:
* Don't step on already-used module names.
* Make clear whether you intend a package as a demonstration/proof of 
concept or are fully committed to significant development and support.


Some technical issues that will help as time goes on (many already 
underway):
* Depreciation of packages on hackage/redirects. (Makes it easier to 
establish upgrade / migration / transition paths).
* Tree organization of packages on hackage. (Reduces the noise generated 
by lots of small packages, and so encourages splitting things out).
* Wikilike documentation features on hackage (lets users contribute and 
share upgrade paths, etc. more directly and simply -- hopefully will 
help with community documentation of packages in general).
* The "local usage" annotation for cabal files to help avoid the dread 
diamond dependency.

* The package version policy checker.
* A DSL to describe transforms of Haskell programs for at least simple 
API migrations. Yes, this is a bit more "out there" but it's a great 
space to explore. The upside is not only better tools to help authors 
migrate their code, but a strong representation of what exactly the API 
changes are. So even if the spec language describes things that can't be 
applied automatically, it can still formalize what authors need to do. A 
standard format for an API change log as a hackage plugin would be a 
good start to this.


The above lists are pretty incomplete, but hopefully they're useful. 
Thanks to Don for kicking this discussion off.


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

[Haskell-cafe] Re: GATD and pattern matching

[Maciej Piechotka]

On Wed, 2010-06-09 at 22:28 +0200, Dupont Corentin wrote:
> Thanks for your response.
> 
> How would you do it? I design this GATD for a game i'm making:
> 
> > data Obs a where 
> > Player :: Obs Integer 
> > Turn :: Obs Integer
> > Official :: Obs Bool 
> > Equ :: Obs a -> Obs a -> Obs Bool   --woops!!
> > Plus :: (Num a) => Obs a -> Obs a -> Obs a 
> > Time :: (Num a) => Obs a -> Obs a -> Obs a 
> > Minus :: (Num a) => Obs a -> Obs a -> Obs a 
> > Konst :: a -> Obs a 

Actually woops is here. Make it for example

Const :: (Show a, Eq a, ...) => a -> Obs a

> > And :: Obs Bool -> Obs Bool -> Obs Bool 
> > Or :: Obs Bool -> Obs Bool -> Obs Bool
> 
> For example I can design an Observable like that:
> 
> myObs = Player `Equ` (Konst 1) `And` Official
> 
> These Observables will then be processed during gameplay.
> 
> I would like to be able to do in ghci:
> 
> > show myObs
> Player `Equ` (Konst 1) `And` Official
> 
> and:
> >  myObs == myObs
> True
> 

Regards



signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Removing alternate items from a list

[John Meacham]

On Wed, Jun 09, 2010 at 11:47:32PM +0300, Markus Läll wrote:
> As the function doing (x:_:rest) pattern-matching was the fastest I
> extended the idea from that to (x1:_:x2: ... x10:_:rest), but skipping
> from 5 to 10, where all steps showed a small increase in performance.
> 
> So a question: when increasing the pattern matched, is it somekind of
> way of inlining the matchings, and if so, is there some way of just
> saying that to the compiler how many recursions you want to inline
> together to increase speed?

What you are describing is somewhat akin to a loop unrolling
optimization, which is a fairly common thing for a compiler to do.
However, as you described it, it is not actually a valid optimization in
haskell. compare

take 2 (matchPattern5 (1:2:3:4:undefined)) => undefined
take 2 (matchPattern  (1:2:3:4:undefined)) => [1,3]

John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Problems with threading?

[Don Stewart]

igouy2:
> 
> Now how do we get those regex-dna and binary-trees programs to compile?
> 
> http://shootout.alioth.debian.org/u32/measurements.php?lang=ghc
> 

binary-trees:
Could not find module `Control.Parallel.Strategies':

--> cabal install parallel

regex-dna:

" cannot satisfy -package regex-posix"

--> cabal install regex-posix


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

Re: [Haskell-cafe] Problems with threading?

[Isaac Gouy]

--- On Mon, 6/7/10, Don Stewart  wrote:

> From: Don Stewart 
> Subject: Re: [Haskell-cafe] Problems with threading?
> To: "Isaac Gouy" 
> Cc: "Louis Wasserman" , "Haskell Café List" 
> 
> Date: Monday, June 7, 2010, 4:43 PM
> igouy2:
> > As Louis has already mentioned this to me, I'll take
> the opportunity
> > to sketch out a simple approach - 
> > 
> > 
> > 1) GHC programs compiled without -threaded and run
> without +RTS -N are already shown for x86 and x64
> > 
> > http://shootout.alioth.debian.org/u32/compare.php?lang=ghc
> > 
> > http://shootout.alioth.debian.org/u64/compare.php?lang=ghc
> > 
> > 
> > 2) For quad-core, the GHC programs will all be
> compiled with -threaded and all run with +RTS -N4 
> > 
> > 
> > 3) That seems to match the approach taken with Erlang,
> where all the
> > programs on quad-core run with smp built into the vm,
> and all the
> > programs on one core run without smp built into the
> vm. 
> > 
> 
> Yep, that's fine.



All the GHC programs have been re-measured.

http://shootout.alioth.debian.org/u64q/compare.php?lang=ghc

http://shootout.alioth.debian.org/u32/compare.php?lang=ghc



Now how do we get those regex-dna and binary-trees programs to compile?

http://shootout.alioth.debian.org/u32/measurements.php?lang=ghc





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

Re: [Haskell-cafe] Strange discrepancy between Emacs interpreter and command-line on windows

[Ivan Lazar Miljenovic]

Don Stewart  writes:

> arnaud.oqube:
>> Hello,
>> I have a strange issue which sprang today out of nowhere. When I load
>> a certain file using bytestring package in Ghci using emacs, I got the
>> following error:
>> 
>> Couldn't match expected type `Data.ByteString.Internal.ByteString'
>>against inferred type
>> `bytestring-0.9.1.4:Data.ByteString.Internal.ByteString'
>> In the second argument of `hPutStrLn', namely `(fromString msgs)'
>> In a stmt of a 'do' expression: hPutStrLn cnx (fromString msgs)
>> 
>> The same file compiles fine on the command-line. I have a single
>> installation of haskell platform, using ghc 6.10.4, on windows XP.
>> 
>
> Looks like you might have two versions of bytestring installed (ghc-pkg
> list bytestring) and are attempting to combine them. The diamond
> dependency problem.
>
> * delete the old version (ghc-pkg unregister)

Isn't the old version likely to be the one that comes with GHC and hence
shouldn't be touched?

-- 
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] How to "Show" an Operation?

[Luke Palmer]

On Wed, Jun 9, 2010 at 12:33 PM, Martin Drautzburg
 wrote:
> So far so good. However my "Named" things are all functions and I don't see I
> ever want to map over any of them. But what I'd like to do is use them like
> ordinary functions as in:
>
> f::Named (Int->Int)
> f x
>
> Is there a way to do this, other than writing
>
> apply::Named Int ->Int
> apply n x = (val_of n) x

What's wrong with that?  (Other than the type signature, but I get
what you mean).  The proper type signature is apply :: Named (Int ->
Int) -> Int -> Int.

You don't need the parentheses:

apply n x = val_of n x

Or just:

apply = val_of

I frequently suggest the following to new Haskellers: don't worry so
much about notation.  Sometimes programmers get a picture in their
heads about how the code *should* look, and then they go through all
manner of ugly contortions to make the notation right.

I suggest that you will encounter much less pain if you accept
Haskell's straightforward notation, and focus on the meaning rather
than the syntax of your program.

So, to summarize:  if you have something that isn't a function and you
want to use it like a function, convert it to a function (using
another function :-P).  That's all.  No syntax magic, just say what
you're doing.

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

Re: [Haskell-cafe] Removing alternate items from a list

[Yitzchak Gale]

Markus Läll wrote:
> So out of curiosity i took the definitions given in this thread, and
> tried to run timing-tests.

Nice!

> Any comments? (besides -O2 ;-)  -- I remembered it too late and didn't
> want to restart...

Oh, could you please run that again with -O2?

My entry dearly depends on it :)

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

Re: [Haskell-cafe] Strange discrepancy between Emacs interpreter and command-line on windows

[Don Stewart]

arnaud.oqube:
> Hello,
> I have a strange issue which sprang today out of nowhere. When I load
> a certain file using bytestring package in Ghci using emacs, I got the
> following error:
> 
> Couldn't match expected type `Data.ByteString.Internal.ByteString'
>against inferred type
> `bytestring-0.9.1.4:Data.ByteString.Internal.ByteString'
> In the second argument of `hPutStrLn', namely `(fromString msgs)'
> In a stmt of a 'do' expression: hPutStrLn cnx (fromString msgs)
> 
> The same file compiles fine on the command-line. I have a single
> installation of haskell platform, using ghc 6.10.4, on windows XP.
> 

Looks like you might have two versions of bytestring installed (ghc-pkg
list bytestring) and are attempting to combine them. The diamond
dependency problem.

* delete the old version (ghc-pkg unregister)
* recompile any libs that depend on it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Strange discrepancy between Emacs interpreter and command-line on windows

[Arnaud Bailly]

Hello,
I have a strange issue which sprang today out of nowhere. When I load
a certain file using bytestring package in Ghci using emacs, I got the
following error:

Couldn't match expected type `Data.ByteString.Internal.ByteString'
   against inferred type
`bytestring-0.9.1.4:Data.ByteString.Internal.ByteString'
In the second argument of `hPutStrLn', namely `(fromString msgs)'
In a stmt of a 'do' expression: hPutStrLn cnx (fromString msgs)

The same file compiles fine on the command-line. I have a single
installation of haskell platform, using ghc 6.10.4, on windows XP.

Thanks for any help,
Arnaud Bailly
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Removing alternate items from a list

[Markus Läll]

Forgot the file -- here it is:

module Main where

import Data.Either (rights)
import Data.Function (fix)

test f = putStr $ show $ last $ f $ replicate 1000 (1 :: Int)

main = test matchPattern4
-- 1. zipNums
-- 2. matchPattern
-- 3. zipBoolCycle
-- 4. iterDrop
-- 5. zipBoolCycle2
-- 6. consume
-- 7. eitherr
-- 8. golf
-- 9. matchPattern2
-- 10. matchPattern3
-- 11. matchPattern4
-- 12. matchPattern5
-- 13. matchPattern10

-- 1. total time  =   13.72 secs   (686 ticks @ 20 ms)
--total alloc = 1,840,007,000 bytes  (excludes profiling overheads)
zipNums = map snd . filter (odd . fst) . zip [1,2..]

-- 2. total time  =1.82 secs   (91 ticks @ 20 ms)
--total alloc = 400,006,752 bytes  (excludes profiling overheads)
matchPattern (x:_:zs) = x : matchPattern zs
matchPattern x = x

-- 3. total time  =4.46 secs   (223 ticks @ 20 ms)
--total alloc = 1,040,006,904 bytes  (excludes profiling overhea
zipBoolCycle xs = map fst . filter snd $ zip xs (cycle [False, True])

-- 4 total time  =5.20 secs   (260 ticks @ 20 ms)
--   total alloc = 940,006,916 bytes  (excludes profiling overheads)
iterDrop = map head . takeWhile (not . null) . iterate (drop 2) . drop 1


-- 5 total time  =3.68 secs   (184 ticks @ 20 ms)
--   total alloc = 820,006,872 bytes  (excludes profiling overheads)
zipBoolCycle2 x = [y | (True, y) <- zip (cycle [False, True]) x]


-- 6. total time  =2.46 secs   (123 ticks @ 20 ms)
--total alloc = 420,006,860 bytes  (excludes profiling overheads)
data Consume = Take | Skip
consumeBy :: [Consume] -> [a] -> [a]
consumeBy [] _ = []
consumeBy _ [] = []
consumeBy (tOrS:takesAndSkips) (x:xs) =
   case tOrS of Take -> x : consumeBy takesAndSkips xs
Skip -> consumeBy takesAndSkips xs
consume = consumeBy $ cycle [Take, Skip]


-- 7. total time  =4.10 secs   (205 ticks @ 20 ms)
--total alloc = 1,000,006,884 bytes  (excludes profiling overheads)
eitherr = rights . zipWith ($) (cycle [Left,Right])


-- 8. total time  =2.08 secs   (104 ticks @ 20 ms)
--total alloc = 420,006,784 bytes  (excludes profiling overheads)
golf = (fix $ \f xs -> case xs of { (x:_: xs) -> x : f xs; _ -> [] })


-- 9. total time  =1.68 secs   (84 ticks @ 20 ms)
--total alloc = 370,006,752 bytes  (excludes profiling overheads)
matchPattern2 (a:_:c:_:rest)  = a : c : matchPattern2 rest
matchPattern2 (a:_:rest)  = a : rest
matchPattern2 (rest)  = rest

-- 10. total time  =1.58 secs   (79 ticks @ 20 ms)
-- total alloc = 360,006,744 bytes  (excludes profiling overheads)
matchPattern3 (a:_:c:_:e:_: rest) = a : c : e : matchPattern3 rest
matchPattern3 (a:_:c:_:rest)  = a : c : rest
matchPattern3 (a:_:rest)  = a : rest
matchPattern3 (rest)  = rest

-- 11. total time  =1.56 secs   (78 ticks @ 20 ms)
-- total alloc = 355,006,752 bytes  (excludes profiling overheads)
matchPattern4 (a:_:c:_:e:_:g:_:rest) = a : c : e : g : matchPattern4 rest
matchPattern4 (a:_:c:_:e:_: rest)= a : c : e : rest
matchPattern4 (a:_:c:_:rest) = a : c : rest
matchPattern4 (a:_:rest) = a : rest
matchPattern4 (rest) = rest

-- 12. total time  =1.52 secs   (76 ticks @ 20 ms)
-- total alloc = 352,006,752 bytes  (excludes profiling overheads)
matchPattern5 (a:_:c:_:e:_:g:_:i:_:rest) = a : c : e : g : i :
matchPattern5 rest
matchPattern5 (a:_:c:_:e:_:g:_:rest) = a : c : e : g : rest
matchPattern5 (a:_:c:_:e:_: rest)= a : c : e : rest
matchPattern5 (a:_:c:_:rest) = a : c : rest
matchPattern5 (a:_:rest) = a : rest
matchPattern5 (rest) = rest

-- 13. total time  =1.48 secs   (74 ticks @ 20 ms)
-- total alloc = 346,006,752 bytes  (excludes profiling overheads)
matchPattern10 (a:_:c:_:e:_:g:_:i:_:k:_:m:_:o:_:q:_:s:_:rest) =
a:c:e:g:i:k:m:o:q:s: matchPattern10 rest
matchPattern10 (a:_:c:_:e:_:g:_:i:_:k:_:m:_:o:_:q:_:rest) =
a:c:e:g:i:k:m:o:q:rest
matchPattern10 (a:_:c:_:e:_:g:_:i:_:k:_:m:_:o:_:rest) =
a:c:e:g:i:k:m:o:rest
matchPattern10 (a:_:c:_:e:_:g:_:i:_:k:_:m:_:rest) =
a:c:e:g:i:k:m:rest
matchPattern10 (a:_:c:_:e:_:g:_:i:_:k:_:rest) = a:c:e:g:i:k:rest
matchPattern10 (a:_:c:_:e:_:g:_:i:_:rest) = a:c:e:g:i:rest
matchPattern10 (a:_:c:_:e:_:g:_:rest) = a:c:e:g:rest
matchPattern10 (a:_:c:_:e:_: rest)= a:c:e:rest
matchPattern10 (a:_:c:_:rest) = a:c:rest
matchPattern10 (a:_:rest) = a:rest
matchPattern10 (rest) = rest

On Wed, Jun 9, 2010 at 11:47 PM, Markus Läll  wrote:
> So out of curiosity i took the definitions given in this thread, and
> tried to run timing-tests.
> Here's what I ran:
>> ghc -prof -auto-all -o Test Test.h
>> Test +RTS -p
> and then looked in the Test.prof file.
>
> A

Re: [Haskell-cafe] Removing alternate items from a list

[Markus Läll]

So out of curiosity i took the definitions given in this thread, and
tried to run timing-tests.
Here's what I ran:
> ghc -prof -auto-all -o Test Test.h
> Test +RTS -p
and then looked in the Test.prof file.

All tests I ran from 3 to 10 times (depending on how sure I wanted to
be), so the  results are not entirely exact. (I copied the "average"
result to the source-file as comments above every function.)

As the function doing (x:_:rest) pattern-matching was the fastest I
extended the idea from that to (x1:_:x2: ... x10:_:rest), but skipping
from 5 to 10, where all steps showed a small increase in performance.

So a question: when increasing the pattern matched, is it somekind of
way of inlining the matchings, and if so, is there some way of just
saying that to the compiler how many recursions you want to inline
together to increase speed?

Any comments? (besides -O2 ;-)  -- I remembered it too late and didn't
want to restart... At least for the last two functions it showed a
similar difference in seconds as with no -O2)


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

Re: [Haskell-cafe] GATD and pattern matching

[Dupont Corentin]

Thanks for your response.

How would you do it? I design this GATD for a game i'm making:

> data Obs a where
> Player :: Obs Integer
> Turn :: Obs Integer
> Official :: Obs Bool
> Equ :: Obs a -> Obs a -> Obs Bool   --woops!!
> Plus :: (Num a) => Obs a -> Obs a -> Obs a
> Time :: (Num a) => Obs a -> Obs a -> Obs a
> Minus :: (Num a) => Obs a -> Obs a -> Obs a
> Konst :: a -> Obs a
> And :: Obs Bool -> Obs Bool -> Obs Bool
> Or :: Obs Bool -> Obs Bool -> Obs Bool

For example I can design an Observable like that:

myObs = Player `Equ` (Konst 1) `And` Official

These Observables will then be processed during gameplay.

I would like to be able to do in ghci:

> show myObs
Player `Equ` (Konst 1) `And` Official

and:
>  myObs == myObs
True



Corentin

On Wed, Jun 9, 2010 at 9:10 PM, Daniel Fischer wrote:

> On Wednesday 09 June 2010 20:37:22, Dupont Corentin wrote:
> > Hello,
> >
> > I am making a little GATD:
> > > {-# LANGUAGE GADTs#-}
> > >
> > > data Obs a where
> > > Equal :: Obs a -> Obs a -> Obs Bool
> > > Plus :: (Num a) => Obs a -> Obs a -> Obs a
> >
> > (etc..)
> >
> > > instance Show t => Show (Obs t) where
> > > show (Equal a b) = (show a) ++ " Equal " ++ (show b)
> > > show (Plus a b) = (show a) ++ " Plus " ++ (show b)
> > >
> > > instance Eq t => Eq (Obs t) where
> > > a `Equal` b == c `Equal` d = (a == c) && (b == d)
> > > a `Plus` b == c `Plus` d = (a == c) && (b == d)
> >
> > The Equal constructor causes me problems, while the Plus is fine:
> >
> > test3.lhs:8:26:
> > Could not deduce (Show a) from the context (t ~ Bool)
> >   arising from a use of `show' at test3.lhs:8:26-31
> > Possible fix:
> >   add (Show a) to the context of the constructor `Equal'
> > In the first argument of `(++)', namely `(show a)'
> > In the expression: (show a) ++ " Equal " ++ (show b)
> > In the definition of `show':
> > show (Equal a b) = (show a) ++ " Equal " ++ (show b)
> >
> >
> > I guess this is because GADT refines type with pattern matching.
> > Since Equal return type is Obs Bool and not Obs a, it cannot bind the
> > type variable a to belong to Show.
>
> Right. You can have
>
> (+ 3) `Equal` sin :: Obs Bool
>
> , but how would you show it?
>
> You could add a (Show a) constraint to Equal.
>
> >
> > I don't see how to precise the type in the pattern match.
> >
> > I have another problem:
> >
> > test3.lhs:12:41:
> > Couldn't match expected type `a' against inferred type `a1'
> >   `a' is a rigid type variable bound by
> >   the constructor `Equal' at test3.lhs:12:8
> >   `a1' is a rigid type variable bound by
> >the constructor `Equal' at test3.lhs:12:23
> >   Expected type: Obs a
> >   Inferred type: Obs a1
> > In the second argument of `(==)', namely `c'
> > In the first argument of `(&&)', namely `(a == c)'
>
> ((+ 3) `Equal` sin) == (True `Equal` False)
>
> Doesn't work.
>
> And you can't make it work, because in
>
> (a `Equal` b) == (c `Equal` d)
>
> , a and b have the same type t1, and c and d have the same type t2 but the
> two types t1 and t2 are generally different, so calling (==) on a and c has
> no chance to type-check. With Equal forgetting the type parameter of its
> arguments, I don't think it's possible.
>
> >
> >
> > Cheers,
> > Corentin
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GATD and pattern matching

[Daniel Fischer]

On Wednesday 09 June 2010 20:37:22, Dupont Corentin wrote:
> Hello,
>
> I am making a little GATD:
> > {-# LANGUAGE GADTs#-}
> >
> > data Obs a where
> > Equal :: Obs a -> Obs a -> Obs Bool
> > Plus :: (Num a) => Obs a -> Obs a -> Obs a
>
> (etc..)
>
> > instance Show t => Show (Obs t) where
> > show (Equal a b) = (show a) ++ " Equal " ++ (show b)
> > show (Plus a b) = (show a) ++ " Plus " ++ (show b)
> >
> > instance Eq t => Eq (Obs t) where
> > a `Equal` b == c `Equal` d = (a == c) && (b == d)
> > a `Plus` b == c `Plus` d = (a == c) && (b == d)
>
> The Equal constructor causes me problems, while the Plus is fine:
>
> test3.lhs:8:26:
> Could not deduce (Show a) from the context (t ~ Bool)
>   arising from a use of `show' at test3.lhs:8:26-31
> Possible fix:
>   add (Show a) to the context of the constructor `Equal'
> In the first argument of `(++)', namely `(show a)'
> In the expression: (show a) ++ " Equal " ++ (show b)
> In the definition of `show':
> show (Equal a b) = (show a) ++ " Equal " ++ (show b)
>
>
> I guess this is because GADT refines type with pattern matching.
> Since Equal return type is Obs Bool and not Obs a, it cannot bind the
> type variable a to belong to Show.

Right. You can have

(+ 3) `Equal` sin :: Obs Bool

, but how would you show it?

You could add a (Show a) constraint to Equal.

>
> I don't see how to precise the type in the pattern match.
>
> I have another problem:
>
> test3.lhs:12:41:
> Couldn't match expected type `a' against inferred type `a1'
>   `a' is a rigid type variable bound by
>   the constructor `Equal' at test3.lhs:12:8
>   `a1' is a rigid type variable bound by
>the constructor `Equal' at test3.lhs:12:23
>   Expected type: Obs a
>   Inferred type: Obs a1
> In the second argument of `(==)', namely `c'
> In the first argument of `(&&)', namely `(a == c)'

((+ 3) `Equal` sin) == (True `Equal` False)

Doesn't work.

And you can't make it work, because in

(a `Equal` b) == (c `Equal` d)

, a and b have the same type t1, and c and d have the same type t2 but the 
two types t1 and t2 are generally different, so calling (==) on a and c has 
no chance to type-check. With Equal forgetting the type parameter of its 
arguments, I don't think it's possible.

>
>
> Cheers,
> Corentin

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

Re: [Haskell-cafe] A Finally Tagless Pi Calculus

[Dan Doel]

On Wednesday 09 June 2010 2:32:29 pm Dupont Corentin wrote:
> I am making a little GATD:
> > {-# LANGUAGE GADTs#-}
> > 
> > data Obs a where
> > 
> > Equal :: Obs a -> Obs a -> Obs Bool
> > Plus :: (Num a) => Obs a -> Obs a -> Obs a
> 
> (etc..)
> 
> > instance Show t => Show (Obs t) where
> > 
> > show (Equal a b) = (show a) ++ " Equal " ++ (show b)
> > show (Plus a b) = (show a) ++ " Plus " ++ (show b)
> > 
> > instance Eq t => Eq (Obs t) where
> > 
> > a `Equal` b == c `Equal` d = (a == c) && (b == d)
> > a `Plus` b == c `Plus` d = (a == c) && (b == d)

Your two symptoms have the same underlying cause. The 'a' in Equal is 
existentially quantified. It might help to think about bundling the type in 
the Equal constructor:

  Equal T x y :: Obs Bool
   where
   T :: *
   x :: Obs T
   y :: Obs T

Now we write:

  show (Equal T x y) = ...

but we have no evidence that (Show T), so we cannot conclude (Show (Obs T)), 
and thus cannot use show on x and y.

Similarly:

  Equal T x y == Equal T' x y = ...

Your definition assumes that T = T' (or, it assumes that Obs T = Obs T', but 
that reduces to T = T'), but we have no reason to suspect that is the case. 
Hence the mismatch.

The first can be solved by putting a Show constraint on the type of the Equal 
constructor, if that's what you really want. The second can probably only be 
solved by having Equal take some kind of type rep, and checking that the types 
are equal.

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

[Haskell-cafe] GATD and pattern matching

[Dupont Corentin]

Hello,
I am making a little GATD:

> {-# LANGUAGE GADTs#-}

> data Obs a where
> Equal :: Obs a -> Obs a -> Obs Bool
> Plus :: (Num a) => Obs a -> Obs a -> Obs a
(etc..)

> instance Show t => Show (Obs t) where
> show (Equal a b) = (show a) ++ " Equal " ++ (show b)
> show (Plus a b) = (show a) ++ " Plus " ++ (show b)

> instance Eq t => Eq (Obs t) where
> a `Equal` b == c `Equal` d = (a == c) && (b == d)
> a `Plus` b == c `Plus` d = (a == c) && (b == d)


The Equal constructor causes me problems, while the Plus is fine:

test3.lhs:8:26:
Could not deduce (Show a) from the context (t ~ Bool)
  arising from a use of `show' at test3.lhs:8:26-31
Possible fix:
  add (Show a) to the context of the constructor `Equal'
In the first argument of `(++)', namely `(show a)'
In the expression: (show a) ++ " Equal " ++ (show b)
In the definition of `show':
show (Equal a b) = (show a) ++ " Equal " ++ (show b)


I guess this is because GADT refines type with pattern matching.
Since Equal return type is Obs Bool and not Obs a, it cannot bind the type
variable a to belong to Show.

I don't see how to precise the type in the pattern match.

I have another problem:

test3.lhs:12:41:
Couldn't match expected type `a' against inferred type `a1'
  `a' is a rigid type variable bound by
  the constructor `Equal' at test3.lhs:12:8
  `a1' is a rigid type variable bound by
   the constructor `Equal' at test3.lhs:12:23
  Expected type: Obs a
  Inferred type: Obs a1
In the second argument of `(==)', namely `c'
In the first argument of `(&&)', namely `(a == c)'


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

Re: [Haskell-cafe] How to "Show" an Operation?

[Martin Drautzburg]

On Monday, 7. June 2010 23:28:08 Evan Laforge wrote:

> I just meant you could add instances:
>
> instance Functor (Named a) where fmap f named = named { val_of = f
> (val_of named) }
> instance Applicative (Named a) where ... likewise, but maybe not a
> great fit unless you have a "no name" for 'pure'

So far so good. However my "Named" things are all functions and I don't see I 
ever want to map over any of them. But what I'd like to do is use them like 
ordinary functions as in:

f::Named (Int->Int)
f x

Is there a way to do this, other than writing

apply::Named Int ->Int
apply n x = (val_of n) x


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

Re: [Haskell-cafe] A Finally Tagless Pi Calculus

[Dupont Corentin]

Hello,
I am making a little GATD:

> {-# LANGUAGE GADTs#-}

> data Obs a where
> Equal :: Obs a -> Obs a -> Obs Bool
> Plus :: (Num a) => Obs a -> Obs a -> Obs a
(etc..)

> instance Show t => Show (Obs t) where
> show (Equal a b) = (show a) ++ " Equal " ++ (show b)
> show (Plus a b) = (show a) ++ " Plus " ++ (show b)

> instance Eq t => Eq (Obs t) where
> a `Equal` b == c `Equal` d = (a == c) && (b == d)
> a `Plus` b == c `Plus` d = (a == c) && (b == d)


The Equal constructor causes me problems, while the Plus is fine:

test3.lhs:8:26:
Could not deduce (Show a) from the context (t ~ Bool)
  arising from a use of `show' at test3.lhs:8:26-31
Possible fix:
  add (Show a) to the context of the constructor `Equal'
In the first argument of `(++)', namely `(show a)'
In the expression: (show a) ++ " Equal " ++ (show b)
In the definition of `show':
show (Equal a b) = (show a) ++ " Equal " ++ (show b)


I guess this is because GADT refines type with pattern matching.
Since Equal return type is Obs Bool and not Obs a, it cannot bind the type
variable a to belong to Show.

I don't see how to precise the type in the pattern match.

I have another problem:

test3.lhs:12:41:
Couldn't match expected type `a' against inferred type `a1'
  `a' is a rigid type variable bound by
  the constructor `Equal' at test3.lhs:12:8
  `a1' is a rigid type variable bound by
   the constructor `Equal' at test3.lhs:12:23
  Expected type: Obs a
  Inferred type: Obs a1
In the second argument of `(==)', namely `c'
In the first argument of `(&&)', namely `(a == c)'


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

[Haskell-cafe] Re: Stone age programming for space age hardware?

[Heinrich Apfelmus]

Michael Schuerig wrote:
> Heinrich Apfelmus wrote:
>>
>> I have absolutely no experience with real time system, but if I were
>> tasked to write with these coding standards, I would refuse and
>> instead create a small DSL in Haskell that compiles to the requested
>> subset of C.
> 
> That suggestion is similar to the approach taken by "verifiable" 
> languages, as Matthias describes it in a parallel reply.
> 
> Now, the interesting question is, whether it is possible to define a DSL 
> that's expressive enough and still can be translated to a very 
> restrictive subset of C. I wouldn't expect the on-board functionality of 
> a space probe or rover to be trivial.
> 
> I think it would count as cheating if you compile down a DSL to C code 
> that only takes a fixed chunk of memory, but then itself manages blocks 
> of that memory dynamically.

Ah, I had in mind that the embedded DSL represents the target subset of
C verbatim, very much in the spirit of Lennart Augustsson's
reimplementation of BASIC

   http://tinyurl.com/augustss-BASIC
   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/BASIC

In other words, I'm thinking of a direct copy of the target language in
Haskell.


This way, you can use the type system to reject programs that don't
adhere to the coding standards, which would be the main point of this
embedding.

But you get a huge benefit on top of that: Haskell now serves as a macro
language and you can implement many abstractions that are not directly
available in the target language, like custom control structures
("foreach") or exceptions (to organize these abundant checks for error
conditions).

Of course, the main goal of the NASA restrictions is to make the code so
simple that it has no obvious deficiencies, but what better way is there
to do that than finding and expressing - even small-scale -
abstractions? (The  foreach  statement seems to be a convincing example.)

> As I understood Holzmann in his talk, use of C is a kind of cultural 
> heritage at JPL.

Ah well, the shackles of habit... In the matter of program design, I am
unconvinced of any cultural heritage that is not based on the
mathematical clarity of Edsger W. Dijkstra. ;)

> BTW, thanks for your recent video on GADTs.

My pleasure. :) I'm already planning another video experiment.


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

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

[Haskell-cafe] A Finally Tagless Pi Calculus

[Edward Kmett]

Keegan McAllister gave a very nice talk at Boston Haskell last night about
"First Class Concurrency". His slides are available online at

http://t0rch.org/

His final few slides covered the Pi calculus:

http://en.wikipedia.org/wiki/Pi_calculus

I took a few minutes over lunch to dash out a finally tagless version of the
pi calculus interpreter presented by Keegan, since the topic of how much
nicer it would look in HOAS came up during the meeting.

For more information on finally tagless encodings, see:

http://www.cs.rutgers.edu/~ccshan/tagless/jfp.pdf

Of course, Keegan went farther and defined an encoding of the lambda
calculus into the pi calculus, but I leave that as an exercise for the
reader. ;)

-Edward Kmett

> {-# LANGUAGE Rank2Types, TypeFamilies, FlexibleInstances #-}
> module Pi where

> import Control.Applicative
> import Control.Concurrent

A finally tagless encoding of the Pi calculus. Symantics is a portmanteau of
Syntax and Semantics.

> class Symantics p where
> type Name p :: *
> new :: (Name p -> p) -> p
> out :: Name p -> Name p -> p -> p
> (|||) :: p -> p -> p
> inn :: Name p -> (Name p -> p) -> p
> rep :: p -> p
> nil :: p
> embed :: IO () -> p

Type level fixed points

> newtype Nu f = Nu { nu :: f (Nu f) }

> fork :: IO () -> IO ()
> fork a = forkIO a >> return ()

> forever :: IO a -> IO a
> forever p = p >> forever p

Executable semantics

> instance Symantics (IO ()) where
> type Name (IO ()) = Nu Chan
> new f = Nu <$> newChan >>= f
> a ||| b = forkIO a >> fork b
> inn (Nu x) f = readChan x >>= fork . f
> out (Nu x) y b = writeChan x y >> b
> rep = forever
> nil = return ()
> embed = id

A closed pi calculus term

> newtype Pi = Pi { runPi :: forall a. Symantics a => a }

> run :: Pi -> IO ()
> run (Pi a) = a

> example = Pi (new $ \z -> (new $ \x -> out x z nil
>||| (inn x $ \y -> out y x $ inn x $ \
y -> nil))
>   ||| inn z (\v -> out v v nil))

A pretty printer for the pi calculus

> newtype Pretty = Pretty { runPretty :: [String] -> Int -> ShowS }
>
> instance Symantics Pretty where
> type Name Pretty = String
> new f = Pretty $ \(v:vs) n ->
> showParen (n > 10) $
> showString "nu " . showString v . showString ". " .
> runPretty (f v) vs 10
> out x y b = Pretty $ \vs n ->
> showParen (n > 10) $
> showString x . showChar '<' . showString y . showString ">. "
.
> runPretty b vs 10
> inn x f = Pretty $ \(v:vs) n ->
> showParen (n > 10) $
> showString x . showChar '(' . showString v . showString "). "
.
> runPretty (f v) vs 10
> p ||| q = Pretty $ \vs n ->
> showParen (n > 4) $
> runPretty p vs 5 .
> showString " | " .
> runPretty q vs 4
> rep p = Pretty $ \vs n ->
> showParen (n > 10) $
> showString "!" .
> runPretty p vs 10
> nil = Pretty $ \_ _ -> showChar '0'
> embed io = Pretty $ \_ _ -> showString "{IO}"

> instance Show Pi where
> showsPrec n (Pi p) = runPretty p vars n
> where
> vars = fmap return vs ++
>[i : show j | j <- [1..], i <- vs] where
> vs = ['a'..'z']

Pi> example
nu a. (nu b. (b. 0 | b(c). c. b(d). 0) | a(b). b. 0)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] cabal problem on OS X

[Gregory Collins]

Jeroen Weijers  writes:

> Hi,
>
> For me it turned out to be some problem with MacPorts, removing
> MacPorts (with all its installed ports) solved the problem regarding
> ZLib. I assume that a less drastic measure would also work (only
> remove selected ports or remove the ports from your path).

This specific error happens when you try to link with a 64-bit library
from 32-bit GHC. So the odds are good either your flags aren't set right
in /usr/bin/ghc and friends (which was an issue on 6.10), or you're
linking to a non-universal copy of zlib (like the one macports will
build).

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

Re: [Haskell-cafe] strange errors with unix-compat

[Brandon S. Allbery KF8NH]

On Jun 8, 2010, at 19:52 , Günther Schmidt wrote:
4 of 4] Compiling System.PosixCompat.Extensions ( dist/build/System/ 
PosixCompat/Extensions.hs, dist/build/System/PosixCompat/ 
Extensions.o )

cbits/HsUnixCompat.c: In function `unix_major':

cbits/HsUnixCompat.c:4:0:
warning: implicit declaration of function `major'
cbits/HsUnixCompat.c: In function `unix_minor':

cbits/HsUnixCompat.c:8:0:
warning: implicit declaration of function `minor'
cbits/HsUnixCompat.c: In function `unix_makedev':

cbits/HsUnixCompat.c:12:0:
warning: implicit declaration of function `makedev'



You're missing an include file somehow; those are macros that pack and  
unpack an st_rdev.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Monadic presentation of delimited continuations and dissection

[Greg Meredith]

Dear Haskellians,

After reading through the Dybvig, Jones and Sabry paper on the monadic
presentation of delimited continuations, it seems like one can come up with
a direct representation of the control contexts and meta continuations
framework as an instance of McBride's dissection mechanism. Do either of you
know if that work has already been done? McBride doesn't use that as an
example in his Clowns and Jokers paper.

Best wishes,

--greg

-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

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

RE: [Haskell-cafe] HP/Cygwin and Curl

[Chris Dornan]

Thanks very much Claus and Malcolm.

You have clarified the situation nicely: I was beginning to suspect my
Cygwin setup and I bet that is where the problem lies.

I won't have time to straighten my Cygwin environment this week, but when I
do I will come back here and explain what went wrong (I have seen evidence
of others stumbling on this giving rise to speculative misinformation).

Sorry for the confusion!

Chris

-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Malcolm Wallace
Sent: 08 June 2010 22:06
To: haskell-cafe Cafe
Subject: Re: [Haskell-cafe] HP/Cygwin and Curl

> with Cygwin I get
>
>Linking dist\build\cmu\cmu.exe ...
>   C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin
> \windres:
> can't open temporary file `\/cca04932.irc': No such file or directory

This sounds very much like a temporary-filename issue.  The reported
filename's lack of a valid directory specifier looks highly suspicious to
me.  Are your TEMP, TEMPDIR, TMP, and TMPDIR environment variables set? Are
their values sensible?  Do you have appropriate permissions on the
directories they point to?  These are the kinds of thing I usually need to
check when setting up a new Cygwin build environment.

Admittedly, we do not use cabal on Windows (firewall prevents it from
working), but the other ghc tools generally seem to work without problems
for us under Cygwin.

Regards,
 Malcolm

___
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: Rewriting a famous library and using the same name: pros and consf

[Stephen Tetley]

Hi John

My feeling is that a beginner would be transferring almost all of the
the knowledge they gained from Parsec 2.1 if they moved to Parsec 3.0.
We're talking about "famous" libraries, so the library was previously
valuable and useful before the "discontinuous" version change.

In Parsec 3.0's case the discontinuous change revised the parser type
(Parser -> ParserT), the hierarchy for importing modules and where you
find the run functions. These are almost insignificant when an
experienced user wants to move their code from 2.1 to 3.0, but they
may well be significant hurdles for a Haskell beginner working from
examples written with 2.1 (there are no examples in the Parsec 3.0
distribution) or working through the manual.

Daan Leijen's Parsec manual, the QuickCheck paper, Paul Hudak's
Haskore tutorial were all "authored" - it would seem inappropriate to
update them. Of course, a revised project could supply a commentary on
the original documentation - "Parsec - Cliff's notes", detailing where
the differences are, but in practice they don't vis my point that
libraries advance ahead of their documentation.

Best wishes

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

Re: [Haskell-cafe] Re: Stone age programming for space age hardware?

[Matthias Guedemann]

> Perhaps it's just my lack of imagination that was driving my original 
> question. I'm just having a hard time imagining how to write reasonably 
> interesting algorithms that way.

Very likely they have very specific functionality and hopefully a precise
specification about what to do if the memory bounds are reached (at least some
"failsafe" mode etc.) Many of these programs are very simple, but deliberately
so.
 
> As I wrote, they might "cheat". It's entirely possible to implement 
> dynamic memory on top of fixed-size arrays and use indexes instead of 
> pointers. Of course, I have no idea if that's what they do.

I think it is very likely done that way. I know this kind of programming from
Java-smartcards. These support a subset of Java and allow the creation of 
objects
only when installing a program on the card. There is no garbage collection,
objects are persistent, i.e. creating new objects at runtime would fill up the
available (very low) memory. "Dynamic" creation is done by reusing one "freed"
object of the statically allocated ones or returning an error if no free object
is available. 

Systems in high security or safety applications and those with properties like
very low memory, very slow CPUs etc. often have requirements that makes direct
usage of languages like Haskell very difficult or impossible. They are
programmed in a way that makes their behavior as deterministic as possible,
often also from the temporal view. If you have dynamic data structures with
non-O(1) access it is also not possible to guarantee RT bounds.

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