From: Oren Ben-K. <or...@ri...> - 2002-08-05 07:35:41
|
David Garamond [mailto:dav...@ic...] wrote: > how i skimmed the list archive and have found this topic discussed. i > wonder things settle? Well... we *thought* things have settled :-) Currently a string is everything starting with an alphanumeric character, unless it is an integer, float or a date. Anything starting with another character (such as '/') needs to be quoted or typed. The reasoning is that we may want, at some time or the other, add further implicit types. These would have to be marked by some non-alphanumeric leading character. For example, '$NIS 12.50' for fixed-point currency values. Brian doesn't believe much in us ever having any more implicit types. Clark thinks we might (currency, for example, is very useful for him). I think we shouldn't close the doors on them. The above state of affairs is the compromise we reached. > especially, since yaml is to be used for > configuration files, wouldn't it be nicer if path strings > ("/foo/bar", > which should be occured a lot) can be written without > explicit quoting? It is true that as a result people writing absolute path names inside configuration files have to quote them. Unless they are working in windows, that is :-) The possible prefixes for a path are '/', './', '../' and '~'. We could: - Just require such paths to be quoted. Is this a big deal? - Explicitly add these prefixes to the default string type. Very specific... Are there other widely-used cases of this kind? - Give up on any further implicit types forever. Much too restrictive. Hmmm. Thoughts? Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2002-08-05 15:50:47
|
Ned Konz [mailto:ne...@bi...] wrote: > > I'm for option #2, adding "/" and "." to denote a string allowing > > paths to be unquoted within YAML. > > You mean "Unix paths", don't you? I thought YAML was supposed to be > cross-platform <g>... So it is... > After all, there's also Mac (HFS) and Windows/DOS paths that don't > look like that. Well, absolute Windows/DOS paths start with a drive letter, so they'll be string by default anyway. Paths starting with a '\' are an issue I suppose - to be fully cross-platform, all of '/' '\' and '.' should denote a string. > Is it really so troublesome to type the quotes? I don't know. Configuration files are a major use case after all... OK, step back a bit. All non-ASCII Unicode characters are assumed to be "alpha" and denote a string (except for controls characters, line breaks etc.). That leaves us the 128 ASCII characters, out of which several are control characters (invalid), space (separator), letters, '_' and digits (start a string), and the following: ! " # $ & ' ( ) * + , - . / : < = > ? @ [ \ ] ^ ` { | } ~ Out of these, YAML uses the following as indicators so they can't start a string: ! " & ' * > [ ] { } | (Note that ':' '#' ',' *can* start a string if not followed by a space). Also, ` was defined to mark "private implicit types", so that's out too. Likewise (word) is used for enum-like implicit types, and ~ is used for null, leaving us: # $ + , - . / : < = ? @ \ ^ Now, the question is: which of the above should be used to denote a string and which should be reserved for potential future global implicit types? The current answer is "all are reserved for potential future implicit types". However, if we ask the reverse question: which of the above is commonly used in string values in use cases we are aware of today? The answer to this seems to be: / . \ - The . \ start paths; / starts paths in UNIX and command line options in DOS; - and + start command line options in UNIX. Assuming we use these to denote strings, it leaves us only 8 controversial characters: # $ , : = ? @ ^ Now, can anyone think of a common use case where any of the above would be the first character of a string value? Off the top of my head, I can't think of any. Alternatively, can anyone thing of potential implicit types that may make use of these characters? Well, '$' seems a natural for currency. We could prefix a '#' to make binary an implicit type. '@' is a natural for all sort of addresses (IP/domain/E-mail, maybe also URLs). I don't know. But, given my crystal ball is broken, I'd rather play it safe and reserve all these 8 characters for possible future implicit types, unless someone points out a common use case requiring them. Thoughts? Have Fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-08-05 16:09:55
|
So, as I read the proposal, you would open up string implicit to begin with the following (unless it smells like another implicit): / . \ - This leaves the following characters "reserved" # $ , : = ? @ ^ Its good to keep these fellas reserved, #,:? are all used to mean particular things (albeit with an extra space) so using them as string starter is probably a bad idea. Further, I can think of special keys meanings for @ and ^, and = is already a special key. Oops. Found the monkey wrench. What about the //comment special key? I do think that a special key for round-tripping comments is a good idea. *sighs* Clark |
From: Oren Ben-K. <or...@ri...> - 2002-08-05 16:29:39
|
Clark C . Evans wrote: > So, as I read the proposal, you would open up string implicit > to begin with the following (unless it smells like another implicit): > > / . \ - Actually '+' as well. I forgot to list it. > This leaves the following characters "reserved" > > # $ , : = ? @ ^ Yes. Actually ';' as well (I somehow missed it completely). > Its good to keep these fellas reserved, #,:? are all used to mean > particular things (albeit with an extra space) so using them as > string starter is probably a bad idea. Further, I can think of > special keys meanings for @ and ^, and = is already a special key. Right. > Oops. Found the monkey wrench. What about the //comment special key? > I do think that a special key for round-tripping comments is a good > idea. *sighs* Nice catch! Let's see... Probably the best way would be to use something other than '//' (making '//' be special and '/' start a string is way too magical for me). How about ';'? I think there's prior art for using ';' for comments (SAMBA configuration files come to mind and I'm certain there are others). like this: x : 7 ;y : 8 or this: [ x : 7, ; y : 8 ] How about it? Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-08-05 16:47:16
|
On Mon, Aug 05, 2002 at 07:31:08PM +0300, Oren Ben-Kiki wrote: | making '//' be special and '/' start a string is way too magical for me agreed. | How about ';'? I think there's prior art for using ';' for | comments (SAMBA configuration files come to mind and I'm certain | there are others). | | like this: | x : 7 | ;y : 8 | or this: [ x : 7, ; y : 8 ] Looks too close to the colon.. Hmm. What if we used the () implict type mechanism for this sort of thing in conjunction with the pound? like this: x: 7 (#y) : 8 or this: [ x: 7, (#y): 8] To me, the ( means that a "implicit type" is on its way and the ending ) clearly indicates the end of it. Thus, (#) could mark a special comment. Its magical, but then again, anything in parenthesis is magical, right? Hmm. We also have the equal special key... this: (=): equal special key value hmm: perhaps this is a better way to do special keys? Best, Clark |
From: Oren Ben-K. <or...@ri...> - 2002-08-05 17:12:08
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | How about ';'? I think there's prior art for using ';' for > | comments (SAMBA configuration files come to mind and I'm certain > | there are others). > | > | like this: > | x : 7 > | ;y : 8 > | or this: [ x : 7, ; y : 8 ] > > Looks too close to the colon.. I don't know if that's a good reason to rule it out. A leading colon isn't a common thing, for the simple reason it isn't legal anyway - so there's no confusion reading this. And ';' has been used for comments in several formats, so it wouldn't be surprising. I think ';' is perfect for the job. > ... What if we used the () implicit type mechanism > for this sort of thing in conjunction with the pound? > > like this: > x: 7 > (#y) : 8 > or this: [ x: 7, (#y): 8] and: > this: > (=): equal special key value > hmm: perhaps this is a better way to do special keys? I don't know. I like the one-char look. I also like being able to comment out something by just prefixing it, instead of surrounding it - that is, use // rather /* ... */ and ; instead of (# ... ). As for using (=) instead of =, well, I got used to =, I rather like it. But it is a matter of taste - either way would work. As a side issue, if we don't end up using ';' for comments, would it denote a string or an implicit type? Of course, using it as a comment nicely avoid having to decide this ;-) Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2002-08-05 17:45:53
|
On Mon, Aug 05, 2002 at 08:13:30PM +0300, Oren Ben-Kiki wrote: | > like this: | > x: 7 | > (#y) : 8 | > or this: [ x: 7, (#y): 8] | | I don't know. I like the one-char look. I also like being able to comment | out something by just prefixing it Ahh. Got you. Hmm. Clark |
From: Clark C . E. <cc...@cl...> - 2002-08-05 13:02:56
|
Indeed. I feel David's pain. Currently the Python parser is "broken" in that it doesn't require paths to be quoted. On Mon, Aug 05, 2002 at 10:37:10AM +0300, Oren Ben-Kiki wrote: | Currently a string is everything starting with an alphanumeric character, | unless it is an integer, float or a date. Anything starting with another | character (such as '/') needs to be quoted or typed. | | The reasoning is that we may want, at some time or the other, add further | implicit types. These would have to be marked by some non-alphanumeric | leading character. For example, '$NIS 12.50' for fixed-point currency | values. Pretty much the only "core" type that we are missing, is currency. It would be based on ISO 4217 (http://www.jhall.demon.co.uk/currency/) and preferrably be a single token, such as USD$2.30 -- although I guess $USD 233.39 isn't that bad. Sorry to be such a pain, but time has proven to be a great addition to YAML, and I'm confident currency will be just as useful in most business domains. | Brian doesn't believe much in us ever having any more implicit types. Clark | thinks we might (currency, for example, is very useful for him). I think we | shouldn't close the doors on them. The above state of affairs is the | compromise we reached. At this time, Currency is the only one that I think is missing, just about every other data type out there is a derived type. | > wouldn't it be nicer if path strings ("/foo/bar") can be written | > without explicit quoting? | | The possible prefixes for a path are '/', './', '../' and '~'. We could: | | - Just require such paths to be quoted. Is this a big deal? | | - Explicitly add these prefixes to the default string type. Very specific... | Are there other widely-used cases of this kind? | | - Give up on any further implicit types forever. Much too restrictive. - Adding a path type I'm for option #2, adding "/" and "." to denote a string allowing paths to be unquoted within YAML. I'd rather leave ~ in the reserved pool for now, we can always add this and other characters to the list of string starters at a later time if the need so arises. This is a good demonstration of why the spec open for a bit longer is a good idea. Real world feedback is great, thank you so much David. Best, Clark |
From: Ned K. <ne...@bi...> - 2002-08-05 14:37:13
|
On Monday 05 August 2002 06:13 am, Clark C . Evans wrote: > I'm for option #2, adding "/" and "." to denote a string allowing > paths to be unquoted within YAML. You mean "Unix paths", don't you? I thought YAML was supposed to be=20 cross-platform <g>... After all, there's also Mac (HFS) and Windows/DOS paths that don't=20 look like that. Is it really so troublesome to type the quotes? --=20 Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE |