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

newer
Request body parsing in Yesod

older
A few questions about Yesod

Alexander Dunlap

30 Dec 2010 30 Dec '10

6:23 p.m.

2010/12/30 Michael Snoyman :

...

On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop 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 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

Show replies by date

Michael Snoyman

30 Dec 30 Dec

8:45 p.m.

On Thu, Dec 30, 2010 at 8:23 PM, Alexander Dunlap wrote:

...

2010/12/30 Michael Snoyman :

...
On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop 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 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

Felipe Almeida Lessa

31 Dec 31 Dec

12:58 a.m.

On Thu, Dec 30, 2010 at 6:45 PM, Michael Snoyman wrote:

...

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

What about something like $forall bin <- foo bar baz We could even support pattern matches, which would be very useful on some cases: $forall Person name age address <- people I know, I know, bad example, it's just to get the idea across. =) Cheers, -- Felipe.

Mark Bradley

1:45 a.m.

On Fri, Dec 31, 2010 at 11:58 AM, Felipe Almeida Lessa wrote:

...

On Thu, Dec 30, 2010 at 6:45 PM, Michael Snoyman wrote:

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

What about something like

$forall bin <- foo bar baz

I like this syntax, but the comma also works for me.

...

We could even support pattern matches, which would be very useful on some cases:

$forall Person name age address <- people

I know, I know, bad example, it's just to get the idea across. =)

I know it is possible, but the difficulty of bringing in more haskell features into hamlet is that hamlet's interpreter is written from scratch. So unless someone gets an itch to grab a chunk of ghcs source code so we can run it at compile time in a template haskell context. There has to be a better way than reinventing that wheel.

...

Cheers,

-- Felipe.

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

-barkmadley sent from an internet enabled device

Michael Snoyman

5:43 a.m.

On Fri, Dec 31, 2010 at 3:45 AM, Mark Bradley wrote:

...

On Fri, Dec 31, 2010 at 11:58 AM, Felipe Almeida Lessa wrote:

...
On Thu, Dec 30, 2010 at 6:45 PM, Michael Snoyman wrote:

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

What about something like

$forall bin <- foo bar baz

I like this syntax, but the comma also works for me.

I too could go either way, and neither is particularly complicated to implement. A separate question, since it's bugged me for a bit now: there's a minor inconsistency, since maybe is paired with nothing. In theory, it should be just/nothing. However, it still "feels" like maybe is a better choice, though this could just be because I got used to it. Any other thoughts?

...

...
We could even support pattern matches, which would be very useful on some cases:

$forall Person name age address <- people

I know, I know, bad example, it's just to get the idea across. =)

I know it is possible, but the difficulty of bringing in more haskell features into hamlet is that hamlet's interpreter is written from scratch. So unless someone gets an itch to grab a chunk of ghcs source code so we can run it at compile time in a template haskell context. There has to be a better way than reinventing that wheel.

I concur on this one. The one place where I've really considered using pattern match syntax is for tuples, which maybe *should* be implemented now. With proper datatypes, the record accessors are usually very clear. Michael

Alexander Dunlap

4:08 a.m.

2010/12/30 Michael Snoyman :

...

On Thu, Dec 30, 2010 at 8:23 PM, Alexander Dunlap wrote:

...
2010/12/30 Michael Snoyman :

...
On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop 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 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

Max Cantor

5:33 a.m.

New subject: Hamlet variable interpolation syntax [previously: A few questions about Yesod]

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 :

...
On Thu, Dec 30, 2010 at 8:23 PM, Alexander Dunlap wrote:

...
2010/12/30 Michael Snoyman :

...
On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop 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 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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Michael Snoyman

5:48 a.m.

On Fri, Dec 31, 2010 at 7:33 AM, Max Cantor 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 :

...
On Thu, Dec 30, 2010 at 8:23 PM, Alexander Dunlap wrote:

...
2010/12/30 Michael Snoyman :

...
On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop 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 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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Max Cantor

5:52 a.m.

New subject: Hamlet variable interpolation syntax [previously: A few questions about Yesod]

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

...

On Fri, Dec 31, 2010 at 7:33 AM, Max Cantor 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 :

...
On Thu, Dec 30, 2010 at 8:23 PM, Alexander Dunlap wrote:

...
2010/12/30 Michael Snoyman :

...
On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop 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 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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Aur Saraf

7:18 a.m.

