Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

> Semantics is a separate matter.

I agree; and symbol is a semantic entity, not a syntactic one.

S-expressions do not have symbols, they have tokens which become symbols when read into the machine.

Tokens are clumps of characters. i.e. strings.

> There are no symbols or references in Jevko.

> @gnulinux and @User23 have it right.

Those two are insisting that texts are symbols in Jevko, so the above two statements contradict each other.

E.g.

gnulinux> You're not understanding. These are not strings. These are symbols.

User23> Jevko language [...] has no strings. For example, a Common Lisp hosted Jevko parser implementation might choose to represent Jevko text objects as symbols.

> What's happening here is parsing. `jevkoToHtml` is a kind of parser-transpiler which operates on a syntax tree, rather than a sequence of characters or tokens.

That is obviously false. It's operating on a nested list of strings, whereby it's making a semantic decision whether a string in a certain position of a nested item in the structure ends in the = character.

In other words the syntax is character-level. The strings themselves have syntax, which is made of characters. That's in the Jevko specification. Characters are the atoms in Jevko.

The = character that the code is looking for is a %x3D element.

It's right here: https://github.com/jevko/specifications/blob/master/draft-st...

The = character is %x3D. An %x3D is Character. A Character is one of the kinds of Symbol (the other being Digraph). A Symbol is a constituent of Text. Text generates a Prefix or Suffix. A Suffix alone can be a Jevko due to this rule:

  Jevko ::= *Subjevko Suffix

Thus, formally Jevko does have Symbols: a Symbol is a Character or Digraph.

A Text is a sequence of Symbols, which are Characters or Digraphs. It is in no way an atom. A sequence of characters or diagraphs is a string.

I suppose there is a bit of confusion.

User23> For example, a Common Lisp hosted Jevko parser implementation might choose to represent Jevko text objects as symbols.

This is right.

gnulinux> These are not strings. These are symbols.

This might be confusing. @gnulinux seems to be using the word `symbols` loosely here, not in the Lisp sense. I suppose that's unfortunate in this context.

What may be adding to the confusion is that Jevko spec also talks about Symbols, which are still a different thing.

So the word symbol is much too overloaded here. Let's forget about for the sake of trying to solve this thread once and for all.

The comment that started it was:

Nullabillity> I wish we could stop making up new languages in 2022 that use unenclosed strings...

And then people were trying to explain how there are no strings in Jevko.

Indeed, Jevko the syntax (Jevko is not a language) does not involve anything named string.

It does involve a rule named Text. When parsing a sequence of unicode code points, a specific parser implementation may choose to store a fragment of the sequence that conforms to this rule using a specialized object or a data structure to explicitly represent also the subfragments that conform to rules that Text is defined in terms of. But it may also choose to use a string type.

`jevkoToHtml`[0] relies on an implementation that stores the Text fragments as JS strings.

Thus:

> It's operating on a nested list of strings, whereby it's making a semantic decision whether a string in a certain position of a nested item in the structure ends in the = character.

That "nested list of strings" (not exactly an accurate description) is the syntax tree.

Those strings represent the Text fragments. This is a very convenient implementation, because most of the time we don't want to go lower than that. If we do, Symbols and Digraphs are still easily accessible and identifiable in this representation. They are just not explicitly reified.

So looking whether there is a `=` character in the string is the same as looking whether there is a `=` Character in the Text.

This happens as part of the second pass of parsing I was talking about above.

This pass does not result in any discernible intermediate representation -- it just directly guides the process of constructing an HTML string[1].

This mental model is the best for understanding this code, because it's essentially the one used to create it.

There is no intention anywhere to lie or insult the semantics or philosophy of Lisp in there, trust me.

I'm telling you this as the author of both the specification and the code.

Ultimately, you can understand this any way you like. If thinking about this as strings or numbers or whatever works for you, great!

A common mental model and agreed upon language is useful to achieve productive results in collaboration. If that's not the goal, then it's not necessary.

Anyway, thank you for looking into the specification and taking the time to understand it. Have a good night!

[0] Have in mind that these 14 lines of JS were not really written to be examined in this detail or to present the best way to do something. I just needed a quick sketch to try out an idea. It's not for use in production or lectures on parsing. :D

[1] Which is not nice, but [0]

Reply on news.ycombinator.com