- Haskell-Cafe - Haskell.org

Does this have a name?
by Jacques Carette 05 Nov '12

05 Nov '12

The function > app1 f x = f >>= ($ x) or equivalently > app2 f x = join (f <*> pure x) with type Monad m => m (a -> m b) -> a -> m b ? Hoogle did not help. Jacques PS: a nice point-free version would be appreciated as well. I can easily change app1 and app2 myself to point-free with enough applications of flip, . and $, but none of those are 'nice'.

1 0

ANN: OpenGL packages update
by Jason Dagit 04 Nov '12

04 Nov '12

The updates include: * All of the newtypes in OpenGLRaw have been changed to type aliases (credit to Trevor Elliott and Mike Ledger) * OpenGLRaw's TypesInternal module has gone away * NVidia path rendering extensions have been added by "ozelis" on github This release changes OpenGLRaw to use type aliases instead of newtype wrappers for the GLfoo types, such as GLenum/GLfloat/GLdouble. Using newtypes had the following downsides: * The CPP macros to make these definitions are borrowed verbatim from GHC sources and required updates with new GHC releases in order to stay compatible. Although, it hasn't been a problem yet, it's conceivable this will conflict with supporting different versions of GHC at some point. * Optimization rules have to be written against these newtypes and forgetting them can lead to significant performance degradation or extra verbosity for people using the bindings. * You have to reach pretty deep into GHC to make it possible for the newtypes to work in the unboxed vectors provided by the vector package. This is again, another missed opportunity for high performance code. You can find the source and bug trackers for these packages here: https://github.com/haskell-opengl/ Feedback, pull requests, and bug reports are always welcome! Thanks! Jason

1 0

Help: Main: thread blocked in MVar operation
by "José A. Lopes" 04 Nov '12

04 Nov '12

Hey everyone, I changed my code I now I get the following error message Main: thread blocked indefinitely in an MVar operation Before the change, I was using the State monad with runState. Then, I changed the code to use the StateT monad transformer wrapped around IO monad and runStateT. And this change introduced the error message. BTW I am using DoRec extension, maybe it is the source of the problem, but I don't know. Here are some specs: ghc 7.4.2 mtl 2.1.1 If you need any other information please don't hesitate to ask. Any help is greatly appreciated! Cheers, José -- José António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon

2 2

more sharing in generated code
by Peter Divianszky 04 Nov '12

04 Nov '12

Hi, I have a question about sharing at the Haskell run-time level. Suppose we have a record update r { x = f (r x)} and suppose that most of the time f returns it's argument unchanged. I have the following questions: 1. Does the generated code for the record update build an identical record when f returns it's argument unchanged instead of sharing the old one? (I guess yes.) 2. Can we prevent building identical records? Recently I've heard about Q-combinators. Central idea: Change (f :: a -> a) to (f' :: a -> Maybe a) returning Nothing when the value didn't change. Then we can replace the record update with smarter code which preserves more sharing. My question is: Can (or could) we enable more sharing without changing the source code? Ideally the compiler would generate record update code which checks poiter-equality of the updated field value to decide whether a copy of the original record is needed or it can be shared (given an optimisation flag enabled). Thanks, Peter Background info: There was a discussion on the Agda mailing list about decreasing the Agda compiler memory-usage with more sharing[^1]. (The Agda compiler is written in Haskell.) I had the above idea and I was advised to ask about it on some Haskell mailing list. [^1]: https://lists.chalmers.se/pipermail/agda/2012/004485.html

4 6

Input Handling, Callbacks, State Machines
by Daniel Trstenjak 04 Nov '12

04 Nov '12

Hi all, I'm currently struggling in the search for a nice abstraction for the input handling of a game (it's a simple platformer with rectangular platforms). One good example is the level editor of the game. When pressing the left mouse button the creation of a new platform is started. As long as the mouse button is hold the platform can be resized by moving the mouse. When releasing the mouse button the platform is created with the current shape. The GUI library I'm using is GLFW. There're several callbacks for key, mouse button and mouse move events. Firstly I would like to be able to describe application states, like the creation of a platform or the definition of the movement of a platform. The state might add something to the current level rendering and it changes temporary the callbacks. So in the case of a platform creation, the mouse move callback would just resize the platform, the mouse button callback awaits the button release and the key callback might only allow the quitting of the current creation. Above the application states it would be nice to be able to describe the transition from one state to another. Perhaps FRP might be a solution for this. But I'm still shying away of it, because a game might have some hairy state changes and I still don't see, how FRP makes life in this regard that much easier. Any Ideas? Greetings, Daniel

3 2

haskellers.com: Keterconfig incorrect?
by Obscaenvs 04 Nov '12

04 Nov '12

Excerpt from source: "<h1>Welcome to Keter</h1><p>The hostname you have provided is not recognized.</p>". This after trying to login using Mozilla Persona: http://www.haskellers.com/auth/page/browserid/eyJhbGciOiJSUzI (Where I have shortened the string at the end) f

2 1

forall disappear from type signature
by oleg＠okmij.org 03 Nov '12

03 Nov '12

Takayuki Muranushi wrote: > Today, I encountered a strange trouble with higher-rank polymorphism. It > was finally solved by nominal typing. Was it a bug in type checker? lack of > power in type inference? > runDB :: Lens NetworkState RIB > runDB = lens (f::NetworkState -> RIB) (\x s -> s { _runDB = x }) > where f :: NetworkState -> RIB As it becomes apparent (eventually), RIB is a polymorhic type, something like type RIB = forall a. DB.DBMT (Maybe Int) IO a0 -> IO (StM (DB.DBMT (Maybe Int) IO) a0) The field _runDB has this polymorphic type. Hence the argument x in (\x s -> s { _runDB = x }) is supposed to have a polymorphic type. But that can't be: absent a type signature, all arguments of a function are monomorphic. One solution is to give lens explicit, higher-ranked signature (with explicit forall, that is). A better approach is to wrap polymorphic types like your did > newtype RIB = RIB (RunInBase (DB.DBMT (Maybe Int) IO) IO) The newtype RIB is monomorphic and hence first-class, it can be freely passed around. In contrast, polymorphic values are not first-class, in Haskell. There are many restrictions on their use. That is not a bug in the type checker. You may call it lack of power in type inference: in calculi with first-class polymorphism (such as System F and System Fw), type inference is not decidable. Even type checking is not decidable.

