[Haskell-cafe] Physical equality
Is there in Haskell a non monadic function of type a - a - Bool which test for physical equality of two values? It would return True if only if both values are the same object in memory. For instance: value1 = good value2 = good eq value1 value2 = False value1 = good value2 = value1 eq value1 value2 = True Romildo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Physical equality
2010/6/28 José Romildo Malaquias j.romi...@gmail.com: Is there in Haskell a non monadic function of type a - a - Bool which test for physical equality of two values? It would return True if only if both values are the same object in memory. For instance: value1 = good value2 = good eq value1 value2 = False value1 = good value2 = value1 eq value1 value2 = True Not exactly what you ask for, but quite close: http://www.haskell.org/ghc/docs/6.12.1/html/libraries/base/System-Mem-StableName.html Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Physical equality
On 28 Jun 2010, at 09:38, José Romildo Malaquias wrote: Is there in Haskell a non monadic function of type a - a - Bool which test for physical equality of two values? It would return True if only if both values are the same object in memory. For instance: value1 = good value2 = good eq value1 value2 = False value1 = good value2 = value1 eq value1 value2 = True This simply isn't possible without manually tagging values yourself (or with a library), it would violate referential transparency. Remember, a function, called twice with semantically identical arguments must always return the same value, that isn't true of eq. Even if this weren't an issue, you're relying heavily on the runtime's behaviour here. There's nothing to stop the runtime, in the first example, observing that the two values are identical, and making them both take up the same memory – they are after all immutable, so that's totally safe. There's similarly nothing to stop the runtime, in the second example, arbitrarily copying the the string (although it's probably not a great idea for efficiency). Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why this doesn't type checked
On Mon, Jun 28, 2010 at 08:51:45AM +0400, Victor Nazarov wrote:
What we get with this instances is following code.
main =
do print (sizeof :: Sizeof Word16)
Let's try it.
$ runhaskell this.lhs
this.lhs:78:14:
Couldn't match expected type `Int'
against inferred type `Sizeof sizeable'
NB: `Sizeof' is a type function, and may not be injective
In the first argument of `print', namely
`(sizeof :: Sizeof Word16)'
In the expression: print (sizeof :: Sizeof Word16)
In the expression: do { print (sizeof :: Sizeof Word16) }
Right. Since Sizeof Word8 is Int too, the type can't help determining the
value.
Then it should be ambiguous type-parameter error or something like
this, why Int is expected?
It knows that
Sizeof Word16 = Int
which is why Int is expected. It also knows
sizeof :: Sizeable sizeable = Sizeof sizeable
so it tries to match 'Sizeof sizeable' with 'Int'. Unfortunately this
is not enough information to figure out what 'sizeable' is supposed to
be. There are quite a few options for sizeable that would make
'Sizeof sizeable = Int', and even if there were only one, type classes
are open so there could always be another one added in another module
somewhere.
-Brent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: building a patched ghc
I don't know the answer to your questions, but just wanted to note that you will probably get a better response on the glasgow-haskell-users mailing list. http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/mailing-lists-GHC.html -Brent On Fri, Jun 25, 2010 at 08:56:09PM -0700, braver wrote: An attempt to build the trunk gets me this: /opt/portage/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64- pc-linux-gnu/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation R_X86_64_PC32 against symbol `StgRun' can not be used when making a shared object; recompile with -fPIC -- I use prefix portage on a CentOS box, admittedly a non-standard setup. Its gcc is found first and it wants -fPIC... Should I just add it to CFLAGS or what? -- Alexy ___ 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] Type-Level Programming
On Fri, Jun 25, 2010 at 02:26:54PM -0700, Walt Rorie-Baety wrote: I've noticed over the - okay, over the months - that some folks enjoy the puzzle-like qualities of programming in the type system (poor Oleg, he's become #haskell's answer to the Chuck Norris meme commonly encountered in MMORPGs). Anyway,... are there any languages out there whose term-level programming resembles Haskell type-level programming, and if so, would a deliberate effort to appeal to that resemblance be an advantage (leaving out for now the hair-pulling effort that such a change would entail)? As several people have pointed out, type-level programming in Haskell resembles logic programming a la Prolog -- however, this actually only applies to type-level programming using multi-parameter type classes with functional dependencies [1] (which was until recently the only way to do it). Type-level programming using the newer type families [2] (which are equivalent in power [3]) actually lets you program in a functional style, much more akin to defining value-level functions in Haskell. However, all of this type-level programming is fairly *untyped* -- the only kinds available are * and (k1 - k2) where k1 and k2 are kinds [4], so type-level programming essentially takes place in the simply typed lambda calculus with only a single base type, except you can't write explicit lambdas. I'm currently working on a project with Simon Peyton-Jones, Dimitrios Vytiniotis, Stephanie Weirich, and Steve Zdancewic on enabling *typed* functional programming at the type level in GHC, very much inspired by Conor McBride's SHE preprocessor [5]. I've got a blog post in the works explaining our goals in much more detail, hopefully I'll be able to get that up in the next day or two. -Brent [1] http://haskell.org/haskellwiki/Functional_dependencies [2] http://haskell.org/haskellwiki/Type_families [3] http://www.haskell.org/pipermail/haskell-cafe/2009-February/055890.html [4] Leaving out GHC's special ? and ?? kinds which aren't really of interest to the type-level programmer. [5] http://personal.cis.strath.ac.uk/~conor/pub/she/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: HaRe, the Haskell Refactorer 0.6
Dear Haskellers, As part of our project on Refactoring Functional Programs http://www.cs.kent.ac.uk/projects/refactor-fp/ we are pleased to announce the availability of HaRe 0.6 (also known as HaRe 28/06/2010), a snapshot of our Haskell Refactorer prototype. Apart from bug-fixes, there are major changes since HaRe 0.5 and HaRe 0.4: A number of new refactorings have been added to HaRe. Some of these include: Adding and removing fields and constructors to data-type definitions, folding and unfolding against as-patterns, merging and splitting, converting between let and where constructs, introduce pattern matching, generative folding, and a clone detection and elimination tool. We have evolved the ongoing architecture of HaRe and derived an API (documented using Haddock) for program analysis and transformation. This allows HaRe to serve as a framework for end-users to build their own refactorings or just program transformations (or analyses). HaRe is available to download directly from here: http://www.cs.kent.ac.uk/projects/refactor-fp/hare/HaRe_28062010.tar.gz You can get HaRe 0.6 and the documentation about how to build your own refactorings via: http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Please see the README.txt for build/use instructions and known issues, and let us know about any problems, bugs, suggestions or additional platforms you can confirm as working. You will need: 1. ghc-6.12.1 2. hint-0.3.2.3 (available from cabal) 3. unix/gnu tools (or cygwin tools, if on windows) 4. vim or emacs (we've tested with gvim 6.2 and with emacs 21.4) 5. If you intend on running the test suite, HUnit-1.0. Happy Refactoring! The HaRe Team (Chris Brown, Huiqing Li, Simon Thompson) Project email: refactor-fp at kent.ac.ukhttp://www.haskell.org/mailman/listinfo/haskell Background: Refactoring is the process of changing the structure of programs without changing their functionality, i.e., refactorings are meaning-preserving program transformations that implement design changes. For more details about refactoring, about our project and for background on HaRe, see our project pages. HaRe - the Haskell Refactorer: HaRe is our prototype tool supporting a collection of refactorings for Haskell 98 (see README.txt for known issues and limitations). It is implemented as a separate refactoring engine (on top of Programatica's Haskell frontend and Strafunski's generic traversal strategy library), with small scripting frontends that call this engine from either Vim or Emacs. Currently supported refactorings: Introduce Pattern Match: place cursor over pattern variable Introduce Sub pattern : place cursor over pattern variable Introduce Case Expression : place cursor over pattern variable Generative Fold: highlight expression to fold. Must have equation in comment directly before definition of highlighted expression. Clone Analysis : select from menu Clone Extraction : highlight clone from the clone class to extract, follow step-by-step instructions. Converting Let to Where: place cursor at start of identifier whose definition is to be moved Converting Where to Let: place cursor at start of identifier whose definition is to be moved. create type signatures : select from menu remove redundant declarations : highlight definition to clean up add constructor to data type: place cursor at start of data type, you'll be prompted to add the new Constructor name, followed by any Type parameters as a complete string Split a tuple : place cursor at start of top level definition that returns a tuple. Slicing based on a subexpression : highlight sub-expression to extract. Instantiate a general pattern : select a function equation and enter the new instances for each pattern in the argument set. Extract an expression : highlight an expression within a definition Convert data type to newtype: place cursor at start of data type add definition to merge: place cursor at start of definition that is to be merged merge definitions : use add definition for merge for each definition to be merged. then choose merge definitions from menu. fold function definition : highlight function equation to fold against. fold
Re: [Haskell-cafe] Construction of short vectors
On Sun, Jun 27, 2010 at 4:44 PM, Alexey Khudyakov alexey.sklad...@gmail.com wrote: Dependent types would be nice but there isn't anything usable out there. Newtype wrapper parametrized by type level number works fine so far. If you interested sources are available here: http://bitbucket.org/Shimuuar/nvector http://bitbucket.org/Shimuuar/type-numbers I haven't looked to see how complete your code is, but feel free to take over the vector-static [1] project if you wish to use some existing code. I haven't taken the time yet to say so on the Hackage page, but it's not currently being maintained. - Jake [1] http://hackage.haskell.org/package/vector-static ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCi and State
hi, On 25.06.2010 11:07, corentin.dup...@ext.mpsa.com wrote: Another couple of reflexions (sorry for monopolizing): 1. Since i am making a Nomic game, players will have to submit rules. These rules will be written in a sub-set of haskell. Instead of writing my own reader/interpreter, i'd like to use GHC to compil them on the fly, and then add them to the current legislation. What would you suggest me to do that? Any pointers? check out hint, a nice wrapper around the ghc api [1]. have fun martin [1]: http://hackage.haskell.org/package/hint 2. For now, the game is more or less playable in GHCi. But my concern is: When you use GHCi, you are in the IO monad, right? How to had state to this monad? I would like that the player can compose his rule in GHCi, and when he is done, he can submit it in GHCi with something like: *Nomic submitRulemyrule And then the game takes the rule, possibly modify the current legislation, and give the hand back to GHCi. So the current legislation has to be a state of the GHCi's loop. Is this possible at all? submitRule would have a type more or less like that (GameState contains the legislation): submitRule :: Rule - StateT GameState IO () Thanks for your attention! I know this is a bit confused! Best, Corentin ___ 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] Construction of short vectors
On Mon, Jun 28, 2010 at 7:02 PM, Jake McArthur jake.mcart...@gmail.com wrote: On Sun, Jun 27, 2010 at 4:44 PM, Alexey Khudyakov alexey.sklad...@gmail.com wrote: Dependent types would be nice but there isn't anything usable out there. Newtype wrapper parametrized by type level number works fine so far. If you interested sources are available here: http://bitbucket.org/Shimuuar/nvector http://bitbucket.org/Shimuuar/type-numbers I haven't looked to see how complete your code is, but feel free to take over the vector-static [1] project if you wish to use some existing code. I haven't taken the time yet to say so on the Hackage page, but it's not currently being maintained. I'm aware about this package but I didn't use it because it's completely undocumented. Also my code is a bit different. Vector is parametrized by two phantom type parameters. One is vector length another is type of vector. I want to be able to differentiate between different vectors (euclidean vector and polynomial coefficients have different types) There is also one rather wild idea. Since function for fixed vectors only wraps function from vector in theory it could be possible to generate most of code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MonadCatchIO and bracket.
While working this weekend on the Snap web framework, I ran into a problem. Snap implements MonadCatchIO, so I thought I could just use bracket to handle resource acquisition/release in a safe manner. Imagine my surprise when bracket simply failed to run the release action sometimes. I quickly determined the times when it doesn't run are when Snap's monadic short-circuiting is used. I dug into the source of bracket (in the transformers branch, though the mtl branch has the same behavior in these cases, with slightly different code), and the reason why quickly became obvious: -- | Generalized version of 'E.bracket' bracket :: MonadCatchIO m = m a - (a - m b) - (a - m c) - m c bracket before after thing = block $ do a - before r - unblock (thing a) `onException` after a _ - after a return r When monadic short-circuiting applies, the _ - after a line gets completely ignored. In discussions with #haskell on this topic, it quickly became clear that for any monad transformer that can affect control flow, the definition of bracket in MonadCatchIO doesn't keep the guarantee provided by bracket in Control.Exception, which is that the after action will be run exactly once. Because of that, I think bracket needs to be a class function. Furthermore, I think it needs to be a new class, ie class MonadCatchIO m = MonadBracketIO m where bracket :: m a - (a - m b) - (a - m c) - m c This would allow its definition in cases where it makes sense (Snap or MaybeT IO), but it could be left out in cases where it doesn't make sense, like ListT IO, even though MonadCatchIO makes sense there. Carl Howells ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type-Level Programming
So is there a specific reason why Haskell isn't dependently typed then? Or you could ask, So is there a specific reason why C isn't a functional language? More to the point, Haskell was a bit too frozen in stone when dependent type theory reached the point of being implementable. Right. So, in summary, the answer is historical circumstance? (I was wondering whether it was history or whether it's impossible to implement dependantly-typed languages or some other reason or...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type-Level Programming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/28/10 15:04 , Andrew Coppin wrote: More to the point, Haskell was a bit too frozen in stone when dependent type theory reached the point of being implementable. Right. So, in summary, the answer is historical circumstance? (I was wondering whether it was history or whether it's impossible to implement dependantly-typed languages or some other reason or...) I think you chose to chop off a partial answer to that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwo9I4ACgkQIn7hlCsL25VeSwCfSwXPHN1iN9RSbvxa31BL+Q0Y nq8AoMf5I13/mGItF5MS08WxSWUsOF0f =hBO8 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type-Level Programming
wren ng thornton wrote: Andrew Coppin wrote: I think I looked at Coq (or was it Epigram?) and found it utterly incomprehensible. Whoever wrote the document I was reading was obviously very comfortable with advanced mathematical abstractions which I've never even heard of. One of the things I've found when dealing with--- er, reading the documentation for languages like Coq, is that the class of problems which motivate the need to move to such powerful formalisms are often so abstract that it is hard to come up with simple practical examples of why anyone should care. There are examples everywhere, but complex machinery is only motivated by complex problems, so it's hard to find nice simple examples. Yeah. I think a similar problem is probably why most of the existing GHC extensions don't have comprehendable documentation. It's like if you don't understand why this is useful, you probably don't even need it anyway. Except that that still doesn't explain the opaque language. (Other than that saying this lets you put a thingy on the wotsit holder would be even *more* opaque...) It's a bit like trying to learn Prolog from somebody who thinks that the difference between first-order and second-order logic is somehow common knowledge. (FWIW, I have absolutely no clue what that difference is. First-order means you can only quantify over simple things. Second-order means you can also quantify over quantification, as it were. Sure. I get the idea that second-order means like first-order, but you can apply it to itself (in most contexts, anyway). But what the heck does quantification mean? Sadly, I suspect that it would be like asking where Maidenhead is. (Hey, where *is* Maidenhead anyway? Oh, it's near Slough. Uh, where's Slough? It's in Berkshire. ...and where's Berkshire? It's near Surrey. OK, forget I asked.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Mining Twitter data in Haskell and Clojure
Claus -- cafe5 is pretty much where it's at. You're right, the proggy was used as the bug finder, actually at cafe3, still using ByteString. It would be useful to have a really tiny data source - no more than 100 entries per Map should be sufficient to confirm or reject hunches about potential leaks by profiling. As it stands, my poor old laptop with a 32bit GHC won't be much use with your sample data, and now that the GHC bug is fixed, the size of the samples would only hide the interesting aspects (from a profiling perspective). Having translated it from Clojure to Haskell to OCaml, Translating quickly between strict-by-default and non-strict-by-default languages is always a warning sign: not only is it unlikely to make best use of each language's strengths, but typical patterns in one class of languages simply don't translate directly into the other. I'm now debugging the logic and perhaps the conceptual data structures. Then better maps will be tried. No matter what Maps you try, if they are strict in keys and non-strict in values, translating code from strict language needs careful inspection. Most of the higher-order functions in Maps have issues here (eg, repeated use of insertWith is going to build up unevaluated thunks, and so on). I'm not even sure how well binary fares with nested IntMaps (not to mention the occasional too few bytes error depending on strictness or package version - it would be useful to have a cabal file, or a README listing the versions of libraries you used). To binary package users/authors: is there a typed version of binary (that is, one that records and checks a representation of the serialized type before actual (de-)serialization)? It would be nice to have such a type check, even though it wouldn't protect against missing bytes or strictness changes. Then a giant shootout will ensue, now that Haskell finishes! I'll post here when it's ready. Just make sure Haskell isn't running with brakes on!-) Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Mining Twitter data in Haskell and Clojure
claus.reinke: To binary package users/authors: is there a typed version of binary (that is, one that records and checks a representation of the serialized type before actual (de-)serialization)? It would be nice to have such a type check, even though it wouldn't protect against missing bytes or strictness changes. There is a wrapper, that wraps all encodes in a typeOf (iirC), I think by Edward Kmett, but I couldn't find e.g. binary-typed on Hackage. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type-Level Programming
Brent Yorgey wrote: As several people have pointed out, type-level programming in Haskell resembles logic programming a la Prolog -- however, this actually only applies to type-level programming using multi-parameter type classes with functional dependencies [1] (which was until recently the only way to do it). Type-level programming using the newer type families [2] (which are equivalent in power [3]) actually lets you program in a functional style, much more akin to defining value-level functions in Haskell. I did wonder what the heck a type function is or why you'd want one. And then a while later I wrote some code along the lines of class Collection c where type Element c :: * empty :: c - Bool first :: c - Element c So now it's like Element is a function that takes a collection type and returns the type of its elements - a *type function*. Suddenly the usual approach of doing something like class Collection c where empty :: c x - Bool first :: c x - x seems like a clumsy kludge, and the first snippet seems much nicer. (I gather that GHC's implementation of all this is still fragile though? Certainly I regularly get some very, very strange type errors if I try to use this stuff...) The latter approach relies on c having a particular kind, and the element type being a type argument (rather than static), and in a specific argument position, and so on. So you can construct a class that works for *one* type of element, or for *every* type of element, but not for only *some*. The former approach (is that type families or associated types or...? I get confused with all the terms for nearly the same thing...) seems much cleaner to me. I never liked FDs in the first place. Not only is Element now a function, but you define it as a sort of case-by-case pattern match: instance Collection Bytestring where type Element ByteString = Word8 instance Collection [x] where type Element [x] = x instance Ord x = Collection (Set x) where type Element (Set x) = x ... So far, I haven't seen any other obvious places where this technology might be useful (other than monads - which won't work). Then again, I haven't looked particularly hard either. ;-) However, all of this type-level programming is fairly *untyped* Yeah, there is that. -- the only kinds available are * and (k1 - k2) Does # not count? so type-level programming essentially takes place in the simply typed lambda calculus with only a single base type, except you can't write explicit lambdas. Uh... if you say so? o_O I'm currently working on a project with Simon Peyton-Jones, Dimitrios Vytiniotis, Stephanie Weirich, and Steve Zdancewic on enabling *typed* functional programming at the type level in GHC Certainly sounds interesting... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] whine and solution about programmers not respecting documentations
Some docs are in a miserable state of being incomplete. And then some programmers are in a miserable state of not respecting docs when the docs are complete. Why should anyone expect deleteBy (=) 5 [0..10] to accomplish anything meaningful, if he/she respects the written docs? Today someone on #haskell expected it to accomplish something meaningful, even something mind-reading. The said person has been around for more than a year, not eligible for the newbie excuse. The said person is just the tip of an iceberg. The doc of deleteBy states: The deleteBy function behaves like delete, but takes a user-supplied equality predicate. A precondition is that the user-supplied predicate is an equality predicate. (=) is not an equality predicate, be it in the layperson sense of it isn't analogous to (==) or the mathematical sense of it isn't an equivalence relation. If you respect the precondition or the authors of the doc, you should just never use deleteBy (=) 5 [0..10], much less expect any meaningful result. I propose this solution: For each of deleteBy, groupBy, unionBy... we can usually conceive at least two implementations, behaving pretty much the same (answer, speed, space) when given an equivalence relation (modulo some rare concern when the equivalence relation has assymetric strictness properties), but behaving different when not, and their code sizes are pretty much the same. With more imagination and allowing some code bloat, perhaps we can conceieve more implementations. But two suffices, really. I propose that at each minor version of base, someone picks an implementation randomly. Here is a more radical, less labour-intensive solution, if you don't mind a judicious, correctness-preserving use of unsafePerformIO: at the first invocation of the process lifetime, pick an implementation randomly. The result frustrates people who disrespect the docs. My purpose is exactly that. The goal is to give people an incentive to not disrepect the docs. (If you think this is a nasty stick, not carrot incentive, on first thought I would agree. On second thought, it is not adding a stick, it is just removing a carrot. Programmer's carrot means his/her code works consistently. When deleteBy (=) works consistently, you are giving out undeserved free carrots --- incentive to write more wrong code. I am proposing to remove undeserved free carrots.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MonadCatchIO and bracket.
On 28/06/2010 20:02, Carl Howells wrote: While working this weekend on the Snap web framework, I ran into a problem. Snap implements MonadCatchIO, so I thought I could just use bracket to handle resource acquisition/release in a safe manner. Imagine my surprise when bracket simply failed to run the release action sometimes. I quickly determined the times when it doesn't run are when Snap's monadic short-circuiting is used. I dug into the source of bracket (in the transformers branch, though the mtl branch has the same behavior in these cases, with slightly different code), and the reason why quickly became obvious: See also this recent thread on haskell-cafe: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079198.html which concluded that the ContT instance in MonadCatchIO is broken. I think as you say, the instances of that library are flawed when dealing with monads that can alter the control flow. Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MonadCatchIO and bracket.
On Mon, Jun 28, 2010 at 10:02 PM, Carl Howells chowell...@gmail.com wrote: While working this weekend on the Snap web framework, I ran into a problem. Snap implements MonadCatchIO, so I thought I could just use bracket to handle resource acquisition/release in a safe manner. Imagine my surprise when bracket simply failed to run the release action sometimes. I quickly determined the times when it doesn't run are when Snap's monadic short-circuiting is used. I dug into the source of bracket (in the transformers branch, though the mtl branch has the same behavior in these cases, with slightly different code), and the reason why quickly became obvious: -- | Generalized version of 'E.bracket' bracket :: MonadCatchIO m = m a - (a - m b) - (a - m c) - m c bracket before after thing = block $ do a - before r - unblock (thing a) `onException` after a _ - after a return r When monadic short-circuiting applies, the _ - after a line gets completely ignored. In discussions with #haskell on this topic, it quickly became clear that for any monad transformer that can affect control flow, the definition of bracket in MonadCatchIO doesn't keep the guarantee provided by bracket in Control.Exception, which is that the after action will be run exactly once. Because of that, I think bracket needs to be a class function. Furthermore, I think it needs to be a new class, ie class MonadCatchIO m = MonadBracketIO m where bracket :: m a - (a - m b) - (a - m c) - m c This would allow its definition in cases where it makes sense (Snap or MaybeT IO), but it could be left out in cases where it doesn't make sense, like ListT IO, even though MonadCatchIO makes sense there. I'm not sure if it's related to this, but I had a problem[1] using the ContT instance of MonadCatchIO, but there the result was the opposite: I would have resources released twice. I would really like to have that one solved as well. Michael [1] http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/76262 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Space leak with unsafePerformIO
On Sun, 27 Jun 2010, Henning Thielemann wrote: Maybe I can combine splitAtLazy and (++) to a function like splitAtAndAppend :: [x] - ([a] - [b]) - ([a] - [b]) - [a] - [b] but I'm afraid I will need pairs temporarily and then I run into the same problems. I have now implemented a solution that is tailored to special function types in the first ([a] - [b]) argument. It works, but it is sad that the general, more declarative solution is so fragile. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Mon, Jun 28, 2010 at 1:44 PM, Albert Y.C.Lai tre...@vex.net wrote: Why should anyone expect deleteBy (=) 5 [0..10] to accomplish anything meaningful, if he/she respects the written docs? I proposed the following solution: http://lukepalmer.wordpress.com/2009/07/01/on-the-by-functions/ Today someone on #haskell expected it to accomplish something meaningful, even something mind-reading. The said person has been around for more than a year, not eligible for the newbie excuse. The said person is just the tip of an iceberg. The doc of deleteBy states: The deleteBy function behaves like delete, but takes a user-supplied equality predicate. A precondition is that the user-supplied predicate is an equality predicate. (=) is not an equality predicate, be it in the layperson sense of it isn't analogous to (==) or the mathematical sense of it isn't an equivalence relation. If you respect the precondition or the authors of the doc, you should just never use deleteBy (=) 5 [0..10], much less expect any meaningful result. I propose this solution: For each of deleteBy, groupBy, unionBy... we can usually conceive at least two implementations, behaving pretty much the same (answer, speed, space) when given an equivalence relation (modulo some rare concern when the equivalence relation has assymetric strictness properties), but behaving different when not, and their code sizes are pretty much the same. With more imagination and allowing some code bloat, perhaps we can conceieve more implementations. But two suffices, really. I propose that at each minor version of base, someone picks an implementation randomly. Here is a more radical, less labour-intensive solution, if you don't mind a judicious, correctness-preserving use of unsafePerformIO: at the first invocation of the process lifetime, pick an implementation randomly. The result frustrates people who disrespect the docs. My purpose is exactly that. The goal is to give people an incentive to not disrepect the docs. (If you think this is a nasty stick, not carrot incentive, on first thought I would agree. On second thought, it is not adding a stick, it is just removing a carrot. Programmer's carrot means his/her code works consistently. When deleteBy (=) works consistently, you are giving out undeserved free carrots --- incentive to write more wrong code. I am proposing to remove undeserved free carrots.) ___ 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] Physical equality
On Monday, June 28, 2010 10:38:33 am José Romildo Malaquias wrote: Is there in Haskell a non monadic function of type a - a - Bool which test for physical equality of two values? It would return True if only if both values are the same object in memory. IIRC observable sharing does similar things. Sönke For instance: value1 = good value2 = good eq value1 value2 = False value1 = good value2 = value1 eq value1 value2 = True Romildo ___ 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] Physical equality
reallyUnsafePointerEquality :: a - a - Int# but don't use as it can give both false negatives (i.e. GC in the middle of evaluation) and false positives (that GC just finished and put one object right where the other was.) The better model to obtain what you want to use StableNames and seq and, if you must, a little bit of unsafePerformIO, but note that this means that side-effects and various inlining/sharing improvements caused by the usual compilation process that previously were non-observable become critical to the correctness of your function, which is why the result is in IO to begin with. Typically you can construct something purely and inspect the result using IO all in one go, so the unsafePerformIO machinery isn't required. -Edward Kmett 2010/6/28 José Romildo Malaquias j.romi...@gmail.com Is there in Haskell a non monadic function of type a - a - Bool which test for physical equality of two values? It would return True if only if both values are the same object in memory. For instance: value1 = good value2 = good eq value1 value2 = False value1 = good value2 = value1 eq value1 value2 = True Romildo ___ 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] Call for comments: neither package
Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MonadCatchIO and bracket.
There’s a history of rich debate and discussion on these issues coming from the scheme world, where it takes the guise of implementing unwind-protect in the presence of call/cc. Kent Pitman’s take is presented here: http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-overview.html There’s some context given in the following ltu discussion: http://lambda-the-ultimate.org/node/2966 Will Clinger’s notes on his revised implementation are particularly useful: http://www.ccs.neu.edu/home/will/UWESC/uwesc.sch Note that none of the implementations translate directly, I think, as they rely on top-level mutable state. In any case, my take is the following -- first, remove the ContT instance from the CatchIO package as it is obviously wrong. Next, don’t use ContT in the presence of exceptions. There are few cases where one really needs to do so, given that exceptions provide a powerful means of flow control themselves. Finally, it is much easier to provide a bracket function with one-shot continuations (i.e., MonadExit), and doing so could well simplify most of the current uses of ContT. Cheers, Sterl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
It looks like good work, but I would be hesitent about depending on a package which pulled in both mtl and tranformers. Maybe that's just superstition - I haven't tried it. Antoine On Jun 28, 2010 5:51 PM, Michael Snoyman mich...@snoyman.com wrote: Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither ___ 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] specifying package name in ghci import?
Hi, Quick question about ghci: when I do this at the prompt: ghci :m +Control.Monad.Cont I get Ambiguous module name `Control.Monad.Cont': it was found in multiple packages: mtl-1.1.0.2 monads-fd-0.0.0.1 Is there any way to fix this from within ghci (i.e. not involving mucking with ghc-pkg)? What I have in mind might be e.g. ghci :m + mtl Control.Monad.Cont or something similar. Thanks, Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Mining Twitter data in Haskell and Clojure
On Mon, Jun 28, 2010 at 2:32 PM, Don Stewart d...@galois.com wrote: claus.reinke: To binary package users/authors: is there a typed version of binary (that is, one that records and checks a representation of the serialized type before actual (de-)serialization)? It would be nice to have such a type check, even though it wouldn't protect against missing bytes or strictness changes. There is a wrapper, that wraps all encodes in a typeOf (iirC), I think by Edward Kmett, but I couldn't find e.g. binary-typed on Hackage. In Happstack.Data there's a wrapper type called Object which we serialize through which has a type-rep field and a ByteString field, and the deserialize instance function checks that the type-string filed matches show (typeOf result): http://hackage.haskell.org/packages/archive/happstack-data/0.5.0.2/doc/html/Happstack-Data-Serialize.html#t%3AObject A similar technique might be approrpiate for 'binary' or 'cereal'. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
In the case of 'deleteBy' we can improve an API. deleteBy eq x xs == deletePred (eq x) xs @deletePred pred xs@ removes the first element of @xs@ which satisfies a predicate @p...@. Your solution is more general. :) On 28.06.10 22:44, Albert Y.C.Lai wrote: And then some programmers are in a miserable state of not respecting docs when the docs are complete. Why should anyone expect deleteBy (=) 5 [0..10] -- Best regards, Roman Beslik. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Bangalore
Wow! great to see Haskellers from B'lore. I'll be interested too. On Mon, Jun 21, 2010 at 10:00 AM, C K Kashyap ckkash...@gmail.com wrote: Hi, I was wondering if it would be a good idea for the folks interested in Haskell in Bangalore to get together. Especially if there are folks at EGL, perhaps we could just meet up at pyramid. I've been trying to learn Haskell for a while and currently am trying to work through SPJ's implementation of Functional Programming languages. It would be good to bounce off ideas (in person) with like minded folks. -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- lakshminp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] whine and solution about programmers not respecting documentations
On Jun 28, 2010, at 2:29 PM, Luke Palmer wrote: I proposed the following solution: http://lukepalmer.wordpress.com/2009/07/01/on-the-by-functions/ Seconded! I always want xxxOn and I almost never (perhaps never*) want xxxBy for xxx in sort, maximum, group and nub. - Mark (*) A quick scan of all the Haskell source I wrote on my machine reveals that I have never once used xxxBy without giving it a function of the form (==) on foo or comparing foo! Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
As far as I know, the only issue with depending on both is the conflicting orphan Monad instance for Either. Can anyone either confirm or deny this? On Tue, Jun 29, 2010 at 5:11 AM, Antoine Latter aslat...@gmail.com wrote: It looks like good work, but I would be hesitent about depending on a package which pulled in both mtl and tranformers. Maybe that's just superstition - I haven't tried it. Antoine On Jun 28, 2010 5:51 PM, Michael Snoyman mich...@snoyman.com wrote: Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither ___ 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] Call for comments: neither package
On 29 June 2010 15:20, Michael Snoyman mich...@snoyman.com wrote: As far as I know, the only issue with depending on both is the conflicting orphan Monad instance for Either. Can anyone either confirm or deny this? Since you're being naughty and using package-qualified imports, it should be OK (in terms of working). On Tue, Jun 29, 2010 at 5:11 AM, Antoine Latter aslat...@gmail.com wrote: It looks like good work, but I would be hesitent about depending on a package which pulled in both mtl and tranformers. Maybe that's just superstition - I haven't tried it. Antoine On Jun 28, 2010 5:51 PM, Michael Snoyman mich...@snoyman.com wrote: Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither ___ 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 -- 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] whine and solution about programmers not respecting documentations
Albert Y.C.Lai tre...@vex.net writes: The doc of deleteBy states: The deleteBy function behaves like delete, but takes a user-supplied equality predicate. A precondition is that the user-supplied predicate is an equality predicate. (=) is not an equality predicate, be it in the layperson sense of it isn't analogous to (==) or the mathematical sense of it isn't an equivalence relation. One could argue that this is a bad specification. The type is deleteBy :: (a - a - Bool) - a - [a] - [a] but there are further limitations on the arguments, and worse, the function doesn't check this and produce an error if the arguments don't conform, but just silently produces a meaningless result. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
On Tue, Jun 29, 2010 at 8:24 AM, Ivan Miljenovic ivan.miljeno...@gmail.comwrote: On 29 June 2010 15:20, Michael Snoyman mich...@snoyman.com wrote: As far as I know, the only issue with depending on both is the conflicting orphan Monad instance for Either. Can anyone either confirm or deny this? Since you're being naughty and using package-qualified imports, it should be OK (in terms of working). Is naughty simply tongue-in-cheek, or are there detriments to it? You know, besides not all compilers supporting them... Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
On 29 June 2010 15:38, Michael Snoyman mich...@snoyman.com wrote: On Tue, Jun 29, 2010 at 8:24 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 29 June 2010 15:20, Michael Snoyman mich...@snoyman.com wrote: As far as I know, the only issue with depending on both is the conflicting orphan Monad instance for Either. Can anyone either confirm or deny this? Since you're being naughty and using package-qualified imports, it should be OK (in terms of working). Is naughty simply tongue-in-cheek, or are there detriments to it? You know, besides not all compilers supporting them... A bit of both. Someone (dons?) had a good discussion on the Haskell reddit about why you shouldn't use them, but I can't seem to find it at the moment (I did find this one, but I seem to recall a better discussion: http://www.reddit.com/r/haskell/comments/bfcfs/haskells_big_three/c0mhqtg ). Otherwise, the documentation for it discourages its use: http://haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#package-imports -- 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
