[web-devel] Hamlet variable interpolation syntax [previously: A few questions about Yesod]

Michael Snoyman michael at snoyman.com
Fri Dec 31 06:48:18 CET 2010


On Fri, Dec 31, 2010 at 7:33 AM, Max Cantor <mxcantor at gmail.com> wrote:
> I agree with just dropping the dot syntax and using spaces for function application to be consistent with haskell syntax.
>
> Another inelegance of the syntax is the difference between:
>
> $xxx
> and
> $yyy$
>
> The first requires xxx to be a special hamlet keyword (forall, if, maybe) and the second just references a normal haskell value. So, the second $ on a line sort of changes the meaning of the leading $.  Its not terrible and I've gotten used to it, but I imagine it could be a bit confusing at first.

If others feel the same way, I have no problem using a different
leading character than dollar signs for statements. Or- now that we're
considering truly breaking changes- we could resurrect the possibility
of standardizing variable interpolation character for Hamlet, Julius
and Cassius. I suppose we could try percent sign for variable
interpolation (like Julius) and then keep the dollar sign for
statements.

Totally different topic: right now, Cassius directly generates a
blaze-builder value, which makes it impossible to do cooler features
like automatically merging CSS blocks and removing duplicates. I have
on my TODO list to produce instead an intermediate data value to allow
us to do more sophisticated analysis before code generation.

Michael

> -מרדכי
>
> On Dec 31, 2010, at 12:08 PM, Alexander Dunlap wrote:
>
>> 2010/12/30 Michael Snoyman <michael at snoyman.com>:
>>> On Thu, Dec 30, 2010 at 8:23 PM, Alexander Dunlap
>>> <alexander.dunlap at gmail.com> wrote:
>>>> 2010/12/30 Michael Snoyman <michael at snoyman.com>:
>>>>> On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop <iustin at google.com> wrote:
>>>>>> On Thu, Dec 30, 2010 at 03:09:16PM +0200, Michael Snoyman wrote:
>>>>>>> Very good questions, answers below.
>>>>>>>
>>>>>>> On Thu, Dec 30, 2010 at 1:01 PM, Iustin Pop <iustin at google.com> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I just started looking at Yesod and its associated libs (hamlet, etc.)
>>>>>>>> and it is very interesting, thanks.
>>>>>>>>
>>>>>>>> However, I'm confused by a few things and the docs are not helping, so
>>>>>>>> please bear my beginner questions.
>>>>>>>>
>>>>>>>> First: hamlet uses '.' as function application, instead of the usual
>>>>>>>> space. How can I then use a qualified name (e.g. Data.List.nub)? If I
>>>>>>>> use it normally, it errors out on me. Must be something very trivial but
>>>>>>>> I cannot find a way.
>>>>>>>
>>>>>>> Hamlet uses both '.' and space as function application, and therefore
>>>>>>> qualified names are not supported. I work around this usually by
>>>>>>> creating an alias for the function I want locally. I know this can be
>>>>>>> inelegant; if you have any ideas, I'm all ears.
>>>>>>
>>>>>> Yep, that's what I'm using too now, but it becomes cumbersome quickly,
>>>>>> especially when using records…
>>>>>>
>>>>>> I'm not sure what was the original impetus to use . (too) as function
>>>>>> application if space is accepted too. I'm thinking reverting that
>>>>>> decision would make the code look more like regular Haskell.
>>>>>>
>>>>>> A simpler alternative (not sure if easily doable) would be to allow
>>>>>> escaping of the dot, e.g. $Data\.List\.nub.mylist$; it's ugly, but…
>>>>>
>>>>> It actually went the other way: period first, and space added by
>>>>> request. Originally, Hamlet variables were not directly mapped to
>>>>> Haskell function calls. Instead, it was meant to parallel variable
>>>>> lookup in common template languages from the object-oriented world.
>>>>> Another impetus is because of statements like forall and maybe:
>>>>>
>>>>> $forall allPeople.myFamily person
>>>>>    %li $person name$
>>>>>
>>>>> This can also be written as
>>>>>
>>>>> $forall (allPeople myFamily) person
>>>>>
>>>>> You could argue that the latter is more legible; my problem with the
>>>>> space is for cases with more than two functions in the chain. $foo bar
>>>>> baz$ gets converted to the Haskell code "foo (bar baz)".
>>>>>
>>>>> I'll admit that this whole situation bothers me as well. Hamlet 0.7 is
>>>>> currently in the works, and I don't mind introducing some major
>>>>> changes. I think this issue deserves some attention: what does
>>>>> everyone else think? Maybe we should start a separate thread to
>>>>> discuss this issue in particular.
>>>>>
>>>>
>>>> Would there be a problem with removing the dot syntax entirely and
>>>> just having regular Haskell syntax for variable interpretation? That
>>>> might be more flexible and easier to learn.
>>>>
>>>> Alexander
>>>>
>>>
>>> I'm beginning to lean that direction as well. As far as forall/maybe
>>> syntax, I propose adding a comma:
>>>
>>> $forall foo bar baz, bin
>>>
>>> I specifically want to avoid using a keyword such as in, since we
>>> shouldn't be limiting the variables names available, and I think it's
>>> not very well distinguished from the surrounding words.
>>>
>>> Are you recommending not allowing hierarchical functions, or did I
>>> misunderstand?
>>>
>>> Michael
>>>
>>
>> Could it just be interpreted as-is by the compiler? (Does TH allow
>> plugging in some literal code?) Then hierarchical functions, lambda
>> expressions, whatever would all be allowed "for free". (The only
>> problem would be the delimiter.)
>>
>> Alex
>>
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>
>



More information about the web-devel mailing list