4 ms·

If your goal wasn't "use s-expr" and it isn't a lisp interpreter, the tagline probably shouldn't be "Produce HTML from S-Expressions" and the project shouldn't

If your goal wasn't "use s-expr" and it isn't a lisp interpreter, the tagline probably shouldn't be "Produce HTML from S-Expressions" and the project shouldn't be named "lisp-to-html"; it should be "Write HTML with parentheses".

lelanthran 3y ago
> If your goal wasn't "use s-expr" and it isn't a lisp interpreter, the tagline probably shouldn't be "Produce HTML from S-Expressions" and the project shouldn't be named "lisp-to-html"; it should be "Write HTML with parentheses". You're right maybe it shouldn't be called "Lisp-ish". But, the sources really are s-expressions with an additional ':' marker for attributes, just not Lisp s-expressions with the ':' marker. So "Write HTML with parenthesis" would be less accurate than "Emit HTML from S-expressions".
- zarzavat 3y ago
  Who is your target audience? If it’s Lispers then you need to make the format macro-friendly, if it’s not Lispers then you need to figure out who else likes sexprs but not Lisp? You could replace the = sign with a space, then you can have (a :href “/news”). Perhaps ::required for an empty attribute. This makes it better for macros.
  - lelanthran 3y ago
    > Who is your target audience? It's not Lispers. > If it’s Lispers then you need to make the format macro-friendly, if it’s not Lispers then you need to figure out who else likes sexprs but not Lisp? Well, it depends. I like Lisp just fine, but all the Lisp ways of producing HTML are extremely unergonomic for those not already in the Lisp ecosystem. Someone below posted a link to the clwiki page (I think, not sure) for a list of HTML-generation libraries. I've used some of these before, and they require the user to actually know Lisp well enough to program in Lisp. I wanted something I can hand off to a junior who doesn't know any Lisp (and doesn't really want to), while still having something that makes it easier to type out HTML. The `l2h` program is a compromise of sorts between ergonomics and flexibility. It's more effort to use actual Lisp, but you get more in return when you do. It's less effort to use `l2h`, but there are more limits when you do. > You could replace the = sign with a space, then you can have (a :href “/news”). Perhaps ::required for an empty attribute. This makes it better for macros. I made a note of this. You're correct about it being better for Lispy macros. Another responder elsethread pointed out a few things that could benefit the usage (imports, macros) while maybe not adding too much "cognitive overload" (AKA Too Much Lisp). This project has only had about 6hrs thrown at it so far, so it is still early days. I do appreciate your feedback. Thank you.
    - kazinator 3y ago
      > Lisp ways of producing HTML are extremely unergonomic for those not already in the Lisp ecosystem. Sure; pedaling a road bike is very unergonomic for someone who is jogging next to it. Makes sense.
      - lelanthran 3y ago
        > Sure; pedaling a road bike is very unergonomic for someone who is jogging next to it. Exactly! There's no exhortation to turn joggers into bikers. Joggers on exercise forums aren't told to take up biking when they want to increase their distance. It's exactly the same as asking developers to take up Lisp to use a non-Lisp tool.
  - em-bee 3y ago
    i learned lisp, but i don't use it actively. so macros don't matter for me as much, but i have written a few parsers for s-expressions in other languages, most notably i have one in javascript. what is critical for that parser is that parentheses () do the grouping, and that whitespace is the separator between keywords and values. with class=foo you introduce another separator, complicating the code needed to parse this. if you could use a space here, then i could use my already existing parser to convert this into json or even directly into html without needing any additional code to figure out class values. simple s-expression parsers in many languages can be found here: https://rosettacode.org/wiki/S-expressions https://rosettacode.org/wiki/S-expressions
    - lelanthran 3y ago
      To keep the rules simple (i.e. people shouldn't need to learn Lisp to write the source input) I don't want context to determine what `(foo :bar baz)` means. With the current two rules, the symbol after any `(` is always the tagname. There are no exceptions based on context. The input `(foo (bar baz))` has meaning `<foo><bar>baz</bar></foo>`. This meant I needed a different way to indicate attributes. I used the ':', resulting in needing a way to specify the optional attribute value, so I used the '='. I still have to decide on a few more things, so I'm still considering changing the way attributes are specified, but I don't think I will ever make it contextual.
      - em-bee 3y ago
        ok, that's reasonable. though you could specify attributes as (:foo bar) so that "(:" always starts an attribute. attributes without value could still be written without surrounding parentheses although always requiring them would make parsing easier.
        lelanthran 3y ago
        > ok, that's reasonable. though you could specify attributes as (:foo bar) so that "(:" always starts an attribute. attributes without value could still be written without surrounding parentheses although always requiring them would make parsing easier. There's been a lot of pushback on the attributes, so something there has got to change. I'm considering all the changes (including your suggestion too. Thanks, BTW). The downside #1 with '(:' , from a usage perspective, is that '(' is no longer context-free and is inconsistent. For example, you could not produce a tree with `<:placeholder:>`[1]. Downside #2 is that it's just cumbersome to type (The whole point of this was to reduce the clunkiness of typing out HTML). Four attributes which would be :name1=value1 :name2=value2 :name3=value3 :name4=value4 turn into (:name1 value1) (:name2 value2) (:name3 value3) (:name4 value4) I think if I adopt the reverse-smiley, I may as well adopt it in a way that is consistent - reserve all lists which has a ':' as the first symbol. Then, even though it's an exception to the general rule, it's a rule itself so users can easily abide by it and it opens up possibility for new functionality without breaking existing documents. For example `(:attrs ...)`, and `(:import ...)` and `(:set-var ...)` etc. [1] I don't know why a user would want this, but it's probable. After all, I use a similar syntax currently in LaTeX files so that sed can perform replacements before pdflatex generates my invoices using the transformed files.

lelanthran 3y ago

> If your goal wasn't "use s-expr" and it isn't a lisp interpreter, the tagline probably shouldn't be "Produce HTML from S-Expressions" and the project shouldn't be named "lisp-to-html"; it should be "Write HTML with parentheses". You're right maybe it shouldn't be called "Lisp-ish". But, the sources really are s-expressions with an additional ':' marker for attributes, just not Lisp s-expressions with the ':' marker. So "Write HTML with parenthesis" would be less accurate than "Emit HTML from S-expressions".

zarzavat 3y ago
Who is your target audience? If it’s Lispers then you need to make the format macro-friendly, if it’s not Lispers then you need to figure out who else likes sexprs but not Lisp? You could replace the = sign with a space, then you can have (a :href “/news”). Perhaps ::required for an empty attribute. This makes it better for macros.
- lelanthran 3y ago
  > Who is your target audience? It's not Lispers. > If it’s Lispers then you need to make the format macro-friendly, if it’s not Lispers then you need to figure out who else likes sexprs but not Lisp? Well, it depends. I like Lisp just fine, but all the Lisp ways of producing HTML are extremely unergonomic for those not already in the Lisp ecosystem. Someone below posted a link to the clwiki page (I think, not sure) for a list of HTML-generation libraries. I've used some of these before, and they require the user to actually know Lisp well enough to program in Lisp. I wanted something I can hand off to a junior who doesn't know any Lisp (and doesn't really want to), while still having something that makes it easier to type out HTML. The `l2h` program is a compromise of sorts between ergonomics and flexibility. It's more effort to use actual Lisp, but you get more in return when you do. It's less effort to use `l2h`, but there are more limits when you do. > You could replace the = sign with a space, then you can have (a :href “/news”). Perhaps ::required for an empty attribute. This makes it better for macros. I made a note of this. You're correct about it being better for Lispy macros. Another responder elsethread pointed out a few things that could benefit the usage (imports, macros) while maybe not adding too much "cognitive overload" (AKA Too Much Lisp). This project has only had about 6hrs thrown at it so far, so it is still early days. I do appreciate your feedback. Thank you.
  - kazinator 3y ago
    > Lisp ways of producing HTML are extremely unergonomic for those not already in the Lisp ecosystem. Sure; pedaling a road bike is very unergonomic for someone who is jogging next to it. Makes sense.
    - lelanthran 3y ago
      > Sure; pedaling a road bike is very unergonomic for someone who is jogging next to it. Exactly! There's no exhortation to turn joggers into bikers. Joggers on exercise forums aren't told to take up biking when they want to increase their distance. It's exactly the same as asking developers to take up Lisp to use a non-Lisp tool.
- em-bee 3y ago
  i learned lisp, but i don't use it actively. so macros don't matter for me as much, but i have written a few parsers for s-expressions in other languages, most notably i have one in javascript. what is critical for that parser is that parentheses () do the grouping, and that whitespace is the separator between keywords and values. with class=foo you introduce another separator, complicating the code needed to parse this. if you could use a space here, then i could use my already existing parser to convert this into json or even directly into html without needing any additional code to figure out class values. simple s-expression parsers in many languages can be found here: https://rosettacode.org/wiki/S-expressions https://rosettacode.org/wiki/S-expressions
  - lelanthran 3y ago
    To keep the rules simple (i.e. people shouldn't need to learn Lisp to write the source input) I don't want context to determine what `(foo :bar baz)` means. With the current two rules, the symbol after any `(` is always the tagname. There are no exceptions based on context. The input `(foo (bar baz))` has meaning `<foo><bar>baz</bar></foo>`. This meant I needed a different way to indicate attributes. I used the ':', resulting in needing a way to specify the optional attribute value, so I used the '='. I still have to decide on a few more things, so I'm still considering changing the way attributes are specified, but I don't think I will ever make it contextual.
    - em-bee 3y ago
      ok, that's reasonable. though you could specify attributes as (:foo bar) so that "(:" always starts an attribute. attributes without value could still be written without surrounding parentheses although always requiring them would make parsing easier.
      - lelanthran 3y ago
        > ok, that's reasonable. though you could specify attributes as (:foo bar) so that "(:" always starts an attribute. attributes without value could still be written without surrounding parentheses although always requiring them would make parsing easier. There's been a lot of pushback on the attributes, so something there has got to change. I'm considering all the changes (including your suggestion too. Thanks, BTW). The downside #1 with '(:' , from a usage perspective, is that '(' is no longer context-free and is inconsistent. For example, you could not produce a tree with `<:placeholder:>`[1]. Downside #2 is that it's just cumbersome to type (The whole point of this was to reduce the clunkiness of typing out HTML). Four attributes which would be :name1=value1 :name2=value2 :name3=value3 :name4=value4 turn into (:name1 value1) (:name2 value2) (:name3 value3) (:name4 value4) I think if I adopt the reverse-smiley, I may as well adopt it in a way that is consistent - reserve all lists which has a ':' as the first symbol. Then, even though it's an exception to the general rule, it's a rule itself so users can easily abide by it and it opens up possibility for new functionality without breaking existing documents. For example `(:attrs ...)`, and `(:import ...)` and `(:set-var ...)` etc. [1] I don't know why a user would want this, but it's probable. After all, I use a similar syntax currently in LaTeX files so that sed can perform replacements before pdflatex generates my invoices using the transformed files.