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

[Michael Snoyman]

On Fri, Dec 31, 2010 at 6:08 AM, Alexander Dunlap
<alexander.dunlap at gmail.com> 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
>

I'll have to look again, but I don't think any of those can be
automatically inserted.

Michael