First of all, congrats on the release! Just one small quibble with your documentation: there are implementations of Haml in Lua <ttp://github.com/norman/lua-haml> and Perl<http://github.com/vti/text-haml> that are nearly syntactically equivalent to Ruby's Haml. We've even gone so far to create a set of cross-platform of specs that is used by these three implementations, as well as by implementations in .Net<http://github.com/lanwin/NHaml_v3>and PHP <http://github.com/dxw/Fammel>.
The original Haml *interpreter* targets only one platform (i.e., Ruby), but the Haml *language* is not tied to Ruby, other than borrowing some of its syntax. So I think it's inaccurate to say the shpaml is "less targeted at one particular platform." The situation is in fact quite the opposite; shpaml currently only exists for Python and Javascript, while there are Haml implementations for Ruby, Python, .Net, PHP, Lua, Perl, and even Erlang. Regards, Norman On Tue, Jan 26, 2010 at 3:52 PM, Steve Howell <showel...@yahoo.com> wrote: > On Jan 26, 8:26 am, Neil Funk <infinitedownt...@gmail.com> wrote: > > Thanks for your contribution! I can tell you put a lot of effort > > into the presentation, what with the tutorial and FAQ and live demo. > > I'm not a heavy HAML user, so take my opinions for only what they're > > worth. > > Opinions welcome! > > > > Having only played on the live demo without trying to code anything > > of my own, I don't have a good feeling for how (and how well) you > > allow access to the host server-side language. The nice thing about > > HAML is that = and - mean that ruby code follows. It seems you're > > just passing the code through with the rest of the text. The downside > > of this seems to be that you would have to delimit that code with > > markers native to that language: back to using lots of <% %> and <? ?> > > pairs. With your focus on extreme terseness, I would think this would > > be something you'd really want to address - perhaps in the same way > > HAML does. > > > > You are correct that shpaml provides no sugar for the target template > language, which in my case is Django. > > The main rationale for that is simplicity and versatility, so that it > can work with other templating languages. > > My initial version actually did have Django support, but I got some > pushback on it, which looking back, I am not sure I still completely > agree with. So there is a chance I will try to integrate more fully > with Django or other template languages down the road. > > > Some quick opinions/questions about the syntax. In your FAQ, you > > say you strive "for total elimination of syntax, particularly with > > block tags." The most important thing for syntax (other than > > correctness, of course) is regularity, and I think you should take > > another overall look at that aspect. > > You say you "[dispense] with the need for percent tags in front of > > block tags." But the purpose of those % tags is to distinguish the > > tags from other types of text. Without some means for that, you (the > > parser) have to *guess* what is meant. (Or maybe you have some > > complex-yet-deterministic method to decide this, but the point is the > > user is still for the most part left guessing.) Consider the following > > ambiguous SPHAML example: > > p > > p | > > p | p > > p > > p > > p > > p | > > p | p > > The pipe syntax can lead to ambiguity in theory, but in practice I've > found it easy to get it right. > > There is nothing at all complex-yet-deterministic going on under the > hood; in fact, shpaml is brutally dumb about HTML, except when it > comes to inserting div/id/class. The preprocessor assumes the > designer knows best, and it just marks up text according to > indentation level and/or position with respect to the pipe. > > > What that actually yields is: > > p > > p | > > <p>p</p> > > <p> > > p > > </p> > > <p> > > p | > > <p>p</p> > > </p> > > > > Is that what you would expect to get? Is that what everyone would > > reasonably expect? Of course that's a contrived example and not very > > realistic, BUT it's important because the syntax ambiguity that it > > exposes will definitely come up at some point in a larger project. > > Although your example is indeed a little contrived, your underlying > point is well taken. > > In my own use, the ambiguity hasn't really presented any real world > problems, but of course I wrote the parser so am less vulnerable to > getting tripped up to the ambiguities than other users might be. > > > > For the price of one character per tag, there's no guessing at > > all. Suggested compromise for ease/brevity: Maybe instead of using a % > > use a character that saves you from having to hit the shift key, like > > -,/'; > > There already is syntax to relieve the ambiguity; that's what the pipe > is for. > > > Same observation on your "singleton tag" syntax: > > > hr > > If you're going to use a special syntax form there, why not for all tags? > > > > Singleton tags are just strange to begin with, in general, so I do not > mind giving them a slightly heavier syntax. I actually want them to > stand out from structural tags like table/ol/ul/etc. (no syntax) and > content (either indented or prefixed by a pipe). > > > On final thing - while going through the tutorial, I did an experiment > > that I think reveals a bug: > > > > .Goodbye .bye > > l8r! > > > > Produces invalid HTML that probably is not what you'd intend: > > <div .bye class="Goodbye"> > > l8r! > > </div> > > > > Good catch. You can say ".Goodbye.bye" now to get the intended > result, but I agree that the space should be allowed. > > > Keep on codin' > > -Neil > > Will do! Thanks for the feedback. > > -- > You received this message because you are subscribed to the Google Groups > "Haml" group. > To post to this group, send email to h...@googlegroups.com. > To unsubscribe from this group, send email to > haml+unsubscr...@googlegroups.com <haml%2bunsubscr...@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/haml?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to h...@googlegroups.com. To unsubscribe from this group, send email to haml+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/haml?hl=en.
