The only quirk is that you need to add --| after every sem block, otherwise TextMate will consider everything afterward Haskell code. This token is used to indicate the end of the Haskell code that officially starts after the =. This has the effect that every | before every Constructor is coloured blue. If you want to avoid this, insert --| after every definition.

1
2
3
4

sem Foo
  | Bar lhs.cafe = ...
  | Hotel lhs.desk = ...
--|

Happy coding! (GitHub repository, develop: UUAG.tmbundle.tar.gz)

Over the past few years web standards have, albeit slowly, developed into some mature state: Most browsers support the current (x)HTML, CSS and JS standards to the letter and can do more. However, due to the fact that these standards have evolved so slowly new developments are not included in these standards. HTML5 (W3C and WhatWG) solves a lot of these problems, including features like <canvas> and <video>.

With WhatWG dropping the version number of HTML I foresee a descent back to the Dark Ages where every browser supported a different standard and supported the same standards differently, one browser would support feature X and not Y while the other supports Y but not X. This is a nightmare for developers: not being able to rely on the uniformity of the browsers of your visitors. This created necessities as writing specific CSS and JS code for specific browsers to `fix’ certain behaviour. These fixes mostly had to be done for Internet Explorer as it had at the time by far the largest install base.

Now that we have finally arrived at an era where all browsers support the same set of rather advanced techniques we decide to drop versions. In some cases it is not a disaster to not have a version number. Look at CSS, the changes that have been made to the standard were mostly additions. New operators and new properties and values have been added. These changes required a better parser, and the recognition of the new fields, but never did a semantic change. This, together with the tradition that CSS engines ignore the statements they don’t understand has led to developers being able to include new techniques in CSS files and thus implicitly setting the version of the CSS in the file. As nothing changed older and newer browsers behaved the same at the old statements and only the newer browsers acted on the new statements. So up to now the absence of explicit CSS versioning didn’t cause any problems for CSS.

However, with the absence of versions in HTML5 we have a problem. Not only does the HTML5 standard describe the structure of HTML but it also describes the JS that the browser should support. These standards are in contrast to CSS subject to the changing of their semantics. For example, a JavaScript function can get a different interface: different parameters and/or return values, but also its semantic proper might change.

This changing of semantics without version numbers causes a new nightmare for developers, as they have no way to be sure that their site will look the same across different browsers as they all may support a slightly different incarnation of the standard and on top of that the developer cannot be sure his site will look the same in the same browser a month from now, or even the next day, as the browser can switch to support a newer instance of the standard. As different versions of the same browser may have different engines that support different incarnations of the standard you now also have to worry about the differences between browser versions that your visitors use.

One might notice the presence of a lot of conditions in the above text and think “What is the fuss, it might all not happen.”. The main argument I would like to make here is this: a `living’ standard introduces a lot of uncertainties. At a time where certainties are just starting to come back, giving developers peace of mind, going back to living with uncertainties is certainly a descent into Dark Ages in my opinion.

A solution?

