Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Produce HTML from S-Expressions

github.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Produce HTML from S-Expressions

#51

Post by em-bee »

lelanthran wrote: post #50
em-bee wrote: post #43

Earlier quoted context omitted.

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

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 ` baz `. This meant I needed a different way to indicate attributes. I used the ':', resulting in needing…

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.

Re: Produce HTML from S-Expressions

#52

Post by ptx »

sph wrote: post #2

(h1 :disabled Hello world!) (div :class="alert" So long, and (b thanks) for all the (em fish)) I hate that syntax for attributes. :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. Not a fan of the bare words instead of strings either, which means this cannot be naively evaluated by a Lisp. I…

With this merged attribute syntax, since each key-value combination is a separate symbol and since symbols are interned, doesn't this mean that all the attribute values (and not just the keys) end up interned?

Do Lisp implementations usually garbage-collect interned symbols when they're no longer used?

Re: Produce HTML from S-Expressions

#53

Post by kazinator »

ptx wrote: post #52
sph wrote: post #2

(h1 :disabled Hello world!) (div :class="alert" So long, and (b thanks) for all the (em fish)) I hate that syntax for attributes. :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. Not a fan of the bare words instead of strings either, which means this cannot be naively evaluated by a Lisp. I…

With this merged attribute syntax, since each key-value combination is a separate symbol and since symbols are interned, doesn't this mean that all the attribute values (and not just the keys) end up interned? Do Lisp implementations usually garbage-collect interned symbols when they're no longer used?

Firstly, obviously yes for un-interned.

TXR Lisp:

  This is the TXR Lisp interactive listener of TXR 291.
  Quit with :quit or Ctrl-D on an empty line. Ctrl-X ? for cheatsheet.
  I'm confused; is this piano recital Rimsky-Korsakov or Wernicke–Korsakoff?
  1> (progn [finalize (gensym "foo-") prinl] nil)
  nil
  2> (sys:gc)
  #:foo-0012
  t
  3> (sys:gc)
  t
We make a gensym whose name starts with foo-. We register a GC finalizer for it which is the prinl function (print, with newline).

Then when we manually invoke GC, it gets collected; we see the print.

Internet symbols cannot be collected, normally, because they are always used: they are registered in their package.

TXR Lisp has weak packages, though. A weak package will purge a symbol that is not reachable other than through the package.

  1> (make-package "abc" t)  ;; t argument here means weak
  #
  2> (progn [finalize (intern "xyz" *1) prinl] nil)
  nil
  3> (sys:gc)
  abc:xyz
  t
  4> (package-symbols *1)
  nil
  5>
Don't know if other Lisp people thunk of this one, but there it is.

I don't think I exposed this weak property through the defpackage macro. It's intended for specific scenarios, like reading data in the context of a package.

Re: Produce HTML from S-Expressions

#54

Post by kazinator »

lelanthran wrote: post #42
zarzavat wrote: post #41

Earlier quoted context omitted.

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.

> 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) f…

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

Re: Produce HTML from S-Expressions

#55

Post by kazinator »

lelanthran wrote: post #4
sph wrote: post #2

(h1 :disabled Hello world!) (div :class="alert" So long, and (b thanks) for all the (em fish)) I hate that syntax for attributes. :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. Not a fan of the bare words instead of strings either, which means this cannot be naively evaluated by a Lisp. I…

> :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. I hear you, but I wasn't aiming for leveraging the power of macros. Using `((class . "alert"))` does not provide any benefits over :class="alert". > Not a fan of the bare words instead of strings either, which means this cannot be naively e…

If My and first just stand for themselves, you're not interpolating variables; where is the templating?

Also, what if you don't want a space between the bold hello and emphasized world? Or between first and hello?

Re: Produce HTML from S-Expressions

#56

Post by lelanthran »

kazinator wrote: post #54
lelanthran wrote: post #42

Earlier quoted context omitted.

> 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) f…

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

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

Re: Produce HTML from S-Expressions

#58

Post by lelanthran »

kazinator wrote: post #55
lelanthran wrote: post #4

Earlier quoted context omitted.

> :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. I hear you, but I wasn't aiming for leveraging the power of macros. Using `((class . "alert"))` does not provide any benefits over :class="alert". > Not a fan of the bare words instead of strings either, which means this cannot be naively e…

If My and first just stand for themselves, you're not interpolating variables; where is the templating? Also, what if you don't want a space between the bold hello and emphasized world ? Or between first and hello ?

> If My and first just stand for themselves, you're not interpolating variables; where is the templating?

Templating wasn't mentioned (yet. looking at the feedback I got, some avenues are open for some sort of templating).

> Also, what if you don't want a space between the bold hello and emphasized world?

Then you don't put one in?

     $ echo "(div My first (b hello)(em world)) " | ./l2h -s
     My first helloworld
> Or between first and hello?

Again, don't put one in:

    echo "(div My first(b hello) (em world))" | ./l2h -s
    My firsthello world
I think that that is is intuitive as it can get for people who know HTML: space-emission matches what you would expect for HTML.

If you look at the git history, I spent a lot of time making sure that the parsing of whitespace and newlines made sense from an HTML perspective, not from a Lisp perspective.

Re: Produce HTML from S-Expressions

#59

Post by lelanthran »

em-bee wrote: post #51
lelanthran wrote: post #50

Earlier quoted context omitted.

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 ` baz `. This meant I needed a different way to indicate attributes. I used the ':', resulting in needing…

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.

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

Re: Produce HTML from S-Expressions

#60

Post by lelanthran »

fouc wrote: post #48
captainbland wrote: post #45

Earlier quoted context omitted.

Yeah I think you want some way to clearly differentiate between tags and attributes as there are some cases where there are attribute and tags with the same name. E.g. does (body (style "styleinfo")) mean Or styleinfo ?

second example using { } could imply the attribute and ( ) could imply the tag

> second example using { } could imply the attribute and ( ) could imply the tag

Right now the only reserved tokens are '(', ')' and ':'. Everything else is emitted as HTML content. Reserving '{' and '}' for use by the program means that users would have to escape '{' and '}' wherever it occurs in their content.

Post reply on HN