[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
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
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 wrote: > 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 > wrote: > >> 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 >> wrote: >> > >> >> Hi Manish, >> >> >> >> Please provide the input file, I'll debug this. >> >> >> >> On Mon, Sep 3, 2012 at 1:06 PM, Manish Trivedi >> 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 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:
* n bytestrings of same size: n*
* n bytestrings of different size: ++..
* n bytestrings plus a w32 prefixed size: len+n*
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
[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] 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] 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] 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
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
On Tue, Feb 26, 2013 at 3:28 PM, Corentin Dupont wrote: > 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] ANN: Nomyx 0.1 beta, the game where you can change the rules
On 27/02/2013, at 10:28 , Corentin Dupont 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
[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] 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 -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 -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 ... <> ___ 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 : > 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] 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] 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] RFC: rewrite-with-location proposal
On Tue, Feb 26, 2013 at 12:06 PM, Simon Peyton-Jones
wrote:
> 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
> 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 | n<0 = 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 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.ha
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
mailto: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 | n<0 = 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
mailto: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
[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] 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
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?!
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 Abel <>< Du 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
[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 Abel <>< Du 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] 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
