glsl-syntax - abandoned

Copperbox revision 2714.

I've partially updated the syntax to make better distinction between declarations and declarators, but I've decided to abandon the project again. Basically I never had a concrete use for a GLSL parser and I was using the project to learn something about the GLSL language. However, the C style syntax for declarations is so horrible that writing a parser is no fun and hardly instructive. My time is better spent on other things.

glsl-syntax

Copperbox revision 2713.

The parser now works - it must never have been working when I abandoned it as I had to relax the distinction in the parser grammar between identifiers and field selectors - basically the lexer never knows what is a field selector so it has to class everything as an identifier.

The parser isn't going to be robust - I think GLSL code in the wild uses CPP which it obviously can't handle. Also I think the grammar for GLSL has changed vis void main () and void main (void) - as my parser is LALR, which is always a struggle to use, I'm not going to rush to make it handle errors and discrepancies.

glsl-syntax

Copperbox revision 2712.

I've picked up on the old GL Shading Language parser and pretty printer. It will be useful to change the pretty printer to use hpj-pretty-expr as the GL Shading Language is big enough to be considered industrial strength.

Clearly I hadn't discovered Hughes lists when I first worked on GLSL as I was using Data.Seq in the syntax tree so I could build with snoc-ing.

There is some connection between shading languages and Csound and Supercollider instrument languages. Both types of language essentially describe what goes on in a single iteration of a rendering loop.

hpj-pretty-expr

Copperbox revision 2711.

I've changed languages to only use one module - this should make for a better user API. I've worked up the Ocaml printers, the other languages need work.

hpj-pretty-expr

Copperbox revision 2710.

I've started a new project for pretty printing expressions.

The base code is from Norman Ramsey's paper "Unparsing Expressions With Prefix and Postfix Operators". My hypothesis is that if I define sets of expression / operator printers for languages like C or Haskell people can use the library and get good parenthesized pretty printing with only a little more code than writing a naive (brackets everywhere) pretty printer.

orchsyn

Copperbox revision 2709.

I've got a bit stuck with Orchsyn due to building code within a monad. The do-notation seems to make the embedded language a statement language, but this means I don't know what types the opcode built-ins should be (so they can account for arity of the result).

As an alternative, I've be experimenting using the tagless-final style to embed an expression language with sharing within normal Haskell (not the do-notation). I'm quite pleased with the results - I've embedded ref cells, lambda and apply, sharing let, if-the-else and primitive apply (for calling built-ins). The only problem is an expression language will need a real compiler - the abstract syntax is too far from Csound's imperative language to just pretty print to Csound.

This commit stores a series of expression languages (adding more features) as I don't want to lose them.

orchsyn

Copperbox revision 2708.

I've added an environment for binding pfields to names at init time. User code can now reference declared pfields without the risk of declaring them twice (orchsyn doesn't have a proper notion of scoping).