1 0

How to avoid T3 fonts in pdf generated with lhs2TeX?
by Andreas Abel 02 Nov '12

02 Nov '12

Hello, maybe someone has experience in publishing papers that use lhs2TeX and unicode characters with ACM, and has been in my situation before... Sheridan, who publishes for ACM, does not like T3 fonts. However, lhs2tex --agda does make use of T3 fonts via: \RequirePackage[utf8x]{inputenc} If I remove this, my unicode characters are garbled in the lhs2tex-generated code. Does anoyone know a smart workaround besides replacing all the unicode characters manually by some math symbols in the .tex file? Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

3 3

Unicode case (in)stability and Haskell identifiers.
by Richard O'Keefe 02 Nov '12

02 Nov '12

I've been putting together a proposal for Unicode identifiers in Erlang (it's EEP 40 if anyone wants to look it up). In the course of this, it has turned out that there is a technical problem for languages with case-significant identifiers. Haskell 2010 report, chapter 2. http://www.haskell.org/onlinereport/haskell2010/haskellch2.html varid → (small {small | large | digit | ' })\⟨reservedid⟩ conid → large {small | large | digit | ' } small → ascSmall | uniSmall | _ ascSmall → a | b | … | z uniSmall → any Unicode lowercase letter large → ascLarge | uniLarge ascLarge → A | B | … | Z uniLarge → any uppercase or titlecase Unicode letter This is actually ambiguous: any ascSmall is also a uniSmall and any ascLarge is also a uniLarge. I take it that this is intended to mean "any Unicode xxx letter other than an ASCII one" in each case. That's not the problem. The definition currently bans Hebrew, Arabic, Chinese, Japanese, all the Indic scripts, and basically only allows Latin, Greek, Coptic, Cyrillic, Glagolitic, Armenian, arguably Georgian, and Deseret (but not Shavian). That's not the problem either. The problem is that being a Unicode lower case, upper case, or title case letter is not a stable property. Unicode annex UAX#31 guarantees that X is a well-formed case-insensitive identifier now => X will always be a well-formed case-insensitive identifier and that X is a well-formed case-sensitive identifier now => X will always be a well-formed case-sensitive identifier What it does NOT guarantee is that it will continue to be begin with the same *case* or even that a letter will continue to be classified as a letter. So it is at least technically possible for a valid Haskell 2010 varid (conid) to turn into a conid (varid) or even cease to be a legal Haskell identifier at all. Unicode standard Annex UAX#31 guarantees stability of being-an-identifier by having an exceptional set for any letter that stops being a letter to go into. For example, there are SCRIPT CAPITAL {B,E,F,H,I,L,M,P,R} characters, all of which are capital letters except for SCRIPT CAPITAL P, which is a symbol, but it's in the exception set so it's still OK to use. All of the SCRIPT CAPITAL letters were in General Category So in Unicode 1.1.5 (the earliest for which online data is available). In Unicode 2.1.8, all of them were Lu except for SCRIPT CAPITAL P, which was Ll. By Unicode 3.0.0, SCRIPT CAPITAL P was back to So. Some time later it switched over to Sm. So we've had SCRIPT CAPITAL P - not a letter (1.1.5) - is a lower case letter (2.1.8) - not a letter again (3.0.0) at least according to the on-line UnicodeData-<version>.txt files. Putting ℘ into the exceptional set means that a UAX#31 identifier may still contain it, but not so a Haskell one. There are two aspects to this instability. (1) Because Haskell hews its own line instead of tailoring UAX#31 the way Ada and Python do, Haskell cannot benefit from the UAX#31 stability guarantee. There _has_ been a character that used to be legal in a Haskell identifier that is not now. That's Haskell's problem, not Unicode's, and the Haskell community does not have to wait for anyone else to address is. (2) Even if you adopt one of the UAX#31 definitions verbatim, the case distinction Haskell needs to make is not stable. It appears that nobody who worked on UAX#31 was thinking about languages like Prolog, Erlang, Clean, Haskell, F#, or Scala, and that if the Unicode Consortium are told of the problem, they will probably be happy to add some sort of "don't break these languages" guideline. Next week I intend to submit a proposal to the Unicode consortium to consider this issue. Would anyone care to see and comment on the proposal before I send it to Unicode.org? Anyone got any suggestions before I begin to write it? For the sake of argument, suppose that we are going to stick with Xid_Start Xid_Continue* for the union of variables and atoms (which is pretty much what Ada and Python do), and the sole issue of concern is that there should be a stable way to classify such a token as "beginning with default case" or "beginning with marked case".

2 1

[Security] Put haskell.org on https
by Niklas Hambüchen 02 Nov '12

02 Nov '12

(I have mentioned this several times on #haskell, but nothing has happened so far.) Are you aware that all haskell.org websites (hackage, HaskellWiki, ghc trac) allow unencrypted http connections only? This means that everyone in the same Wifi can potentially - read you passwords for all of these services - abuse your hackage account and override arbitrary packages (especially since hackage allows everybody to override everything) I propose we get an SSL certificate for haskell.org. I also offer to donate that SSL certificate (or directly create it using my Startcom account). Niklas

17 34