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

[Max Cantor]

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.

-מרדכי

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