On Mon, Sep 13, 2004 at 02:38:50PM -0400, trans. (T. Onoma) wrote:
| > Having four kinds would cause serious changes in the model,
| > and is far more mental work than I have bandwith. My gut feeling
| > is that you are just moving the 'wart' out of the syntax and
| > into the APIs where it will cause even more problems.
| Okay. Let me see what I can do to help look at this option in full
| and how it might effect the spec. I can understand your concern...
| I just skimmed over the spec with this in mind. Seems to me the
| effect can be kept very minimal by doing these two things:
| - Do not substitute for the word 'scalar', the words 'string'
| and/or 'symbol'. Simply explain early on that two different
| _kinds_ of scalars are recognized: string and symbol. Most of
| the spec will then be completely unaffected in this regard.
So, we have 3 kinds or 4? Or 3 kinds where one is a sub-kind?
| - References to "plain" scalar as style must change, since they
| can no longer be considered just a matter of style. Actually
| this is also true of both later proposals anyway (albeit they
| may try to be "tricky" and mask the fact).
Ok. So symbols are _only_ saved as "plain" and non-symbols arn't?
- this is a string
Does that have to be a symbol and not a string? Or a special,
non-native string? This, especially for keys is 50% or more
of the nodes in the YAML document.
| In this way very little actually changes. Most of the changes center
| around plain scalar as style. But like I said the other two options
| are moving in the very same direction, so this needs to be
| considered anyway.
Actually, it would have big impacts on the API, as you mention
below, and the model is there to help guide the API.
| The only other thing I can think of is for implementors, i.e. if
| they don't have a symbol type in their language of choice, simply
| use a string and flag it as symbol (i.e. for symbols that aren't
| implicitly transformed into something else.)
Ok. So everything written with a Plain scalar in YAML would
need a symbol object? What happened to BLOBs that are stored
as a 'string'? Are they symbols. This gets ugly quick, beacuse
you are taking the syntax distinction and trying to turn it
into something fundamentally different.
Assume for a moment that you did have symbols as totally different
and written using the plain style. The character set allowed by
the plain style is quite arbitrary, mostly due to constraints to
not collide eith other styles. For example, the sequence "# "
is not allowed in a plain style beacuse it marks a comment.
Do we need another style for these symbols that allows one to write
a symbol with "# "? Or, should we limit symbols to not allow spaces
and to have a much more limited scope. In this case, you'd be
preventing our use case of things like address:
street: 23 Broad Ave, N.E.
That's not a symbol.
| Just trying to explore all the alternatives, especially since there
| seems yet to be many rumblings about the current proposals.
Ok. But, I think you're doing exactly what you did a few days ago,
trying to turn the style into something it's not. We've got a damn
exception or wart beacuse people think 23 is an integer and
'23' isn't. That's all. It's not rocket science, it's not a
deep philosophical thingy. It's just an inconsistent human thing.
Also, can an integer be a string, or is it always a symbol? Where
do you draw the line, is a BLOB (using Base64) a string or a symbol?
This line is quite arbitrary, and it makes things more complicated.
| Here's what I'm thinking: Is a string a symbol? No, a string is
| definitely not a symbol --it is the opposite of a symbol. It is
| anti-symbol. A symbol is a symbol. Sure it can turn out to be all
| but equivalent to a string --but only b/c it didn't turn out to
| symbolize anything else. We have symbols in every programming
| language, sometimes there's a an explicit attempt at letting you
| have access to such, like with Lisp. But generally its hard for a
| language to do b/c the code itself _is_ symbol. If your were to say,
| it's just a string that gets symbolized (! "23" => 23), ask yourself
| this, was it a style change or a transformation?
The last proposal uses a bandaid that says this was a 'style change',
it says that 23 is the same as the sole private-type indicator
tagged to a scalar value of '23'. It considers a plain scalar as
a syntax sugar for specifying the type ! for the node.
| Okay, all philosophical crap aside. What is the "everything" effect?
| You get four kinds instead of three. The backend langs will have to
| handle another "thing". No problems for Ruby and Lisp --they have
| symbol "things". Langs w/o separate symbols,
No, you've got a more serious issue here. If plain scalars are symbols,
then you either have to forbid spaces in plain scalars to be consistent
with the "typical" symbol, or you've got to introduce yet-another-style
that is a 'symbol' (and not just a scalar), so double quotes won't due.
Perhaps you'd have to introduce the ` character? Ick.
| Implicit typing would only effect symbols, not strings. Strings are
| always what they are --"literals". Symbols can be transformed based
| on content. But if they don't get transformed they just remain
| indeterminate symbols --essentially strings, but not quite strings,
If you make this distinction, then all of the schema languages will
have to have a special case for matching symbols but not other strings.
Path expressions as well, would need special cases, beacuse one
would have to distinguish between "a" the string and "a" the symbol.
Further, both strings and symbols could potentially have a tag,
so this makes it even more messy.
| Anyhow, like I said just wanted to lay the field barron -- no stone
| unturned. And this seems a fair possibility. So I put it out there.
| Maybe it can stick, maybe it can't. Seems to have some of the right
| ingredients for the current woes. Tis all, tis all.
Well, I think we've turned this stone over, and its clearly
a mess under. ;)
| P.S. If you're not familiar with Ruby's (and Lisps) symbol per se,
| it is like a string but they have almost no "methods". They are just
| "names" basically.
Sounds like what you have is a !symbol tag, not a new kind.
The last proposal should work well, ! , can be your tag!