From: Clark C. E. <cc...@cl...> - 2004-09-03 20:43:35
|
Ok. Here are four additional proposals for this 'change set'. #1 Change the YAML version to 1.1 This is a substantial change set, and we have lots of documents out there that assume older semantics; the whole purpose of the directive was to cover this case. If we bump the version to 1.1 we have the following: - If a 1.1 Parser runs into a 1.0 document, it can either load using the old rules, perhaps with a warning or give the the user a chance to load with the new rules anyway. - If a 1.0 Parser runs into a 1.1 document, it can also issue a warning, and load the best of its ability... probably choking if there are tags; but clearly getting the private types wrong. The specificaiton will "grow" an appendix describing the old behavior, and marking it as depreciated. Really, this is 1.2 as we should have bumped the version when we got rid of default implicit typing... let's not make the same mistake twice. #2 Special hook for 'YAML Type Repository' tags. One of the main goals of YAML is allowing data to be shared across multiple programming languages. There are several reasons why one would want to use YAML types along with private types, and types from other tag sets. So, to help facilitate this we propose using !! to mark YAML tags, without needing a %TAG:yaml.org,2002: directive. --- %TAG:clarkevans.com,2004:wibble/^cce - !int # int - !!int # tag:yaml.org,2002:int - !cce^int # tag:clarkevans.com,2004:wibble/int ... --- %TAG:clarkevans.com,2004:default/ %TAG:clarkevans.com,2004:wibble/^cce - !int # tag:clarkevans.com,2004:default/int - !!int # tag:yaml.org,2002:int - !cce^int # tag:clarkevans.com,2004:wibble/int ... This is introduced to hopefully address some of the concerns about making it inconvient to access built-in YAML types, and thus worries that it would hinder loading of documents across different programming languages. The compelling use case for this was configuration files, where most types will be private, but some built-in types may be desired without having to use directives. #3 Placement and scope of directives In YAML 1.1, directives will be a property of the stream and must appear _before_ any document starts. They then apply to all documents in the stream. %TAG:clarkevans.com,2004:wibble/^cce --- - !int - !cce^wick # directives are not allowed here --- - !int - !cce^bing The rationale for this is that it would be tedious to find a %TAG unless it is at the top of the document and clearly shouts that it is magical. Not allowing it anywhere else in the document is justified by the cost of 'hunting' down a directive. While someone may want to 'concatinate' streams, they can do so after they remove the document. Perhaps the parser can give a _warning_ if it finds directives that repeat previous directives, and issue an _error_ if they find a directive that conflicts with a previous directive. #4 Directives start in column 0 Since directives in YAML 1.1 will be "stream" items, there is no justification for the current 'single-token' constraint placed on them. In particular, they should start in column 0 and extend till the end of the line. This also allows directives to use spaces liberally, and comments. #!/comments/are/still/allowed/here %YAML 1.1 # this is optional %TAG clarkevans.com,2004:wibble cce # 'cce' prefix # comments are here as well %TAG byt...@la...,2003-03:/assembler/ # default prefix # and here --- - !int JUMP # tag:byt...@la...,2003-03:/assembler/int - !!int 324 # tag:yaml.org,2002:int - !cce^int # tag:clarkevans.com,2004:wibble This should also allow for greater clarity in what can be a very ugly mechanism. But, at least the uglyness is a bit less ugly and always at the top of the file in plain view. That's it. I'm not sure if all of this is a great idea; but I think it is on the whole "good" idea, and Oren seems to agree. Brian has not yet seen nor agreed; so this is open for debate. I've asked Oren to write up the next 'draft' of the changeset assuming these are all accepted. He is the production king. Clark |
From: T. O. <tra...@ru...> - 2004-09-03 21:02:18
|
On Friday 03 September 2004 04:43 pm, Clark C. Evans wrote: > Really, this is 1.2 as we > =A0 =A0should have bumped the version when we got rid of default implicit > =A0 =A0typing... let's not make the same mistake twice. Okay, I wasn't around for this. So implicit typing is gone already? Just=20 hasn't caught up to my version of Syck yet? Is that what I'm hearing? - 23 - !str 23 These are the same (semantically)? - 23 - !int 23 Are not the same? Or are they? With Oren's "For the last time, NO." plan. - !tag:yaml.org,2002:int 23 - !int 23 Aren't the same either. But in fact, an "unmodified" loader will think they= 're=20 both strings! =2D-=20 T. |
From: why t. l. s. <yam...@wh...> - 2004-09-03 21:46:04
|
T. Onoma wrote: >On Friday 03 September 2004 04:43 pm, Clark C. Evans wrote: > > >>Really, this is 1.2 as we >> should have bumped the version when we got rid of default implicit >> typing... let's not make the same mistake twice. >> >> > >Okay, I wasn't around for this. So implicit typing is gone already? Just >hasn't caught up to my version of Syck yet? Is that what I'm hearing? > > _default_ implicit typing is gone, t. emancipation of types, courtesy of ole abe ingy. look, we're only trying to sensibly turn the shortcut syntax into a clash-free environment for the external types. i don't see why builtin types and user's private types can't share the generic namespace. ruby's default namespace contains both builtin and user-made classes. _why |
From: T. O. <tra...@ru...> - 2004-09-03 22:07:05
|
On Friday 03 September 2004 05:45 pm, why the lucky stiff wrote: > _default_ implicit typing is gone, t. emancipation of types, courtesy > of ole abe ingy. Thanks, _why. That clears some things up. -- T. |
From: Clark C. E. <cc...@cl...> - 2004-09-04 00:22:57
|
(off list) _why, I want to make sure you are happy with all of this and that it makes sense and that we won't be leaving any Ruby users stranded with this set of decisions. Please feel free to raise a hissy fit if anything is wrong, or if you would like, you can send me your concerns directly -- your choice. Glad you are helping out. It's hard to keep everyone on the same page. Cheers! Clark |
From: Clark C. E. <cc...@cl...> - 2004-09-04 00:24:59
|
oops! I guess it ain't off list ;) On Fri, Sep 03, 2004 at 08:22:56PM -0400, Clark C. Evans wrote: | (off list) |
From: Clark C. E. <cc...@cl...> - 2004-09-04 06:11:37
|
On Fri, Sep 03, 2004 at 03:45:41PM -0600, why the lucky stiff wrote: | look, we're only trying to sensibly turn the shortcut syntax into a | clash-free environment for the external types. i don't see why builtin | types and user's private types can't share the generic namespace. | ruby's default namespace contains both builtin and user-made classes. That's also true in the Python environment. It just doesn't have reserved keywords. In fact, if you want to really mess with someone's brain, you do... (True,False) = (False,True) So, you're proposing that we leave the !stuffs ambiguous; as YAML adds types, they go there. And a parser could, by default, load its handlers there. But, private types could go there too. To make this "easier" for those making private types, we follow David's suggestion: On Fri, Sep 03, 2004 at 04:57:33AM +0100, David Hopwood wrote: | I'm going to keep banging on about the issue of additions to the YAML | tag repository. If there is a policy of restricting new names in the | repository to, say, [a-zA-Z0-9_]+, then people can choose to use private | names that do not match that regexp without any risk that they will be | confusable with future repository-defined tags. (This is useful despite | the fact that there is nothing preventing collisions between two private | names in general.) So, while people could use private tags, we'd clearly say that they could make something that would collide with us down stream if they used a tag from the regex given. Clark |