While we're on the topic of breaking changes to Cassius: This week I've heard a lecture about Sass[1] and Less[2]. [1] http://sass-lang.com/ [2] http://lesscss.org/ This is Sass: #navbar { $navbar-width: 800px; $items: 5; $navbar-color: #ce4dd6; width: $navbar-width; border-bottom: 2px solid $navbar-color; li { float: left; width: $navbar-width/$items - 10px; background-color: lighten($navbar-color, 20%); &:hover { background-color: lighten($navbar-color, 10%); } } } Less is very similar. There are a few things I've learned: 1. Sass used to have a whitespace-is-significant syntax, but then switched to a CSS-superset syntax like Less, because it let people port their existing CSS by... doing nothing. Remembering all the times I've had to translate CSS to Cassius by hand, I think we should at least have a program like Python's 2to3 that translates a block of CSS to Cassius, if not move to the Sass syntax. 2. Sass supports some nifty features that I wished Cassius had (inheritance and mixins, numerical and color math, mixins with parameters which are like functions...) 3. Sass has Compass[3][4], which is sort of a standard library for CSS, with battle-tested classes that you can mix into your CSS for doing things you tend to do a lot and for doing things in a manner supported as cross-browser as possible. A lot of times, when writing CSS, I wish I'd have that. So that's another point for supporting Sass syntax. [3] http://compass-style.org/ [4] An example (implementation of a) Compass function: @mixin hide-text { $approximate_em_value: 12px / 1em; $wider_than_any_screen: -9999em; text-indent: $wider_than_any_screen * $approximate_em_value; overflow: hidden; text-align: left; } To support Sass syntax, we could either parse it, which is as complicated as parsing CSS, and then reimplement Sass's logic, which isn't very hard but would require us to chase it as it changes, or we could use a plaintext-with-variable-interpolation parser and feed that to the Sass toolset (without any harm to the type safety of the code, and with options to run Sass either in compile-time or in run-time, but it would require the user to install ruby and Sass). Of course, Sass support could be added quite easily on a per-project basis (and I just might do that soon for one of mine), but as I've showed, there are some serious advantages to making it default. -- Aur

Michael Snoyman

8:06 a.m.

OK, I've put up a Wiki page[1] to discuss all of these changes. I think I've put a summary of all the proposals brought up so far; if anyone sees something missing, go ahead and edit it. Feel free to add discussions inline (I think that's better than the discuss page for this). Michael [1] http://wiki.yesodweb.com/Hamlet%200.7%20changes On Fri, Dec 31, 2010 at 9:18 AM, Aur Saraf wrote:

...

While we're on the topic of breaking changes to Cassius:

This week I've heard a lecture about Sass[1] and Less[2]. [1] http://sass-lang.com/ [2] http://lesscss.org/

This is Sass:

#navbar { $navbar-width: 800px; $items: 5; $navbar-color: #ce4dd6;

width: $navbar-width; border-bottom: 2px solid $navbar-color;

li { float: left; width: $navbar-width/$items - 10px;

background-color: lighten($navbar-color, 20%); &:hover { background-color: lighten($navbar-color, 10%); } } }

Less is very similar.

There are a few things I've learned:

1. Sass used to have a whitespace-is-significant syntax, but then switched to a CSS-superset syntax like Less, because it let people port their existing CSS by... doing nothing. Remembering all the times I've had to translate CSS to Cassius by hand, I think we should at least have a program like Python's 2to3 that translates a block of CSS to Cassius, if not move to the Sass syntax.

2. Sass supports some nifty features that I wished Cassius had (inheritance and mixins, numerical and color math, mixins with parameters which are like functions...)

3. Sass has Compass[3][4], which is sort of a standard library for CSS, with battle-tested classes that you can mix into your CSS for doing things you tend to do a lot and for doing things in a manner supported as cross-browser as possible. A lot of times, when writing CSS, I wish I'd have that. So that's another point for supporting Sass syntax. [3] http://compass-style.org/ [4] An example (implementation of a) Compass function:

@mixin hide-text { $approximate_em_value: 12px / 1em; $wider_than_any_screen: -9999em; text-indent: $wider_than_any_screen * $approximate_em_value; overflow: hidden; text-align: left; }

To support Sass syntax, we could either parse it, which is as complicated as parsing CSS, and then reimplement Sass's logic, which isn't very hard but would require us to chase it as it changes, or we could use a plaintext-with-variable-interpolation parser and feed that to the Sass toolset (without any harm to the type safety of the code, and with options to run Sass either in compile-time or in run-time, but it would require the user to install ruby and Sass).

Of course, Sass support could be added quite easily on a per-project basis (and I just might do that soon for one of mine), but as I've showed, there are some serious advantages to making it default.

-- Aur

Michael Snoyman

5:43 a.m.

On Fri, Dec 31, 2010 at 6:08 AM, Alexander Dunlap wrote:

...

2010/12/30 Michael Snoyman :

...
On Thu, Dec 30, 2010 at 8:23 PM, Alexander Dunlap wrote:

...
2010/12/30 Michael Snoyman :

...
On Thu, Dec 30, 2010 at 3:31 PM, Iustin Pop 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 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

5299

Age (days ago)

5300

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Alexander Dunlap
Aur Saraf
Felipe Almeida Lessa
Mark Bradley
Max Cantor
Michael Snoyman

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

tags

participants (6)