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

[Michael Snoyman]

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