On 17/06/02 12:14 -0400, Clark C . Evans wrote:
> On Mon, Jun 17, 2002 at 08:22:43AM -0700, Brian Ingerson wrote:
> | 1) Keep YAML tidy
> | 2) Make YAML DWIM
> | 3) Provide an upgrade path
> | 4) Keep the productions reasonable
> | I like the ideas that are floating around. Here's how I would most like
> | to see things:
> | 1) ints and floats work as they do today.
> | 2) null works as today (~). (This shows up like crazy in dumps, and
> | needs to be clean. It is also a native type.)
> | 3) dates and times require explicit declaration
> Dates and times show up like crazy in my dumps. In business
> data dates, times, and currency are big use cases -- much more
> common than floating point values.
Yes. Agreed. But..
They are not native types in Python, Perl, etc. Ints and floats *are*.
So if you want to show that a date string is going to be loaded into a Date
class, please _indicate_ it.
date: ! 06-17-2002
time: ! 12:15
alternate date: ! Sun Oct 28 2001
The ISO8601 dates are so darn long that adding a '! ' won't cause any
readability loss anyway.
Also, your business cases are probably not of the "human writable YAML" form.
> | Otherwise they are strings. (Most people in Perl and Python don't
> | need automatic Date object creation. String would be the expected
> | behaviour from a config file.)
> Yes, for system programming you don't need dates and times
> very often. However, for business applications dates and
> times are essential.
I'm not suggesting they aren't. But for the human writable goal, let's just
use unquoted for strings, ints and floats.
If it came down to it, I'd go with Ryan's stricter proposal of "unquoted
is string only". Ints and floats require '! '. For config stuff, the
application would know which strings should become ints and floats. For
RPC stuff, the emitter would do the right thing:
size: ! 9
weight: ! 3.5
Not too bad. (I'm catching on Ryan)
That way, we drop all implicit typing if there is no '! '.
I'd still require that the unquoted begin with [_A-Za-z0-9]. Anything else
would be a parse error. That way all other characters are reserved.
> | 4) Unquoted strings, outside an Inline collection, must start with a
> | word-char (including numbers). After that anything goes. It's a
> | string. (This assumes we've already checked for ints and floats).
> | 5) Unquoted strings, inside an inline collection, must be only
> | made of word chars. Otherwise you must quote them.
> So, we want to introduce yet-another-scalar-kind? We already
> have block and folded; now we want to split simple scalars
> into the nested (very restrictive) and top-level (very flexible)
> variants? I'm more leaning towards Neil's suggestion of limiting
> unquoted values to a single word.
Yeah. It's a possibility. But for the human writable goal, It just gets in
the way. It is a simple rule though. I'll consider it.
> | 6) All future oddball types, like URI, require explicit or just '! '.
> | (Scripting languages don't have native support for anything outside
> | str, int, float, null. People will expect URIs to be strings. There
> | should be a visual indicator if that isn't true. '! ' works nicely)
> I see URIs as becoming more and more common type of data,
> and I can see how one would like do include complex numbers
> as well. Do we want to draw a line in the sand now and say
> that YAML will never, ever have other implict types?
No lines are being drawn. We just use an implicit type indicator. Always.
> | four:
> | - 123 Main Street
> | - m|.*?\\(foo\w*)?.+$|;
> | - YAML's cool!
> | - http://www.yaml.org
> | - 192.168.0.1
> | - true
> | - 09-11-2001
> | - Unquoted strings, outside an Inline collection, must start with
> | a word-char (including numbers). After that anything goes.
> Of these use cases, only the last one is interesting to me,
> the rest are not interesting. The first two would be better
> as blocks. The URL, Date, and IP address would be better off
> being typed. You seem to be dividing the current "simple"
> scalar type into two subordinate types:
> flex: This type is your #4 above. I'd limit the impliict
> text recognition to start with an alpha character so
> that dates and numeric types can co-exist peacefully.
> word: This type is similar to #5. In this type the
> scalar value can only be a word (sequence of
> word chars beginning with alpha). This is
> designed to work with nested maps/lists. It could
> also be the production for "key" values for
> regular multi-line mappings.
I'm torn. Single word is definitely simple. Both to explain and to implement.
But it just kind of leaves me feeling crippled. I have a ton of YAML docs
that would instantly become invalid. I'd need to cruft them up with lots and
lots of quotes.
I like the Perl attitude. Larry never shyed away from going the extra mile to
make things DWIM. Sure, it's a double-bladed sword. So far, we've tried hard
to make YAML rock. Let's not oversimplify things too much.
> This isn't so bad. Is it worth the extra complexity?
> It would prevent a URI implicit type.