Template Haskell

Digging in. Further down the rabbit hole. ASTs. Right, a different syntax than the language, Haskell, itself, somewhat. I am beginning to see why some people have issues with Template Haskell. Wish I had time to understand this fully. The compilation output is in a different dialect - this means effectively having to learn another dialect just to metaprogram in this one. Crap. Beginning to have second thoughts about the usefulness of this. There must be a way to compile to user-level Haskell, at compile-time. Fuck this shit, I don't want to program in non-user-level Haskell, so I'm just going to toy with the dangers of writing a Haskell script that generates another Haskell script, etc.

The whole point of learning a high level scripting language is to have simpler language, damn it. Getting some useful conversations about this off the Freenode channel. Overall, I'm not satisfied with my understanding of Haskell, let alone the lower level ASTs / GHC bytecodes.

Haskell headache. At least this quarter, I don't have to worry about losing a girl, or losing half my life savings, while studying this. Haha.

Figured out Builders. Sorta.

My 2008 Microsoft mouse has finally expired. Not bad 5-year averages on these things.

Web development framework design again. Pen and paper.

Starting with the obvious noobish path of using Show and Read to convert between strings and source code.

Making decent progress on massaging the MVC control flow, for a web framework in Haskell. Chill day.

Staying aligned with priorities. Work first, hobbies second. Hobbies are giving me a headache, though. Actually, more like a brain freeze.

Recalling a pattern that I used in an Erlang web framework. Ah, yes. From CakePHP. The controller should return control to a renderer.

Breaktime.

Learning the limit of module/interface import/export flexibility in Haskell.

Bed time again.

Toast and coffee - maillard reactions all the way.

All I want is for my grasp of Haskell to equal my grasp of Erlang. That's all...

About to attempt an OOPesque encapsulation of library functions. I hope this doesn't go awry.

Codefu is hard today. :( Rest. Then more practice. Plumbing, plumbing, plumbing.

Named fields in Haskell data constructors: just sugar - so I need to pass the data type definition around somehow, perhaps via a commonly imported library. Sticking to strategy of using simple data types. Avoiding Data.Map until I run out of options.

Ok. Passing a single library around (using symlinks, because it's hard to call a library file from a parent directory). But now I have much boilerplate. Hmm. So much for encapsulation. I shouldn't need to invent a DSL... or is that just the Haskellian way.

Time, perhaps, to read up on packaging things with .cabal files.

It seems hard to do MVC-style separation of concerns, inversion of control etc, in Haskell. Maybe I am missing something.

Something about the mechanism for variable interpolation in Hamlet irks me. If variables to-be-interpolated need to be top-level-entities in the same module as the function containing the hamlet, then... this seems to mean that I need one module per ACTION, not per controller, just to enable proper encapsulation. :-S

Okkkie... I might have figured out that we can meet Hamlet's variable scoping requirements by rendering views in do notation. So the scope is contained very closely, while variables don't have to be in a module of their own.

Maybe I'm just slow at learning this :(

Almost certainly, actually.

On to try Data.Dynamic, and to relook Typeable.

HOLY SHIT, dynamic URL routing in Haskell... it works! #thatFuckingTookAWhile #dataDotDynamic

So much for Template Haskell. But I might end up having to use it to reduce boilerplate anyway. Maybe not. We'll see.