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

Show HN: HyTags – HTML as a Programming Language

hytags.org

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Show HN: HyTags – HTML as a Programming Language

#21

Post by embedding-shape »

dragonwriter wrote: post #9
velcrovan wrote: post #7

HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named arguments and the elements as variadic arguments. The example from the link's main page is equivalent to: (button "Say something") (on_click (selection-insert-after (div "Hello, World "))) [apparently HN strips all emoji but you get the idea]

> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise No, its not. If it was, the attribute vs. child element distinction would not exist. HTML (and HTML-inspired XML) syntax is not a trivial alternative to S-expression syntax, it is more complex with additional distinctions. A simplified subset of (HT|X)ML that uses only elements and no attributes is pretty much directyl equivalent to S-ex…

> A simplified subset of (HT|X)ML that uses only elements and no attributes is pretty much directyl equivalent to S-expressions, sure.

Add one more type, like a map, now you have attributes

  (fn btn ()
   (div
    {onClick (fn ())}
    "Click me"))

Re: Show HN: HyTags – HTML as a Programming Language

#22

Post by dhamidi »

lassejansen wrote: post #15
css_apologist wrote: post #11

first let me say i applaud you for experimenting and doing something unconventional - thoughts as i was reading this - ok, so we're programming via an AST vs syntax I think this is interesting, however there's notable downsides - verbosity, dom bloat & debugging A potential upside to this is very odd but interesting meta programming capabilities, since the code should be able to inspect & modify itself fairly easily…

DOM bloat can certainly become a problem when adding lots of code in e.g. table rows. I added functions mainly to be able to move common code into a central place to minimize that problem. You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g. // returns r…

Maybe useful inspiration from TCL: there are many commands that define new variables, which makes modeling the stack unnecessary.

For example:

  lappend responses [dict status 200 body ...]
Appends a new dict to the list held in the variable responses, creating the variable if necessary.

I can see that being an attribute:

Re: Show HN: HyTags – HTML as a Programming Language

#23

Post by lassejansen »

dhamidi wrote: post #22
lassejansen wrote: post #15

Earlier quoted context omitted.

DOM bloat can certainly become a problem when adding lots of code in e.g. table rows. I added functions mainly to be able to move common code into a central place to minimize that problem. You certainly must get used to the stack based approach. I tried to make it more approachable by making stack lookups type based (automatic search for value with matching type) and by using type-prefixed commands, e.g. // returns r…

Maybe useful inspiration from TCL: there are many commands that define new variables, which makes modeling the stack unnecessary. For example: lappend responses [dict status 200 body ...] Appends a new dict to the list held in the variable responses, creating the variable if necessary. I can see that being an attribute:

The main reason for using a stack was reducing verbosity because for short scripts using variables felt unnecessary when the type-prefix of the command already communicates the variable contents. But it could still be a good idea to have a shorter syntax for assigned variables.

Accessing a variables works like this at the moment:
Keeping the dollar syntax, setting the return value to a named variable could look like this:

Re: Show HN: HyTags – HTML as a Programming Language

#25

Post by TeMPOraL »

publicdebates wrote: post #10
lassejansen wrote: post #8

Earlier quoted context omitted.

Exactly, code is data ;)

Not sure how homoiconicity is related to this at all. Macros don't seem involved. But I do think s-expressions are an improvement over HTML in certain scenarios. That said (talking to OP now), why is the control handler outside the button? In actual HTML, we have [button onclick="codeToBeEvaled()"] In this thing, you have [button][onclick [sub-expressions]] With s-expressions, at least you have some semblance of func…

> Not sure how homoiconicity is related to this at all. Macros don't seem involved.

"Code is data" is more general and fundamental idea; it's a fact of nature. Homoiconicity is a way to try and embrace it instead of fighting it.

Re: Show HN: HyTags – HTML as a Programming Language

#26

Post by chajath »

velcrovan wrote: post #7

HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named arguments and the elements as variadic arguments. The example from the link's main page is equivalent to: (button "Say something") (on_click (selection-insert-after (div "Hello, World "))) [apparently HN strips all emoji but you get the idea]

Fun read! https://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions

Re: Show HN: HyTags – HTML as a Programming Language

#27

Post by npn »

dragonwriter wrote: post #9
velcrovan wrote: post #7

HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named arguments and the elements as variadic arguments. The example from the link's main page is equivalent to: (button "Say something") (on_click (selection-insert-after (div "Hello, World "))) [apparently HN strips all emoji but you get the idea]

> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise No, its not. If it was, the attribute vs. child element distinction would not exist. HTML (and HTML-inspired XML) syntax is not a trivial alternative to S-expression syntax, it is more complex with additional distinctions. A simplified subset of (HT|X)ML that uses only elements and no attributes is pretty much directyl equivalent to S-ex…

Have you ever tried parsing html in s-expression languages before?

For example, in elixir parsing html is this syntax: `{html_tag, attributes, children}`.

You indeed can include attributes in s expression

Re: Show HN: HyTags – HTML as a Programming Language

#28

Post by shakna »

dragonwriter wrote: post #9
velcrovan wrote: post #7

HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named arguments and the elements as variadic arguments. The example from the link's main page is equivalent to: (button "Say something") (on_click (selection-insert-after (div "Hello, World "))) [apparently HN strips all emoji but you get the idea]

> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise No, its not. If it was, the attribute vs. child element distinction would not exist. HTML (and HTML-inspired XML) syntax is not a trivial alternative to S-expression syntax, it is more complex with additional distinctions. A simplified subset of (HT|X)ML that uses only elements and no attributes is pretty much directyl equivalent to S-ex…

Every Lisp I know of has SXML either baked in, or as a library because it absolutely can represent the fullness of HTML...

    (parrot (@ (type "African Grey")) (name "Alfie"))
Becomes:

    Alfie
https://www.gnu.org/software/guile/manual/html_node/SXML.htm...

Re: Show HN: HyTags – HTML as a Programming Language

#29

Post by dragonwriter »

shakna wrote: post #28
dragonwriter wrote: post #9

Earlier quoted context omitted.

> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise No, its not. If it was, the attribute vs. child element distinction would not exist. HTML (and HTML-inspired XML) syntax is not a trivial alternative to S-expression syntax, it is more complex with additional distinctions. A simplified subset of (HT|X)ML that uses only elements and no attributes is pretty much directyl equivalent to S-ex…

Every Lisp I know of has SXML either baked in, or as a library because it absolutely can represent the fullness of HTML... (parrot (@ (type "African Grey")) (name "Alfie")) Becomes: Alfie https://www.gnu.org/software/guile/manual/html_node/SXML.htm...

Yes, (HT|X)ML have a semantic model that that can be represented in Lisp syntax, but so does everything else (well, every programming and data representation language, at least.) They don't do it with the same (or simple parallel) single simple syntactic fiundaton as Lisp, but with something more complex.

Re: Show HN: HyTags – HTML as a Programming Language

#30

Post by shakna »

dragonwriter wrote: post #29
shakna wrote: post #28

Earlier quoted context omitted.

Every Lisp I know of has SXML either baked in, or as a library because it absolutely can represent the fullness of HTML... (parrot (@ (type "African Grey")) (name "Alfie")) Becomes: Alfie https://www.gnu.org/software/guile/manual/html_node/SXML.htm...

Yes, (HT|X)ML have a semantic model that that can be represented in Lisp syntax, but so does everything else (well, every programming and data representation language, at least.) They don't do it with the same (or simple parallel) single simple syntactic fiundaton as Lisp, but with something more complex.

... I'd call that simple, without complex additions. You're not exactly requiring a parser, here.
Post reply on HN