Python Implemention of HAML, but a bit extended

[dasacc22]

Aah geez I feel like I'm spamming nex342, he left a comment on my blog
regarding DAML, what started out as a HAML implementation in python.
But now its starting to feel more like "DAML, it's like HAML"

You can find the github here,
http://github.com/dasacc22/DAML

Its still very experimental but includes some basic unit tests to
demonstrate some of the current functionality (though i just broke two
of them in this last commit, not the parser but an extension).

Specifically though he asked about my syntax choices. In DAML I am
using a colon for any expression declared (except for variables which
I'll touch on in a second). I'm really open for debate here about
this, but so here's some examples

:my_var = 'test'
:html = 'this <strong> rocks'
:include('header.daml')
#content {my_var}
.footer {html:safe}
:block realfooter
#realfooter this is the real
deal here.
%span 2010

Essentially, there is no distinguishment among the various option that
HAML has. The idea for DAML was simply to unify many of the parts to
their lowest common denominators. For-Loops, If-Statements, Function-
Calls, Variables. Yeah and "while" and all that jazz too (though id
say the LCD here is Python-Eval and string.Formatter), but point
being, look at function-calls. HAML features a seperate syntax for
what essential amounts to nothing more then a function call.

Im not aware how extensible HAML (ive never used it nor do i program
ruby), but say I extend it with my function markdown

def markdown(s):
return md.parse(s)

now If i equate this in HAML vs using it as a text filter

=markdown('some content')

:markdown
some content

Buy why the difference? Why not simply

=markdown
some content

and in documentation, explain to users "Hey, you can call all these
fancy filters and extensions one way, inline, or you can mix plain
text content with function calls with a simple syntax and the parser
makes it inline for you". This unification I think, for DAML, is
important for ease of extensibility and simplicity. You can declare a
function in the document (well there wouldn't be a markdown processor
in the sandbox, but for the sake of consistency)

:def markdown(s):
: return md.parse(s)

%body
:markdown
some content

Or a more likely scenario, you write your extension on your backend
and update the sandbox to include it. There are no limits or
constraints placed on its usage. Is this the case with HAML? Is it
either a filter or its not? Why the choice to declare text filters
special? Why even call it a text filter when such a syntax could be
useful for other things? For example consider the following I have
working in daml

--- overlay.daml ---
%body
:block header
%h1 My Site Title
%ul
%li and so on..
:block content
:block footer
#footer.legalese 2010

--- index.daml ---
:extends('overlay.daml')

:block content
.main here i can do anything I would normally do
when writing up my documents like
{variables} or embedded :func_calls('for output')

--- backend.py ---
def block(s):
s = s.splitlines()
s = parse(s)
# some jazz in here
sandbox['__blocks__'][s[0]] = s[1:]
return

I feel like the variation of syntax in HAML is more of a constraint
then anything. But I would love to hear some debate and opinion while
im still in such an early stage of DAML so something doesn't sneak up
on me later.

Thanks,
Daniel

--
You received this message because you are subscribed to the Google Groups "Haml Dev" group.
To post to this group, send email to haml...@googlegroups.com.
To unsubscribe from this group, send email to haml-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/haml-dev?hl=en.

[Hampton]

Daniel-

I just wanted to say... good work! When we first started working on Haml,
the plan was to have "Haml-like languages" where we allow for different
styles and approaches, but with some of the same bits of philosophy.

Sounds like that's what you are doing here. Doing a Haml-like language.

And, I say... good on ya!

-hampton.

[dasacc22]

I love the ideals of Haml for laying out the overall document
structure. Speaking from my Daml experience, I first started using it
to convert my domain to work out bugs and missing features that would
crop up. I remember writing the Daml above the xsl then i erased the
xsl. "oh crap" i thought, i must have missed something, this doesn't
look right, its to short. Double checking, noo no, its all here.

Then the other day I wrote this bit up

:subs = ['www', 'js', 'vizi', 'gitview']

%ul
:for sub in subs:
%li
%a(href={sub}.dasa.cc) {sub}

now I've been using XSL and as far as I can recall, no arrays. So
doing the above, I would have to extend my xml document server side
with the subs. But that doesn't belong there! Granted I have a really
easy way to extend a response xml document by default for various
uri's, but it just doesn't belong there. So i would end up typing
stuff like the above out manually.

I have been roughly considering css attributes following more closely
to css stuff, but i dunno..

%a[href={sub}.dasa.cc][more=stuff]

> > For more options, visit this group athttp://groups.google.com/group/haml-dev?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups "Haml Dev" group.
> To post to this group, send email to haml...@googlegroups.com.
> To unsubscribe from this group, send email to haml-dev+u...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/haml-dev?hl=en.