4 ms·

You're not understanding. These are not strings. These are symbols. Say in python you write `a = b`. Are "a" and "b" strings? No. In these examples what you're

You're not understanding. These are not strings. These are symbols. Say in python you write `a = b`. Are "a" and "b" strings? No. In these examples what you're referring to as strings are just meant to be symbols like "a" and "b". It just so happens that the implementation uses "String" data type to represent them. Other examples: in XML when you write `<abc></abc>` is "abc" a string? In s-expressions (or lisp) when you write `(if a b)` are "if", "a" and "b" strings?

Nullabillity 4y ago
That XML snippet isn't really representative though, let's consider `<a b="c">d</a>` instead. Here, `c` and `d` are definitely plain old strings. Likewise, in the Jevko expression `a [b]` I don't see how `b` is not a string.
- gnulinux 4y ago
  > I don't see how `b` is not a string. Because it isn't. There is no concept of a string. `if [[a] [b]]` is similar to `(if a b)`. So in your example `a [b]` is similar to s-expression `(a b)`. Neither "a" nor "b" are strings here.
  - kazinator 4y ago
    If b is a symbol, which one is it? Is it interned, or uninterned? Given the Jevko syntax [b b], is that a repetition of the same object, or is that two different symbols that have the same name? Is it like (b b) or (#:b #:b)? Why or why not; based on what documentation? In symbol manipulation, symbols are atoms. Each symbol represents an identity. An identity cannot be fractured into sub-identities. The textual name of a symbol just provides a written notation; all semantics of symbol manipulation concerns itself only with whether two symbols are the same one or a different symbol. For instance the idea that the symbol foo is a prefix of the symbol foobar is invalid. We may only ask whether foo and foobar are the same entity or different. A basic operation in symbol manipulation is semantics-preserving substitution. If Jevko is based on symbols then [a b b] can be replaced by [a c c] without loss of semantics. In fact, all we are doing is changing the name of the b symbol; its identity remains the same. Suppose there is some application built on Jevko in which [a=b b] cannot be replaced by [a=b c] without destroying the semantics; suppose it has to be that in that application, if b is replaced by c, then [a=b b] must turn into [a=c c], in order to preserve a relationship that holds between a=b and b. That application has then destroyed the concept of a Jevko symbol, because a=b isn't functioning like an atom any more. It's functioning like two symbols a= b or possibly three symbols a = b. Thus if a=b is really one symbol, and not a string of three characters, then no legitimate, Jevko-respecting application of Jevko can do anything like this, namely treat a=b as being syntax which codes for two or three atoms. But that's a lie, because Jevko is intended for doing that sort of thing like it's going out of style. For instance, in this code: https://github.com/jevko/jevkodom.js/blob/master/jevkoToHtml.js https://github.com/jevko/jevkodom.js/blob/master/jevkoToHtml... can you explain what mid.endsWith('=')? "attr": "tag" is doing? It sure looks to me like it's asking whether a symbol (i.e. indivisible atom) ends with an equal sign, which is semantic gibberish.
    - djedr 4y ago
      This analysis would be valid if we were talking about lambda calculus or a Lisp with square brackets. Jevko isn't that. It's not a programming language[0]. It's just syntax, with even less semantics than JSON and even simpler than S-expressions. There are no symbols or references in Jevko. It's important here to separate syntax and semantics. S-expressions are not Lisp. They are its syntax. Semantics is a separate matter. @gnulinux and @User23 have it right. Strings are an implementation detail. You could store the parsed text as numbers or you could Gödel-encode the entire tree into one giant number. Saying then that Jevko is nothing but numbers is conflating things. --- Just to clarify, in Jevko `[b b]` doesn't parse to what your description implies you think it does. `b[b]` or `[[b][b]]` would be closer to that. If you are interested in the details, please have a look at the specification or diagrams: * https://jevko.org/spec.html https://jevko.org/spec.html * https://jevko.org/diagram.xhtml https://jevko.org/diagram.xhtml From there you should be able to easily write a parser in your favorite Lisp! ;) --- > can you explain what mid.endsWith('=')? "attr": "tag" > is doing? It sure looks to me like it's asking whether a symbol (i.e. indivisible atom) ends with an equal sign, which is semantic gibberish. There are no symbols or indivisible atoms here. 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. The syntax tree is the output of an earlier stage of parsing, done by the Jevko parser. So you can think of this as multi-pass parsing, by analogy with multi-pass compilation. At the same time as this second pass of parsing is happening, translation to HTML is happening as well. Hope this clarifies things! --- [0] To clearly see the point, here is a toy programming language which uses Jevko as its syntax: https://github.com/jevko/jevkalk https://github.com/jevko/jevkalk
      - kazinator 4y ago
        > 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-standard-grammar.md 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.

Nullabillity 4y ago

That XML snippet isn't really representative though, let's consider `<a b="c">d</a>` instead. Here, `c` and `d` are definitely plain old strings. Likewise, in the Jevko expression `a [b]` I don't see how `b` is not a string.

gnulinux 4y ago
> I don't see how `b` is not a string. Because it isn't. There is no concept of a string. `if [[a] [b]]` is similar to `(if a b)`. So in your example `a [b]` is similar to s-expression `(a b)`. Neither "a" nor "b" are strings here.
- kazinator 4y ago
  If b is a symbol, which one is it? Is it interned, or uninterned? Given the Jevko syntax [b b], is that a repetition of the same object, or is that two different symbols that have the same name? Is it like (b b) or (#:b #:b)? Why or why not; based on what documentation? In symbol manipulation, symbols are atoms. Each symbol represents an identity. An identity cannot be fractured into sub-identities. The textual name of a symbol just provides a written notation; all semantics of symbol manipulation concerns itself only with whether two symbols are the same one or a different symbol. For instance the idea that the symbol foo is a prefix of the symbol foobar is invalid. We may only ask whether foo and foobar are the same entity or different. A basic operation in symbol manipulation is semantics-preserving substitution. If Jevko is based on symbols then [a b b] can be replaced by [a c c] without loss of semantics. In fact, all we are doing is changing the name of the b symbol; its identity remains the same. Suppose there is some application built on Jevko in which [a=b b] cannot be replaced by [a=b c] without destroying the semantics; suppose it has to be that in that application, if b is replaced by c, then [a=b b] must turn into [a=c c], in order to preserve a relationship that holds between a=b and b. That application has then destroyed the concept of a Jevko symbol, because a=b isn't functioning like an atom any more. It's functioning like two symbols a= b or possibly three symbols a = b. Thus if a=b is really one symbol, and not a string of three characters, then no legitimate, Jevko-respecting application of Jevko can do anything like this, namely treat a=b as being syntax which codes for two or three atoms. But that's a lie, because Jevko is intended for doing that sort of thing like it's going out of style. For instance, in this code: https://github.com/jevko/jevkodom.js/blob/master/jevkoToHtml.js https://github.com/jevko/jevkodom.js/blob/master/jevkoToHtml... can you explain what mid.endsWith('=')? "attr": "tag" is doing? It sure looks to me like it's asking whether a symbol (i.e. indivisible atom) ends with an equal sign, which is semantic gibberish.
  - djedr 4y ago
    This analysis would be valid if we were talking about lambda calculus or a Lisp with square brackets. Jevko isn't that. It's not a programming language[0]. It's just syntax, with even less semantics than JSON and even simpler than S-expressions. There are no symbols or references in Jevko. It's important here to separate syntax and semantics. S-expressions are not Lisp. They are its syntax. Semantics is a separate matter. @gnulinux and @User23 have it right. Strings are an implementation detail. You could store the parsed text as numbers or you could Gödel-encode the entire tree into one giant number. Saying then that Jevko is nothing but numbers is conflating things. --- Just to clarify, in Jevko `[b b]` doesn't parse to what your description implies you think it does. `b[b]` or `[[b][b]]` would be closer to that. If you are interested in the details, please have a look at the specification or diagrams: * https://jevko.org/spec.html https://jevko.org/spec.html * https://jevko.org/diagram.xhtml https://jevko.org/diagram.xhtml From there you should be able to easily write a parser in your favorite Lisp! ;) --- > can you explain what mid.endsWith('=')? "attr": "tag" > is doing? It sure looks to me like it's asking whether a symbol (i.e. indivisible atom) ends with an equal sign, which is semantic gibberish. There are no symbols or indivisible atoms here. 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. The syntax tree is the output of an earlier stage of parsing, done by the Jevko parser. So you can think of this as multi-pass parsing, by analogy with multi-pass compilation. At the same time as this second pass of parsing is happening, translation to HTML is happening as well. Hope this clarifies things! --- [0] To clearly see the point, here is a toy programming language which uses Jevko as its syntax: https://github.com/jevko/jevkalk https://github.com/jevko/jevkalk
    - kazinator 4y ago
      > 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-standard-grammar.md 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.