Re: [Haskell-cafe] RFC: rewrite-with-location proposal
Hi Michael, On Mon, Feb 25, 2013 at 02:41:19PM +0200, Michael Snoyman wrote: At that point, we've now made two changes to REWRITE rules: 1. They can takes a new ALWAYS parameters. 2. There's a new, special identifier currentLocation available. What would be the advantage is of that approach versus introducing a single new REWRITE_WITH_LOCATION pragma? The name REWRITE_WITH_LOCATION could indicate that it's just a REWRITE with an additional location, but not that it's used by the compiler in a different way. Perhaps using just another word instead of REWRITE could indicate the difference of application. Greetings, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conflicting bindings legal?!
To your amusement, I found the following in the Agda source:
abstractToConcreteCtx :: ToConcrete a c = Precedence - a - TCM c
abstractToConcreteCtx ctx x = do
scope - getScope
let scope' = scope { scopePrecedence = ctx }
return $ abstractToConcrete (makeEnv scope') x
where
scope = (currentScope defaultEnv) { scopePrecedence = ctx }
I am surprised this is a legal form of shadowing. To understand which
definition of 'scope' shadows the other, I have to consult the formal
definition of Haskell.
But I studied computer science to *not* become a lawyer!!
--
Andreas AbelDu bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conflicting bindings legal?!
Luckily, {-# OPTIONS -fwarn-unused-binds #-} saves me from searching for
the formal spec...
On 26.02.13 10:25 AM, Andreas Abel wrote:
To your amusement, I found the following in the Agda source:
abstractToConcreteCtx :: ToConcrete a c = Precedence - a - TCM c
abstractToConcreteCtx ctx x = do
scope - getScope
let scope' = scope { scopePrecedence = ctx }
return $ abstractToConcrete (makeEnv scope') x
where
scope = (currentScope defaultEnv) { scopePrecedence = ctx }
I am surprised this is a legal form of shadowing. To understand which
definition of 'scope' shadows the other, I have to consult the formal
definition of Haskell.
But I studied computer science to *not* become a lawyer!!
--
Andreas AbelDu bist der geliebte Mensch.
Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY
andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conflicting bindings legal?!
Hi,
Am Dienstag, den 26.02.2013, 10:25 +0100 schrieb Andreas Abel:
To your amusement, I found the following in the Agda source:
abstractToConcreteCtx :: ToConcrete a c = Precedence - a - TCM c
abstractToConcreteCtx ctx x = do
scope - getScope
let scope' = scope { scopePrecedence = ctx }
return $ abstractToConcrete (makeEnv scope') x
where
scope = (currentScope defaultEnv) { scopePrecedence = ctx }
I am surprised this is a legal form of shadowing. To understand which
definition of 'scope' shadows the other, I have to consult the formal
definition of Haskell.
in more imperative looking Haskell code, I find it useful to shadow a
previous binding by a new foo - binding... People who do not like
that should use -Wall (or a more specific flag like
-fwarn-name-shadowing).
Greetings,
Joachim
--
Joachim nomeata Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
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] Conflicting bindings legal?!
Hi,
Andreas Abel wrote:
To your amusement, I found the following in the Agda source:
abstractToConcreteCtx :: ToConcrete a c = Precedence - a - TCM c
abstractToConcreteCtx ctx x = do
scope - getScope
let scope' = scope { scopePrecedence = ctx }
return $ abstractToConcrete (makeEnv scope') x
where
scope = (currentScope defaultEnv) { scopePrecedence = ctx }
I am surprised this is a legal form of shadowing. To understand which
definition of 'scope' shadows the other, I have to consult the formal
definition of Haskell.
Isn't this just an instance of the following, more general rule:
To understand what a piece of code means, I have to consult the formal
definition of the language the code is written in.
In the case you cite, you just have to desugar the do notation
abstractToConcreteCtx :: ToConcrete a c = Precedence - a - TCM c
abstractToConcreteCtx ctx x =
getScope = (\scope -
let scope' = scope { scopePrecedence = ctx } in
return $ abstractToConcrete (makeEnv scope') x)
where
scope = (currentScope defaultEnv) { scopePrecedence = ctx }
and it becomes clear by the nesting structure that the lambda-binding
shadows the where-binding. It seems that if you argue against this case,
you argue against shadowing in general. Should we adopt the Barendregt
convention as a style guide for programming?
Tillmann
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Thunks and GHC pessimisation
Tom Ellis wrote: To avoid retaining a large lazy data structure in memory it is useful to hide it behind a function call. Below, many is used twice. It is hidden behind a function call so it can be garbage collected between uses. As you discovered, it is quite challenging to ``go against the grain'' and force recomputation. GHC is quite good at avoiding recomputation. This is a trade-off, of time vs space. For large search tree, it is space that is a premium, and laziness and similar strategies are exactly the wrong trade-off. The solution (which I've seen in some of the internal library code) is to confuse GHC with extra functions: http://okmij.org/ftp/Haskell/misc.html#memo-off So, eventually it is possible to force recomputation. But the solution leaves a poor taste -- fighting a compiler is never a good idea. So, this is a bug of sort -- not the bug of GHC, but of lazy evaluation. Lazy evaluation is not the best evaluation strategy. It is a trade-off, which suits a large class of problems and punishes another large class of problems. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: rewrite-with-location proposal
Do you mean that the proposal itself won't work, or specifically implementing
this features in terms of existing rewrite rules won't work?
I meant the latter.
I'll admit to ignorance on the internals of GHC, but it seems like doing the
shallow source location approach would be far simpler than a full trace. I'd
hate to lose a very valuable feature because we can't implement the perfect
feature.
I agree with that sentiment. But in fact I suspect that getting a stack is
little or no harder than the shallow thing.
My implicit parameter suggestion was trying to re-use an existing feature,
with a small twist, to do what you want, rather than to implement something
brand new.
Simon
From: michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] On Behalf Of
Michael Snoyman
Sent: 25 February 2013 18:19
To: Simon Peyton-Jones
Cc: Alexander Kjeldaas; Simon Hengel; Haskell Cafe
Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal
On Mon, Feb 25, 2013 at 4:42 PM, Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com wrote:
I'm afraid the rewrite-rule idea won't work. RULES are applied during
optimisation, when tons of inlining has happened and the program has been
shaken around a lot. No reliable source location information is available there.
Do you mean that the proposal itself won't work, or specifically implementing
this features in terms of existing rewrite rules won't work?
See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and please edit
it.
One thing I'd disagree with on that page is point (3). While it's certainly
nice to have a full stack trace, implementing just shallow call information is
incredibly useful. For logging and test framework usages, it in fact completely
covers the use case. And even for debugging, I think it would be a massive step
in the right direction.
I'll admit to ignorance on the internals of GHC, but it seems like doing the
shallow source location approach would be far simpler than a full trace. I'd
hate to lose a very valuable feature because we can't implement the perfect
feature.
One idea I had, which that page does not yet describe, is to have an implicit
parameter,
something like ?loc::Location, with
errLoc :: ?loc:Location = String - a
errLoc s = error (At ++ ?loc ++ \n ++ s)
This behave exactly like an ordinary implicit parameter, EXCEPT that if there
is no binding for ?loc::Location, then the current location is used. Thus
myErr :: ?loc:Location = Int - a
myErr n = errLoc (show n)
foo :: Int - int
foo n | n0 = myErr n
| otherwise = ...whatever...
When typechecking 'foo' we need ?loc:Location, and so the magic is that we use
the location of the call of myErr in foo.
Simon
From: haskell-cafe-boun...@haskell.orgmailto:haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.orgmailto:haskell-cafe-boun...@haskell.org]
On Behalf Of Alexander Kjeldaas
Sent: 25 February 2013 12:16
To: Simon Hengel
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal
On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel
s...@typeful.netmailto:s...@typeful.net wrote:
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
I think there is no need to have a separate REWRITE_WITH_LOCATION
rule. What if the compiler instead rewrites 'currentLocation' to the
current location? Then you'd just define the rule:
{-# REWRITE errorLoc error = errorLoc currentLocation #-}
REWRITE rules are only enabled with -O. Source locations are also
useful during development (when you care more about compilation time
than efficient code and hence use -O0). So I'm not sure whether it's a
good idea to lump those two things together.
I could imagine that source locations being useful when debugging rewrite rules
for example.
I think your argument makes sense, but why not fix that specifically?
{-# REWRITE ALWAYS errorLoc error = errorLoc currentLocation #-}
Alexander
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.orgmailto: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] RFC: rewrite-with-location proposal
On Tue, Feb 26, 2013 at 12:06 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Do you mean that the proposal itself won't work, or specifically
implementing this features in terms of existing rewrite rules won't work?*
***
** **
I meant the latter.
** **
I'll admit to ignorance on the internals of GHC, but it seems like doing
the shallow source location approach would be far simpler than a full
trace. I'd hate to lose a very valuable feature because we can't implement
the perfect feature.
** **
I agree with that sentiment. But in fact I suspect that getting a stack is
little or no harder than the shallow thing.
** **
My “implicit parameter” suggestion was trying to re-use an existing
feature, with a small twist, to do what you want, rather than to implement
something brand new.
I personally have very little opinion about how this feature is
implemented. But would this approach implement the shallow trace, or the
full stack trace?
Michael
Simon
** **
*From:* michael.snoy...@gmail.com [mailto:michael.snoy...@gmail.com] *On
Behalf Of *Michael Snoyman
*Sent:* 25 February 2013 18:19
*To:* Simon Peyton-Jones
*Cc:* Alexander Kjeldaas; Simon Hengel; Haskell Cafe
*Subject:* Re: [Haskell-cafe] RFC: rewrite-with-location proposal
** **
** **
** **
On Mon, Feb 25, 2013 at 4:42 PM, Simon Peyton-Jones simo...@microsoft.com
wrote:
I’m afraid the rewrite-rule idea won’t work. RULES are applied during
optimisation, when tons of inlining has happened and the program has been
shaken around a lot. No reliable source location information is available
there.
** **
Do you mean that the proposal itself won't work, or specifically
implementing this features in terms of existing rewrite rules won't work?*
***
See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and
please edit it.
** **
One thing I'd disagree with on that page is point (3). While it's
certainly nice to have a full stack trace, implementing just shallow call
information is incredibly useful. For logging and test framework usages, it
in fact completely covers the use case. And even for debugging, I think it
would be a massive step in the right direction.
** **
I'll admit to ignorance on the internals of GHC, but it seems like doing
the shallow source location approach would be far simpler than a full
trace. I'd hate to lose a very valuable feature because we can't implement
the perfect feature.
One idea I had, which that page does not yet describe, is to have an
implicit parameter,
something like ?loc::Location, with
errLoc :: ?loc:Location = String - a
errLoc s = error (“At “ ++ ?loc ++ “\n” ++ s)
This behave exactly like an ordinary implicit parameter, EXCEPT that if
there is no binding for ?loc::Location, then the current location is used.
Thus
myErr :: ?loc:Location = Int - a
myErr n = errLoc (show n)
foo :: Int - int
foo n | n0 = myErr n
| otherwise = ...whatever...
When typechecking ‘foo’ we need ?loc:Location, and so the magic is that we
use the location of the call of myErr in foo.
Simon
*From:* haskell-cafe-boun...@haskell.org [mailto:
haskell-cafe-boun...@haskell.org] *On Behalf Of *Alexander Kjeldaas
*Sent:* 25 February 2013 12:16
*To:* Simon Hengel
*Cc:* Haskell Cafe
*Subject:* Re: [Haskell-cafe] RFC: rewrite-with-location proposal
On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel s...@typeful.net wrote:***
*
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
I think there is no need to have a separate REWRITE_WITH_LOCATION
rule. What if the compiler instead rewrites 'currentLocation' to the
current location? Then you'd just define the rule:
{-# REWRITE errorLoc error = errorLoc currentLocation #-}
REWRITE rules are only enabled with -O. Source locations are also
useful during development (when you care more about compilation time
than efficient code and hence use -O0). So I'm not sure whether it's a
good idea to lump those two things together.
I could imagine that source locations being useful when debugging rewrite
rules for example.
I think your argument makes sense, but why not fix that specifically?
{-# REWRITE ALWAYS errorLoc error = errorLoc currentLocation #-}
Alexander
___
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] RFC: rewrite-with-location proposal
On 2/25/13 9:42 AM, Simon Peyton-Jones wrote: I'm afraid the rewrite-rule idea won't work. RULES are applied during optimisation, when tons of inlining has happened and the program has been shaken around a lot. No reliable source location information is available there. See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and please edit it. One idea I had, which that page does not yet describe, is to have an implicit parameter, something like ?loc::Location, with errLoc :: ?loc:Location = String - a errLoc s = error (At ++ ?loc ++ \n ++ s) This behave exactly like an ordinary implicit parameter, EXCEPT that if there is no binding for ?loc::Location, then the current location is used. Thus I like the general approach of this proposal quite a bit. I'd very much like Location to be not just a string, but a record type. Ideally we could recover not just module name, line and character, but also the name of the function that takes the location. This would eliminate an entire swath of use-cases for Template Haskell. For example, I've worked out a template-haskell-free version of the Cloud Haskell closure API, which hopefully is getting merged in at some point. The major drawback it has is that the user is required to provide a globally-unique identifier for each closure, ideally stable across compilations. The current TH code solves this by grabbing the function and module name. If we could get direct access to these things without requiring template haskell, that would be quite nice. Other types of RPC libraries I've worked on could similarly benefit from this. Cheers, Gershom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parser left recursion
On Sunday, 24. February 2013 16:04:11 Tillmann Rendel wrote: Both approaches are essentially equivalent, of course: Before considering the very same nonterminal again, we should have consumed at least one token. I see. Thanks So for the laymen: expr ::= expr + expr is a problem, because the parser considers expr again without having consumed any input. expr ::= literal pluses pluses ::= many (+ expr) is not a problem, because by the time the parser gets to the rightmost expr is has consumes at least one +. Instead of literal we can put anything which promises not to be left-recursive expr ::= exprNonLr + expr exprNonLr := ... As exprNonLr gets more complicated, we may end up with a whole set of nonLr parsers. I wonder if I can enforce the nonNr property somehow, i.e. enforce the rule will not consider the same nonterminal again without having consumed any input. -- Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parser left recursion
2013/2/26 Martin Drautzburg martin.drautzb...@web.de: I wonder if I can enforce the nonNr property somehow, i.e. enforce the rule will not consider the same nonterminal again without having consumed any input. You might be interested in this paper: Danielsson, Nils Anders. Total parser combinators. ACM Sigplan Notices. Vol. 45. No. 9. ACM, 2010. Regards, Dominique ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thunks and GHC pessimisation
On Tue, Feb 26, 2013 at 10:00:32AM -, o...@okmij.org wrote: Tom Ellis wrote: To avoid retaining a large lazy data structure in memory it is useful to hide it behind a function call. Below, many is used twice. It is hidden behind a function call so it can be garbage collected between uses. As you discovered, it is quite challenging to ``go against the grain'' and force recomputation. GHC is quite good at avoiding recomputation. This is a trade-off, of time vs space. For large search tree, it is space that is a premium, and laziness and similar strategies are exactly the wrong trade-off. Hi Oleg, I have good news: Don's suggestion of -fno-full-laziness that fixed the space leak in my toy example also fixes the space leak in your iterative deepening code. To be precise, there is no longer any space leak in your second implementation where subtrees are hidden behind a function call. With full laziness your second implementation consumes 99M. To avoid sharing hacks are required and your third implementation consumes 2M. However, without full laziness your second implementation only consumes 2M. The solution (which I've seen in some of the internal library code) is to confuse GHC with extra functions: http://okmij.org/ftp/Haskell/misc.html#memo-off Yes, when I read your exposition several months ago it started the thinking process which culminated in this thread. So, eventually it is possible to force recomputation. But the solution leaves a poor taste -- fighting a compiler is never a good idea. I agree, but I'm glad to discover that disabling full laziness is enough to avoid having to fight the compiler. So, this is a bug of sort -- not the bug of GHC, but of lazy evaluation. Lazy evaluation is not the best evaluation strategy. It is a trade-off, which suits a large class of problems and punishes another large class of problems. I'm not as pessimistic as you on this issue. If the results of function calls may be shared with previous callers then the situation is problematic. However, if it is known that function calls return new thunks then the programmer has a lot of power to avoid space leaks. My conclusion is that this is not the bug of lazy evalution. I would prefer GHC to be more discerning about when it applies full laziness. It is unfortunate that it will apply it in cases where unbounded amounts of additional memory usage may result. Tom % wget --quiet http://okmij.org/ftp/Haskell/STrees.hs % ghc -O2 -fforce-recomp -rtsopts -main-is STrees.main2 STrees.hs ./STrees iter 100 +RTS -tstderr /dev/null [1 of 1] Compiling STrees ( STrees.hs, STrees.o ) Linking STrees ... ghc: 159988256 bytes, 308 GCs, 12946822/42139812 avg/max bytes residency (10 samples), 99M in use, 0.00 INIT (0.00 elapsed), 8.40 MUT (8.40 elapsed), 0.95 GC (0.95 elapsed) :ghc % ghc -O2 -fforce-recomp -rtsopts -main-is STrees.main3 STrees.hs ./STrees iter 100 +RTS -tstderr /dev/null [1 of 1] Compiling STrees ( STrees.hs, STrees.o ) Linking STrees ... ghc: 6488675656 bytes, 12415 GCs, 214291/384036 avg/max bytes residency (37 samples), 2M in use, 0.00 INIT (0.00 elapsed), 8.64 MUT (8.64 elapsed), 0.32 GC (0.32 elapsed) :ghc % ghc -O2 -fno-full-laziness -fforce-recomp -rtsopts -main-is STrees.main2 STrees.hs ./STrees iter 100 +RTS -tstderr /dev/null [1 of 1] Compiling STrees ( STrees.hs, STrees.o ) Linking STrees ... ghc: 11235944260 bytes, 21510 GCs, 208262/456880 avg/max bytes residency (44 samples), 2M in use, 0.00 INIT (0.00 elapsed), 8.03 MUT (8.03 elapsed), 0.52 GC (0.52 elapsed) :ghc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules
Hello everybody! I am very happy to announce the beta release [1] of Nomyx, the only game where You can change the rules. This is an implementation of a Nomic [2] game in Haskell (I believe the first complete implementation). In a Nomyx game you can change the rules of the game itself while playing it. The players can submit new rules or modify existing ones, thus completely changing the behaviour of the game through time. The rules are managed and interpreted by the computer. They must be written in the Nomyx language, which is a subset of Haskell. At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! Here is a video introduction and first tutorial of the game: http://vimeo.com/58265498 The game is running here: www.nomyx.net:8000/Nomyx I have set up a forum where players can learn about Nomyx and discuss the rules they intend to propose: www.nomyx.net/forum As this is the first beta release of the game, I'm looking for beta testers :) Although I tested it quite a lot, I'm sure a lot of bugs remains, especially in multiplayer. So if you are interested in testing Nomyx, please go to this forum thread and we'll set up a small team to start a match! http://www.nomyx.net/forum/viewtopic.php?p=5 Comments/contributions are very highly welcome! There is still a lot to do. As for now, the game is not completely securised. It is easy to break it by submitting rules containing malicious code. I'm working on it. If you'd like to do security testing, please do it locally on your own machine and send me a bug report :). Cheers, Corentin [1] http://hackage.haskell.org/package/Nomyx [2] www.nomic.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules
On 27/02/2013, at 10:28 , Corentin Dupont corentin.dup...@gmail.com wrote: Hello everybody! I am very happy to announce the beta release [1] of Nomyx, the only game where You can change the rules. Don't forget 1KBWC: http://www.corngolem.com/1kbwc/ Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules
On Tue, Feb 26, 2013 at 3:28 PM, Corentin Dupont corentin.dup...@gmail.comwrote: Hello everybody! I am very happy to announce the beta release [1] of Nomyx, the only game where You can change the rules. This is an implementation of a Nomic [2] game in Haskell (I believe the first complete implementation). In a Nomyx game you can change the rules of the game itself while playing it. The players can submit new rules or modify existing ones, thus completely changing the behaviour of the game through time. The rules are managed and interpreted by the computer. They must be written in the Nomyx language, which is a subset of Haskell. That's very nice. I've been following your progress on the list. Congratulations! Did you learn as much about Haskell as you hoped? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package dependencies should distinguish between API and implementation?
On 13-02-25 06:50 AM, Johannes Waldmann wrote: or in general, A (and B.1) are baked into ghc, but there is some B.2/B.3 out there which U wants to use. Or is this what already happens? (ghc would notice that B.1.foo is different from B.2.foo. cabal-install would warn, but proceed? Then the effect of the proposal would just be to switch off these warnings in some cases?) GHC uses both versions of B as much as possible. If none of the following 3 problems occur, they co-exist peacefully. B defines a type T and/or a type class C. GHC considers B-1.T and B-2.T different and not interchangeable; similarly C. This is fine if one version is merely implementation-depended on. This becomes a visible type error if both versions are API-depended on and you try to mix them. You will see type errors like cannot match B-1.T with T or T is not an instance of B-1.C. (Because T refers to B-2's.) B-1 and B-2 both have instance Show (IO a) where Then you get some kind of overlapping instances error. B-1 and B-2 both contain C code, and both contain C extern functions of the same name (which is best practice) fps_count (real example from bytestring). Therefore, GHC cannot load both. (Neither can common linkers.) GHC panics in this case. Clearly, implementation-depend still suffers from 2 of these problems. As for cabal, it never considers multiple versions. Which I like. Just chop up the Gordian Knot. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Nomyx 0.1 beta, the game where you can change the rules
Hello everybody! I am very happy to announce the beta release [1] of Nomyx, the only game where You can change the rules. I just gave it a go -- it looks fun :) However, I've spotted a security hole. The current user number is stored in the URL -- if I change that number, I can masquerade as someone else! Is this behavior intended? This is an implementation of a Nomic [2] game in Haskell (I believe the first complete implementation). In a Nomyx game you can change the rules of the game itself while playing it. The players can submit new rules or modify existing ones, thus completely changing the behaviour of the game through time. The rules are managed and interpreted by the computer. They must be written in the Nomyx language, which is a subset of Haskell. At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! Here is a video introduction and first tutorial of the game: http://vimeo.com/58265498 The game is running here: www.nomyx.net:8000/Nomyx I have set up a forum where players can learn about Nomyx and discuss the rules they intend to propose: www.nomyx.net/forum As this is the first beta release of the game, I'm looking for beta testers :) Although I tested it quite a lot, I'm sure a lot of bugs remains, especially in multiplayer. So if you are interested in testing Nomyx, please go to this forum thread and we'll set up a small team to start a match! http://www.nomyx.net/forum/viewtopic.php?p=5 Comments/contributions are very highly welcome! There is still a lot to do. As for now, the game is not completely securised. It is easy to break it by submitting rules containing malicious code. I'm working on it. If you'd like to do security testing, please do it locally on your own machine and send me a bug report :). Cheers, Corentin [1] http://hackage.haskell.org/package/Nomyx [2] www.nomic.net ___ 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] derivatives and integrals
Hi. The scope of this question is likely bigger that Haskell, but this seems like the right crowd to ask. I'm in Calc II right now, and I'm looking for a FOSS desktop application (I use Gnu/Linux) to replace the functionality of my TI-98 in finding derivatives and integrals. (It's very convenient for double checking my own solutions.) I've heard of some software like Octave, but the manuals are usually very large, and I'm not sure what is the best one to start with. I was wondering if there is anyone on this list who uses free software to do that sort of simpler Calc stuff, and what it is that they use. -- frigidcode.com signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] derivatives and integrals
On Wed, Feb 27, 2013 at 3:24 PM, Christopher Howard christopher.how...@frigidcode.com wrote: I'm not sure what is the best one to start with. I was wondering if there is anyone on this list who uses free software to do that sort of simpler Calc stuff, and what it is that they use. Not sure about any Haskell-based systems, but I can recommend Sage, a Python-based mathematics software system, which includes Maxima: http://sagemath.org/ -- Carlo Hamalainen http://carlo-hamalainen.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC API wiki update
I was playing with the GHC api and found that examples on the GHC wiki don't seem to work with GHC 7.6.1. Does anybody have the updated examples of the same? Regards, Satvik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The state of binary (de)serialization
On Mon, Feb 25, 2013 at 01:30:40PM +0100, Nicolas Trangez wrote:
All,
In order to implement some network protocol clients recently, I needed
binary serialization of commands and deserialization of responses
('Command - ByteString' and 'ByteString - Response' functions,
preferably for both strict as well as lazy ByteStrings).
My go-to packages have always been 'binary' and 'cereal', but I was
wondering about the current (and future) state/goals:
- cereal supports chunk-based 'partial' parsing (runGetPartial). It
looks like support for this is introduced in recent versions of 'binary'
as well (runGetIncremental)
- cereal can output a strict bytestring (runPut) or a lazy one
(runPutLazy), whilst binary only outputs lazy ones (runPut)
- Next to binary and cereal, there's bytestring's Builder interface for
serialization, and Simon Meier's blaze-binary prototype
There are some blog posts and comments out there about merging cereal
and binary, is this what's the goal/going on (cfr runGetIncremental)?
In my use-case I think using Builder instead of binary/cereal's PutM
monad shouldn't be a major problem. Is this advisable performance-wise?
Overall: what's the advised future-proof strategy of handling binary
(de)serialization?
I've been looking at the same thing lately, and i've been quite surprised, to
say the least, by the usual go-to packages (cereal, binary). Performance wise
this is hard to summarize, but if you serialize something small and have a easy
to compute size (e.g. fixed size structure), i would advise against using any
kind of builder structure (builder,cereal,binary), and go directly at the
Storable level, if performance need to be on-par other languages.
My initial interpretation is that the builder initial cost is quite high, and
only get amortized if the number of operations is quite high (and have less
bytestrings). So if you have many structures encoded in one encoding operation
it's probably ok-ish.
I've made the following benchmark when i was doing my experiments,
that shows basic serialization of bytestring-y data structures:
* bclass is a simple function that use bytestring concat or append
* bclass+io is a simple function that use mutable bytestring + poke to create
the bytestring
* cereal is cereal's encode function
* binary is binary's encode function
* builder is bytestring's builder.
* simple bytestring of constant size: sz
* n bytestrings of same size: n*sz
* n bytestrings of different size: sz+sz2+..
* n bytestrings plus a w32 prefixed size: len+n*sz
Obviously, caveat emptor:
http://tab.snarc.org/others/benchmark-bytestring-serialization.html
Let me know if anyone want the source file.
--
Vincent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] tplot (out of memory)
Hi folks, Just thought it might be helpful to close this issue. Haskell tplot out of memory on centos ep6 was indeed related to the font issue. As Malcolm pointed out, installing x11 fonts resolved the issue. This yum install worked for me yum install xorg-x11-font*. Thanks, Manish On Fri, Nov 30, 2012 at 11:29 AM, Eugene Kirpichov ekirpic...@gmail.comwrote: Hi, Wow, that's weird. I wonder what kinds of fonts were missing? I was just using the default cairo font everywhere. On Fri, Nov 30, 2012 at 11:27 PM, Malcolm Wallace malcolm.wall...@me.comwrote: For the record, it turned out that the key difference between the linux machines was the fonts packages installed via RPM. The strace utility told me that the crash happened shortly after cairo/pango attempted (and failed) to open some font configuration files. After installing some of the X11 font packages (and some others too), the crash went away. On 18 Oct 2012, at 09:55, malcolm.wallace wrote: Did you ever solve this? I have a similar message ( user error (out of memory) ) arising from a different app (not tplot) that uses the Haskell Chart library (and cairo underneath). On some linux machines, it crashes, on others it works fine. I can find no environment differences between the machines. The app does not use a lot of memory, and the machine is not running out of physical or swap. Regards, Malcolm On 04 Sep, 2012,at 04:01 PM, Eugene Kirpichov ekirpic...@gmail.com wrote: Hi Manish, Please provide the input file, I'll debug this. On Mon, Sep 3, 2012 at 1:06 PM, Manish Trivedi trivman...@gmail.com wrote: Hi, I am running into a weird out of memory issue. While running timeplot over an input file having ~800 rows. From below provided info, seems like machine has enough ram (1849MB). Please let me know if anyone has pointers. # free -m total used free shared buffers cached Mem: 3825 1975 1849 0 13 71 -/+ buffers/cache: 1891 1934 Swap: 4031 111 3920 #time tplot -o out.png -or 1024x768 -k 'CurrentPerHour' 'lines' -k 'RequiredPerHour' 'lines' -if adgroup_delivery_chart.input -tf 'date %Y-%m-%d %H:%M:%OS' tplot: user error (out of memory) real 0m0.026s user 0m0.018s sys 0m0.008s -Manish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The state of binary (de)serialization
On Mon, Feb 25, 2013 at 11:59:42AM -0800, Johan Tibell wrote: - cereal can output a strict bytestring (runPut) or a lazy one (runPutLazy), whilst binary only outputs lazy ones (runPut) The lazy one is more general and you can use toStrict (from bytestring) to get a strict ByteString from a lazy one, without loss of performance. Two major problems of lazy bytestrings is that: * you can't pass it to a C bindings easily. * doing IO with it without rewriting the chunks, can sometimes (depending how the lazy bytestring has been produced) result in a serious degradation of performance calling syscalls on arbitrary and small chunks (e.g. socket's 'send'). Personally, i also like the (obvious) stricter behavior of strict bytestring. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help to write type-level function
Hi, I try to implement typed C-like structures in my little dsl. I was able to express structures using type-level naturals (type Ty is promoted): data Ty = TInt | TBool | TStruct Symbol [Ty] That allowed to implement all needed functions, including type-level function: type family Get (n :: Nat) (xs :: [Ty]) :: Ty But it is not very convenient to identify struct's fields using naturals, and I wanted to change Ty definition to: data Ty = TInt | TBool | TStruct Symbol [(Symbol, Ty)] It is much closer to how C-struct looks, but I was unable to implement required type function: type family Find (s :: Symbol) (xs :: [(Symbol,Ty)]) :: Ty Which just finds a type in a associative list. Could someone give me a hint, how to do it? Or perhaps, is it just impossible thing to do? Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