There is of course a reason why they choose to declare this standard as `living’. It denotes the fact that the web is evolving on a faster pace than we are used to, it is quite dynamic. Having to wait several years before you can use a very nice new feature on your website is not nice, as you would like to use it as soon as it becomes defined. Therefore, instead of declaring the standard completely dynamic and deprived of versions, I suggest something like annual milestones. This way one can still compare browsers on their capabilities, new features can be expected to be available rather quickly and most importantly you provide a frame of reference for the developer.

1. Classes are written to the format file;
2. There should be less “ambiguous operator” errors now;
3. Removed the Agda dependency as it didn’t do anything with Agda at all.

Hackage, GitHub.

The most important changes are:

1. Added a filter for rewrite rules that aren’t “lhs2TeX safe”, e.g. format () = ...;
2. I hardcoded the default formatting rules for several of lhs2TeX defaults, including but not limited to ->, <- and =>. This is not a desirable solution but it suits my purposes.

You can do literal (numeral, character and string) formatting easily with lhs2TeX itself with the following directives:

1
2
3

%subst char a    	= "\color{char}\text{\tt ''" a "''}"
%subst string a  	= "\color{string}\text{\tt \char34 " a "\char34}"
%subst numeral a =  "\color{numeral}{ " a " }"

Install it like this:

[bash] > cabal install lhs2TeX-hl [/bash]

lhs2TeX-hl is run before you run lhs2TeX and you supply it with the input file and the output file. A typical execution would look like this:

[bash] > lhs2TeX-hl -o MyPaper.fmt MyPaper.lhs > lhs2TeX -o MyPaper.Tex MyPaper.lhs > pdflatex MyPaper.tex [/bash]

It’s important to note here that you should’ve added the following line to your MyPaper.lhs file:

%include MyPaper.fmt

And that you have the following commands defined in your latex file:

• \lhsCHkeyword
• \lhsCHprelude
• \lhsCHtype
• \lhsCHlitNumber
• \lhsCHconstructor
• \lhsCHfunction
• \lhsCHinfixoperator

For example, like this:

\definecolor{datatype}{RGB}{42,0,217}
\definecolor{class}{RGB}{197,11,16}
\definecolor{fieldname}{RGB}{0,0,162}
\definecolor{prelude}{RGB}{64,80,117}
\definecolor{numeral}{RGB}{0,0,205}
\definecolor{infixoperator}{RGB}{42,0,217}
\definecolor{constructor}{RGB}{0,161,0}
\definecolor{keyword}{RGB}{229,120,0}
\definecolor{special1}{RGB}{159,138,0}

\newcommand{\lhsCHfunction}[1]{\color{infixoperator}}
\newcommand{\lhsCHinfixoperator}[1]{\color{infixoperator}}
\newcommand{\lhsCHprelude}[1]{\color{prelude}{\mathbf{#1}}}
\newcommand{\lhsCHkeyword}[1]{\color{keyword}{\textbf{#1}}}
\newcommand{\lhsCHconstructor}[1]{\color{constructor}{\textbf{#1}}}
\newcommand{\lhsCHlitNumber}[1]{\color{numeral}}
\newcommand{\lhsCHtype}[1]{\color{datatype}}

And then you might end up with something that looks like this:

[caption id=”attachment_306” align=”aligncenter” width=”300” caption=”Literate Highlighter Code v0.1.0.2”][/caption]

To this extent I searched and found a nice tutorial: Setting up Apple Filing Protocol and Bonjour under Debian.

Apparently is was there when I tried this the last time and I missed it. But now it works. This works seamlessly with OS X 10.6. I now even have a nice heavy duty server icon in the Finder for my Debian machine. This is because of the avahi service.

This how to also explains how to setup your TimeMachine to backup to the Debian server.

Do not forget to add the following autoload directive to your hooks/doctrine.php and the doctrine.php cli:

[php]spl_autoload_register(array(‘Doctrine’, ‘modelsAutoload’));[/php]

However, there are some issues to solve when installing the platform from source. Mainly you’ll be missing several packages. The following commands worked at my own Debian machine. If you find out that’s something is missing that was apparently already installed on my machine, don’t hesitate to leave a comment.

The following commands are all executed as root. First we need to download the sources, I’m using the x86 sources, but feel free to use the x64 version: [bash] cd /tmp wget http://www.haskell.org/ghc/dist/6.10.4/ghc-6.10.4-i386-unknown-linux-n.tar.bz2 wget http://hackage.haskell.org/platform/2009.2.0.2/haskell-platform-2009.2.0.2.tar.gz [/bash]

Now we need to extract these sources:

[bash] tar xvf ghc-6.10.4-i386-unknown-linux-n.tar.bz2 tar xvzf haskell-platform-2009.2.0.2.tar.gz [/bash]

Before we do any other stuff, let’s ensure that we have all the packages and libraries we need before continuing.

[bash] apt-get install build-essential libghc6-opengl-dev libghc6-glut-dev libeditline-dev libedit2 libedit-dev [/bash]

Also make sure that you apply this patch to the platform, the bug has been around for some time now but hasn’t been fixed apparently, it can be found at bug #84:

[bash] patch -p0 haskell-platform-2009.2.0.2/scripts/install.sh Index: haskell-platform-2009.2.0.2/scripts/install.sh =================================================================== — haskell-platform-2009.2.0.2.orig/scripts/install.sh +++ haskell-platform-2009.2.0.2/scripts/install.sh @@ -34,13 +34,23 @@ install_pkg () { fi }

+# Is this exact version of the package already installed? +is_pkg_installed () { + PKG_VER=$1 + grep " ${PKG_VER} " installed.packages > /dev/null 2>&1 +} + # Actually do something! cd packages for pkg in cat platform.packages; do - cd "${pkg}" || die "The directory for the component ${PKG} is missing" - echo "Installing ${pkg}…" - install_pkg ${pkg} - cd .. + if is_pkg_installed "${pkg}"; then + echo "Platform package ${pkg} is already installed. Skipping…" + else + cd "${pkg}" || die "The directory for the component ${PKG} is missing" + echo "Installing ${pkg}…" + install_pkg ${pkg} + cd .. + fi done

echo [/bash]

Now go to the ghc dir and build it.

[bash] cd ghc-6.10.4 ./configure make install [/bash]

And if all of this goes well you can now go to the haskell-platform dir and install it:

[bash] cd ../haskell-platform-2009.2.0.2/ ./configure make make install [/bash]

And done! :)