I disagree, HTML is a datastructure like any other, and it should be easy to build one without going through an untyped string or an auxiliary file. It's painful to make one html file per renderable item -- and debugging takes more time (once you've found who's responsible for rendering it, you need to check the corresponding template, so there's an additional step in your way.) There's no semantic in using the filesystem to organize your templates: it's the code that specify the meaning, and your programming language provides more organization units than your FS (or should we do "one function per file and one directory per class/module"?).
(Also, the obvious filename typo vs static checking of function names; and the fact that your template is going to contain some rudimentary form of code or force you to obfuscate your intent even more.)
Which is why I don't like the proposal: it's not unifying HTML and Erlang, it's compiling string macros into Erlang. Is there any reasons not to embed the interpolation in Erlang directly?
hello(N) ->
Name = <em><? N ?></em>,
<#>
<p>Hello <? Name ?></p>
<p>The <#></#> lets you group
multiple elements, that don't
have a parent, as a single value.</p>
</#>.
(Whether the <X></X> is doing simple string interpolation, or is HTML-smart is left for the reader to decide -- it's certainly overkill for server-side only code.)
Which is why I don't like the proposal: it's not unifying HTML and Erlang, it's compiling string macros into Erlang. Is there any reasons not to embed the interpolation in Erlang directly?
(Whether the <X></X> is doing simple string interpolation, or is HTML-smart is left for the reader to decide -- it's certainly overkill for server-side only code.)