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

[Max Cantor]

On Dec 31, 2010, at 1:48 PM, Michael Snoyman wrote:

> 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.
Fully agree with standardizing it.  

About adding things like pattern matching and other complexities, I'd suggest not doing that.  things like pattern matching can be readily address with local function bindings in the haskell function that calls the hamlet template.  

I've personally moved in that direction of using a lot of little bindings like that to make my hamlet code as simple as possible.

Max

> 
> 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
>> 
>>