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 sy

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]