6 ms·

A "text object" is just an overly verbose name for... a string. Which doesn't necessarily have to be called a capital-s String in your chosen language, atoms/sy

A "text object" is just an overly verbose name for... a string. Which doesn't necessarily have to be called a capital-s String in your chosen language, atoms/symbols are also forms of strings.

User23 4y ago
If you like confused and muddled understanding of types, why not just insist it’s all bit vectors? Every data type you can name is just a form of bit vector after all.
gnulinux 4y ago
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

A "text object" is just an overly verbose name for... a string. Which doesn't necessarily have to be called a capital-s String in your chosen language, atoms/symbols are also forms of strings.

User23 4y ago

If you like confused and muddled understanding of types, why not just insist it’s all bit vectors? Every data type you can name is just a form of bit vector after all.

gnulinux 4y ago

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