[Haskell-cafe] ANNOUNCE: hayland 0.1.0.0

[Auke Booij]

I just pushed the first release of the Haskell bindings to Wayland
I've been working on to Hackage.


SHAMELESS SPAM
-----
I'm looking for a PhD position in (mathematical) type theory
(preferably in Europe). Contact me for my (interesting!) background.


What is Wayland?
-----
For those of you who have been living under a rock, X11 is probably
going to be ditched soon (porting work for GNOME, KDE, and E is
already well underway), and the graphics stack reworked, in favor of
"wayland". There will no longer be a monolithic server between the
compositor (aka window manager) and the window clients. In the new
design, the compositor *is* the central server.

The new architecture allows for proper isolation of clients (a HUGE
security improvement over X11), as well as major cleanups of code
(enabling embedded use).


Why bind to C code?
-----
In theory, wayland should only be a protocol specification (which
happens to have a reference implementation) which could be implemented
in Haskell. However, the current state of the matter is that for EGL
implementation reasons, one is forced to bind to this reference
implementation. (More precisely, the EGL libraries need to be able to
configure wayland - and such code would have to be written for every
wayland implementation.)

So in practice, one can't write a pure Haskell implementation, and
that's why I made bindings for the C library.


Where's the code?
-----
https://github.com/tulcod/haskell-wayland


Wait, why are you even binding to Wayland?
-----
Not sure, but it's pretty foundational stuff so I'm sure it'll be of
use to someone, somewhere. Maybe someone wants to write a window
manager for the new ecosystem (I'm looking at you XMonad)?


Wow, I've never seen a module expose this many symbols
-----
Yes, if anyone has ideas on how to reorganize and/or clean up the
symbols exposed by the various part of the library, I am most
interested.

The problem here is that I'm generating a lot of code using template
haskell, and TH does not give you control over which symbols you want
to expose and how. I could write this list to a haskell source file at
configure time instead (which might be useful for other reasons as
well), but ideally I would like to split up the library into the
various "interfaces" wayland offers - but these interfaces are unknown
at dev time time, and I don't think there is remotely any mechanism to
generate /modules/ at compile time.

I'm interested to hear what you guys think about controlling the
symbol exposure of TH-generated code.


TemplateHaskell /and/ GeneralizedNewtypeDeriving? Are you /trying/ to
derive bottom?
-----
Well I sacrificed some Safety in favor of exposing nice Haskelly
types. Feedback is welcome.


Final note
-----
By the way, I also wrote bindings to xkbcommon a while ago, although
they need some attention. Anyway, my point is that with hayland and
xkbcommon in place (both in a semi-usable state), there should be
plenty of groundwork ready for you to get started with Wayland on
Haskell.

(xkbcommon is the de facto standard library to work with keyboard
layouts in wayland. It translates keyboard events ("which key did you
press") into Unicode symbols ("what letter should appear on the
screen"), using the right keyboard layout.)