From: Michael G S. <sc...@po...> - 2002-12-05 00:24:40
|
As I mentioned in my eariler post, I found it useful to implement a small parser for a subset of YAML geared towards configuration files and relatively small amounts of meta-data. I'm proposing that YAML have an official subset language to guide people who want to write small YAML parsers. The working title is POY (Piece Of YAML). I see two broad usages for YAML. 1. Data serialization 2. Metadata Data serialization can be things like representing any language's arbitrary data structures in YAML, complete with round-tripping. Its also things like dumping out your store's inventory database into YAML for easier transmission and interoperability. They can be extremely large. For these things you need anchors, aliases, transfer methods, complex keys, etc... along with all the other YAML stuff. It also means YAML parsers must be very efficient taking care not to require the whole YAML document be loaded into memory in case you're reading from an IO stream or a very large document. Metadata can be things like config files, build files (like Ant uses XML for), change logs or extra data about a thing (like RPM spec header files). They're often used in systems which are not centered around data. They tend to be relatively small. These are typically written by a human or by very simple code. They don't require round-tripping. Since they're small you can be sloppy about how you use memory, often making parsing easier. You don't need anchors, aliass, transfer methods or complex keys. I see a very broad potential for YAML in metadata, since it means you get, for free, a data format which is both machine and human readable rather than inventing Yet Another Ad Hoc format. In those cases, YAML is merely a convenience, not an essential part of the program. Making a dependency on a full YAML parsing library might seem like overkill to an author or not be possible. Using a small parser may be easier. A small parser is certainly easier to write. My proof-of-concept state parser (not finished) can be found here: http://www.pobox.com/~schwern/tmp/YAML-POY/ The state transitions here: http://www.pobox.com/~schwern/tmp/YAML-POY/States And a rough draft of the reduced spec (basically, the unneeded productions were removed) here: http://www.pobox.com/~schwern/tmp/POY.spec (BTW That's what your spec looks like when run through an html2text filter. More on that in another post) Here is a short list of what was removed. Unless otherwise noted they were removed because they're either not needed or difficult to parse or both. - Collection flows - Complex, multi-line or quoted keys. All that's left is "foo: " - Scalar only documents - Folded scalars (ie. >) - Document end (ie. ...) - Directives (ie. 3.3.2) - Node Properties (ie. 3.3.4) - Transfer Methods (ie. 3.3.5) - Anchors (ie. 3.3.6) - Aliases (ie. 3.4) These things are under consideration for removal. They're left in because they're either needed or trivial to parse. - Single and double quotes (I've figured an easy way to parse them easily) - Unicode (a necessary evil) - Explicit indentation (ie. |2) (very easy to handle) - Chomping (ie. |-) (ditto) And the only actual addition to the spec is extending the reserved character set to include things for forward compability with the full YAML spec. For example, flow scalars in the small spec can't start with {, [, *, etc... because it would mean something different in YAML. The spec is intended as a complete subset of YAML. Any POY document will mean the same thing in YAML. Real world use cases: - MakeMaker - Module::Build - Perl is moving to a metadata format for modules (ie. a file to stick things like Name, Author and Version into). - Both of these cannot depend on YAML.pm because of circular dependencies (Module::Build gets away with it becuase YAML is currently built with MakeMaker) - They would have to provide their own YAML parsers. - Perl core - There are lots and lots of applications for YAML in the Perl core. Change logs, test data, config files, etc... - Getting YAML.pm into the core is politically hard. It always degrades into a YAML vs XML argument. A small POY library can be snuck in without a lot of bruhaha. Why: - The full spec is rather difficult to implement completely. - POY is relatively easy. - POY covers the 80% of YAML that humans use. - POY removes all the really confusing parts - Easier to document - Easier to convince people of YAML's utility - People are going to implement subset parsers anyway, might as well have one official subset rather than N ad-hoc ones. Why Not: - Some parts of POY make no sense once others are removed, except to preserve forward compatibilty - reserved characters - space after the comment - It "waters down" the official spec. Problems with POY itself: - Collection flows are removed because they're difficult to parse, yet they're still useful for humans. I'd like to keep them if an easy way can be found to parse them. - Whither Unicode? - Unicode makes things complicated - Half the POY users won't care about Unicode - The other half need it. - Do we... - Require Unicode? - Make it optional? - Make a Unicode POY superset of POY (which remains a subset of YAML) - Use a simple subset of the YAML Unicode productions? Other Solutions: - Include in the YAML spec a recommended order of implementation so users at least have a guideline of what features are likely to be implemented and what are not. -- Michael G. Schwern <sc...@po...> http://www.pobox.com/~schwern/ Perl Quality Assurance <pe...@pe...> Kwalitee Is Job One I know you get this a lot, but you're breathtaking, like a vision of simplicity |
From: Steve H. <sh...@zi...> - 2002-12-05 02:25:38
|
On Wed, 2002-12-04 at 19:23, Michael G Schwern wrote: > As I mentioned in my eariler post, I found it useful to implement a small > parser for a subset of YAML geared towards configuration files and > relatively small amounts of meta-data. I'm proposing that YAML have an > official subset language to guide people who want to write small YAML > parsers. The working title is POY (Piece Of YAML). > > [...] > > Why: > - The full spec is rather difficult to implement completely. > - POY is relatively easy. > - POY covers the 80% of YAML that humans use. > - POY removes all the really confusing parts > - Easier to document > - Easier to convince people of YAML's utility > - People are going to implement subset parsers anyway, might as well have > one official subset rather than N ad-hoc ones. > > > --- - POY makes a ton of sense to me. - | We've written over 5000 lines of POY at my job. Here's the approximate breakdown: - metadata for generating html: 75% metadata for data layer: 10% expected/actual testing suites: 10% YAML inside of Python code: 5% - - we don't use aliases (*, &) - we don't use complex keys (?) - we don't use public types (!) - we don't use directives (#) - we don't use comments (# ) - we don't use unicode (\u) - we don't use folded text (>) - we use private types *very* sparingly (!!) - | we sometimes regret using multiple documents (---) instead of just relying on the file system or using arrays - we hate having to quote strings like 12 and 37 - performance has never been an issue - - we actually do round trip - we actually do use OrderedDict - we dig on indented text (we're Python programmers!) - | POY rocks! Every day I use POY, it changes the way I look at programming. I think every feature that we use is illustrated in this small document. |
From: Brian I. <in...@tt...> - 2002-12-05 07:09:50
|
On 04/12/02 21:27 -0500, Steve Howell wrote: > On Wed, 2002-12-04 at 19:23, Michael G Schwern wrote: > > As I mentioned in my eariler post, I found it useful to implement a small > > parser for a subset of YAML geared towards configuration files and > > relatively small amounts of meta-data. I'm proposing that YAML have an > > official subset language to guide people who want to write small YAML > > parsers. The working title is POY (Piece Of YAML). > > > > [...] > > > > Why: > > - The full spec is rather difficult to implement completely. > > - POY is relatively easy. > > - POY covers the 80% of YAML that humans use. > > - POY removes all the really confusing parts > > - Easier to document > > - Easier to convince people of YAML's utility > > - People are going to implement subset parsers anyway, might as well have > > one official subset rather than N ad-hoc ones. > > > > > > > > --- > - POY makes a ton of sense to me. > - | > We've written over 5000 lines of POY at my job. Here's > the approximate breakdown: > - > metadata for generating html: 75% > metadata for data layer: 10% > expected/actual testing suites: 10% > YAML inside of Python code: 5% > - > - we don't use aliases (*, &) > - we don't use complex keys (?) > - we don't use public types (!) > - we don't use directives (#) > - we don't use comments (# ) > - we don't use unicode (\u) > - we don't use folded text (>) > - we use private types *very* sparingly (!!) > - | > we sometimes regret using multiple documents (---) > instead of just relying on the file system or > using arrays > - we hate having to quote strings like 12 and 37 FYI, you don't have to do this. It is well within your right as a Loader author to support a LoadAsString or NoImplicits pragma. A good loader is encouraged to support the type repository as well as the language can handle. But the application can tell the Loader not to use certain features. Remember that the parser now returns (according to the spec): - 42 as a string value containing '42' and an *empty* type family string ''. ('42', '') The empty type family is a cue to the Loader to do implicit typing, if the application wanted implicit typing. This should probably be the default behaviour. - '42' Is returned as ('42', 'yaml.org/str'). - !foo 42 is ('42', 'foo') - ! '42' is ('42, '') - is ('', '') which the type repository says should be an implicit null. But a loader could load it differently. Say as an empty string. > - performance has never been an issue > - > - we actually do round trip > - we actually do use OrderedDict > - we dig on indented text (we're Python programmers!) > - | > POY rocks! Every day I use POY, it changes the > way I look at programming. I think every feature > that we use is illustrated in this small document. As a former cohort/coworker of Steve, I realize his feedback driven methodology of software design. It's a good way to build software. I like it when I can wear that hat. Wearing the language designer hat, I need to think in more general terms. I think it is fortunate that my/Clark's/Oren's use cases were all quite different. It forced us to think outside our boxes a bit. I think a lot of YAML is YAGNY. (You ain't gonna need it yet). Or YAGNIT (YAGNI Today) Why has already made good use of types in his rpc/schema work. ysh and YAML aliases have helped me a lot in understanding Perl internals. Flow collections are much nicer for Math folks (and yes I have a real user driving this) than block collections. YAML has enough rope to solve its own future problems. I feel like we have succeeded in our language design for the most part. Implementations are going through growing pains, but let me tell you, if we had full implementations of YAML if a half dozen languages, YAML would take off like a rocket ship. It's the right size for so many domains of problems, including the POY ones. Cheers, Brian |
From: Steve H. <sh...@zi...> - 2002-12-05 12:59:36
|
On Thu, 2002-12-05 at 02:09, Brian Ingerson wrote: > > Implementations are going through growing pains, but let me tell you, if > we had full implementations of YAML if a half dozen languages, YAML > would take off like a rocket ship. It's the right size for so many > domains of problems, including the POY ones. > Why does YAML need *full* implementations to get itself kickstarted? I like Schwern's idea of creating a POY spec, so that we can get some "stone soup" versions in PHP, Java, C, etc. We don't need a POY "spec" so much as we need a two-page cheat sheet. POY's easy to implement--Schwern, Why, Neil, Ingy, and I have all whipped through the first 20% of YAML when we wrote our parsers. (Am I correct about this? Am I leaving out other POY/YAML implementors?) Then we all slowed down, or even quit development, when the asymptotic approach toward YAML spec nirvana started showing fewer and fewer benefits per hour spent. Less is more. Cheers, Steve |
From: Brian I. <in...@tt...> - 2002-12-05 19:55:41
|
On 05/12/02 08:02 -0500, Steve Howell wrote: > On Thu, 2002-12-05 at 02:09, Brian Ingerson wrote: > > > > Implementations are going through growing pains, but let me tell you, if > > we had full implementations of YAML if a half dozen languages, YAML > > would take off like a rocket ship. It's the right size for so many > > domains of problems, including the POY ones. > > > > Why does YAML need *full* implementations to get itself kickstarted? I > like Schwern's idea of creating a POY spec, so that we can get some > "stone soup" versions in PHP, Java, C, etc. We don't need a POY "spec" > so much as we need a two-page cheat sheet. POY's easy to > implement--Schwern, Why, Neil, Ingy, and I have all whipped through the > first 20% of YAML when we wrote our parsers. (Am I correct about this? > Am I leaving out other POY/YAML implementors?) Then we all slowed down, > or even quit development, when the asymptotic approach toward YAML spec > nirvana started showing fewer and fewer benefits per hour spent. This is not really the case. Schwern is just beginning and does not have anything functional yet. Why never slowed down. Neil hit the pause button waiting for a stable spec, but has every intent to do a full implementation. Ingy has too many BDUF projects on his plate, but will make YAML.pm spec compliant. Showell would refactor his own family if he thought they were too crufty. I think most of the implementors believe in the YAML spec as a whole, even if some of the features don't coincide with their day job. It's a good spec for the design goals we initially laid out. It allows almost all data structures to be serialized in a human pleasing way. That said, I do like the idea of getting a lot of POY implementations going. Most implementations (excepting libyaml) will end up being POY by nature as a natural consequence of evolution. No need to spec this out. YAML.pm and yaml.py are two very good POY modules. Cheers, Brian |
From: Steve H. <sh...@zi...> - 2002-12-05 20:13:09
|
On Thu, 2002-12-05 at 14:55, Brian Ingerson wrote: > On 05/12/02 08:02 -0500, Steve Howell wrote: > > On Thu, 2002-12-05 at 02:09, Brian Ingerson wrote: > > > > > > Implementations are going through growing pains, but let me tell you, if > > > we had full implementations of YAML if a half dozen languages, YAML > > > would take off like a rocket ship. It's the right size for so many > > > domains of problems, including the POY ones. > > > > > > > Why does YAML need *full* implementations to get itself kickstarted? I > > like Schwern's idea of creating a POY spec, so that we can get some > > "stone soup" versions in PHP, Java, C, etc. We don't need a POY "spec" > > so much as we need a two-page cheat sheet. POY's easy to > > implement--Schwern, Why, Neil, Ingy, and I have all whipped through the > > first 20% of YAML when we wrote our parsers. (Am I correct about this? > > Am I leaving out other POY/YAML implementors?) Then we all slowed down, > > or even quit development, when the asymptotic approach toward YAML spec > > nirvana started showing fewer and fewer benefits per hour spent. > > This is not really the case. Schwern is just beginning and does not have > anything functional yet. Why never slowed down. Neil hit the pause > button waiting for a stable spec, but has every intent to do a full > implementation. Ingy has too many BDUF projects on his plate, but will > make YAML.pm spec compliant. Showell would refactor his own family if he > thought they were too crufty. > > I think most of the implementors believe in the YAML spec as a whole, > even if some of the features don't coincide with their day job. It's a > good spec for the design goals we initially laid out. It allows almost > all data structures to be serialized in a human pleasing way. > > That said, I do like the idea of getting a lot of POY implementations > going. Most implementations (excepting libyaml) will end up being POY by > nature as a natural consequence of evolution. No need to spec this out. > YAML.pm and yaml.py are two very good POY modules. > Why can't libyaml be POY? |
From: Steve H. <sh...@zi...> - 2002-12-05 23:59:44
|
It's cool that Michael has brought up the idea of POY (PieceOfYaml). I don't think we need much formality with POY, but I like the idea of encouraging subset implementations. I wonder, though, if we could steer Michael away from Perl and toward other languages that need POY more. POY for Perl is YAGNI. Perl's already got IMPBOY (Ingy' Much Bigger Piece Of YAML). Perl porter politics perplex me. What about POY could possibly make it it easier to install than IMBPOY? The yaml.pm that I remember was a couple thousand lines tops, all in one file, and it had no dependencies. Are Perl Porters scared of the extra text bits? Having said that, I like the idea of Porting Perl POY to PHP. I've had a couple people ask me about getting YAML in PHP. PHP seems superficially similar enough to Perl that it would be a pretty easy port. A POY implementation would be good stone soup for a BPOY implementation, which could then maybe grow into a NQBAY implementation or even a YWTC implementation. I also like the idea of libpoy in C. It would be a good end run around the Perl porters. Implement it in C, and patch Perl directly with POY. The other advantage of libpoy is that it would be a smaller API for other languages to bind to than the more BDUFfy libyaml. Cheers, Steve |
From: <ir...@ms...> - 2002-12-05 23:08:39
|
On Wed, Dec 04, 2002 at 09:27:51PM -0500, Steve Howell wrote: > we sometimes regret using multiple documents (---) > instead of just relying on the file system or > using arrays When have you regretted it? I've been using YAML in a few small applications and have found the multiple-document feature convenient. Of course it's the equivalent of a top-level list, but sometimes the data breaks down naturally that way. For instance, I'm using YAML to hold the metadata for a zine. Each file is one issue, and each document is one article in order. It so happens that you rarely need to refer to one issue from another but you do want to see all the article data together, and it's easier on the eye not to have that top-level list. All YAML documents are mappings of scalars, so it's very POY. Anyway, I standardized several data formats (.ini, rfc822, tab delimited) to YAML. There's one exception. The author information files are rfc822 because it's more flexible: - Blank/null values are allowed (current PyYAML requires ~) - Numeric scalars remain strings (current PyYAML converts to int) - The second space after ':' is not required. - The "e-mail body" section is a perfect place to store the one chunk of HTML needed (the author's bio), without indentation or other extra syntax crap. - PyYAML is missing document end (...), so putting non-YAML data (the bio HTML) after the YAML document is not an option. I could recode this to YAML and put the bio in a separate document or as a mapping item, but the effort/value ratio is too high. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Steve H. <sh...@zi...> - 2002-12-05 23:45:08
|
On Thu, 2002-12-05 at 18:08, Mike Orr wrote: > On Wed, Dec 04, 2002 at 09:27:51PM -0500, Steve Howell wrote: > > we sometimes regret using multiple documents (---) > > instead of just relying on the file system or > > using arrays > > When have you regretted it? We were putting the View/Edit/Manage/Remove screens all into one Unix file, with 4 YAML documents. Doing that shut off the ability to do things like grep foo View*.yml. It was our own stupidity--YAML didn't force us into it. Still, if things are truly separate documents, they belong in different files. If you have a bunch of data structures in the same file, then you have a glorified array, and the "---" is really just syntax sugar. I like the "---" feature in YAML, but I could easily live without it, is all I'm saying. > I've been using YAML in a few small > applications and have found the multiple-document feature convenient. > Of course it's the equivalent of a top-level list, but sometimes > the data breaks down naturally that way. For instance, I'm using YAML > to hold the metadata for a zine. Each file is one issue, and each > document is one article in order. It so happens that you rarely need > to refer to one issue from another but you do want to see all the > article data together, and it's easier on the eye not to have that > top-level list. All YAML documents are mappings of scalars, so it's > very POY. > Sure. > Anyway, I standardized several data formats (.ini, rfc822, tab > delimited) to YAML. There's one exception. The author information > files are rfc822 because it's more flexible: > - Blank/null values are allowed (current PyYAML requires ~) > - Numeric scalars remain strings (current PyYAML converts to int) > - The second space after ':' is not required. > - The "e-mail body" section is a perfect place to store the one chunk > of HTML needed (the author's bio), without indentation or other > extra syntax crap. > - PyYAML is missing document end (...), so putting non-YAML data > (the bio HTML) after the YAML document is not an option. > > I could recode this to YAML and put the bio in a separate document or > as a mapping item, but the effort/value ratio is too high. > Yep, some of those are on my list, particulary the numeric scalars thing. |
From: Michael G S. <sc...@po...> - 2002-12-06 00:05:38
|
On Thu, Dec 05, 2002 at 06:42:53PM -0500, Steve Howell wrote: > I like the "---" feature in YAML, but I could easily live without it, is > all I'm saying. Just to clarify, I left --- in POY because its easy to deal with and useful for logs and tests. I took ... out because it doesn't solve any problems I expect POY users to encounter. You can technically replace a --- with a top level array, but that means everything is indented which I find icky. Just style choice I guess. -- Michael G. Schwern <sc...@po...> http://www.pobox.com/~schwern/ Perl Quality Assurance <pe...@pe...> Kwalitee Is Job One 11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. -- RFC 1925 |
From: Brian I. <in...@tt...> - 2002-12-05 06:36:34
|
On 04/12/02 16:23 -0800, Michael G Schwern wrote: > As I mentioned in my eariler post, I found it useful to implement a small > parser for a subset of YAML geared towards configuration files and > relatively small amounts of meta-data. I'm proposing that YAML have an > official subset language to guide people who want to write small YAML > parsers. The working title is POY (Piece Of YAML). > > I see two broad usages for YAML. > > 1. Data serialization > 2. Metadata There are others. Logging and rpc-style messaging come to mind. Schema definition and data/text markup as well. There are different subsets out there. :) > Data serialization can be things like representing any language's arbitrary > data structures in YAML, complete with round-tripping. Its also things like > dumping out your store's inventory database into YAML for easier > transmission and interoperability. They can be extremely large. > > For these things you need anchors, aliases, transfer methods, complex keys, > etc... along with all the other YAML stuff. It also means YAML parsers must > be very efficient taking care not to require the whole YAML document be > loaded into memory in case you're reading from an IO stream or a very large > document. > > Metadata can be things like config files, build files (like Ant uses XML > for), change logs or extra data about a thing (like RPM spec header files). > They're often used in systems which are not centered around data. They tend > to be relatively small. These are typically written by a human or by very > simple code. For some of these things even POY is overkill. I Intend to do Inline.pm metafiles (.inl) in YAML, but I'm only interest in one value, so I regex the string for /^key: (\w+)$/. Since Inline generated the content, I don't need any general parser at all. I 0WN the data dewd. > They don't require round-tripping. Since they're small you can be sloppy > about how you use memory, often making parsing easier. You don't need > anchors, aliass, transfer methods or complex keys. > > > I see a very broad potential for YAML in metadata, since it means you get, > for free, a data format which is both machine and human readable rather than > inventing Yet Another Ad Hoc format. In those cases, YAML is merely a > convenience, not an essential part of the program. Making a dependency on a > full YAML parsing library might seem like overkill to an author or not be > possible. Using a small parser may be easier. > > > A small parser is certainly easier to write. My proof-of-concept state > parser (not finished) can be found here: > http://www.pobox.com/~schwern/tmp/YAML-POY/ > > The state transitions here: > http://www.pobox.com/~schwern/tmp/YAML-POY/States > > And a rough draft of the reduced spec (basically, the unneeded productions > were removed) here: > http://www.pobox.com/~schwern/tmp/POY.spec I like the idea of subset Loaders, because since all Loaders evolve, the most useful subset should be done first. (libyaml will change a lot of that. A lot of blindingly fast and accurate implementation will be available for free) But I'm against starting a *specification* that nails down a particular subset. Here are some randomly ordered reasons: - Specifications are HARD! They are big boiling pots of endless discussion. Your seemingly simple and innocent suggestion of simplifying the spec is not tempered with 18+ months of daily hardcore discussion. YAML specs don't grow on trees. - The config use case does not warrant interlanguage sharing of YAML config files, so why mandate the subset as a spec? If you do need to share, just pick the intersection of the implementation subsets. - There are already more YAML projects on the slate than we can get done in the next ten years. Another spec effort will spread us thin. - There will be a broad scale of use cases and picking features for a simplified spec will be slippery and subject to constant readjustment. - Once we bite the bullet and get full implementations (which are not that hard really) most of this will be a non issue. - libyaml will put a lot of issues to rest. > (BTW That's what your spec looks like when run through an html2text filter. > More on that in another post) > > Here is a short list of what was removed. Unless otherwise noted they were > removed because they're either not needed or difficult to parse or both. > - Collection flows > - Complex, multi-line or quoted keys. All that's left is "foo: " > - Scalar only documents > - Folded scalars (ie. >) > - Document end (ie. ...) > - Directives (ie. 3.3.2) > - Node Properties (ie. 3.3.4) > - Transfer Methods (ie. 3.3.5) > - Anchors (ie. 3.3.6) > - Aliases (ie. 3.4) > > These things are under consideration for removal. They're left in because > they're either needed or trivial to parse. > - Single and double quotes (I've figured an easy way to parse them easily) > - Unicode (a necessary evil) > - Explicit indentation (ie. |2) (very easy to handle) > - Chomping (ie. |-) (ditto) > > And the only actual addition to the spec is extending the reserved character > set to include things for forward compability with the full YAML spec. For > example, flow scalars in the small spec can't start with {, [, *, etc... > because it would mean something different in YAML. > > The spec is intended as a complete subset of YAML. Any POY document will > mean the same thing in YAML. This is important. The only way I would agree with subset implementations is if they are 100% subsets. > Real world use cases: > - MakeMaker > - Module::Build > - Perl is moving to a metadata format for modules (ie. a file to stick > things like Name, Author and Version into). Ruby too! I/Why should know. :) > - Both of these cannot depend on YAML.pm because of circular dependencies > (Module::Build gets away with it becuase YAML is currently built with > MakeMaker) I don't really think this is a problem. > - They would have to provide their own YAML parsers. The level of YAML they need could be handled by any version of YAML.pm and YAML.pm could not rely on any of the features of MakeMaker that needed YAML. BTW, YAML.pm will use CPAN::MakeMaker for all future releases. CP::MM can handle weak module deps, so CPAN shell will not break. These types of seemingly chicken/egg problems are almost always easily resolved. > - Perl core > - There are lots and lots of applications for YAML in the Perl core. > Change logs, test data, config files, etc... > - Getting YAML.pm into the core is politically hard. It always degrades > into a YAML vs XML argument. A small POY library can be snuck > in without a lot of bruhaha. With regards to MJD and his P5P Judo advice, I would really want to fight to get YAML.pm into the core. Yes it will be immensely useful as a build tool, etc, but it is even more useful as a whole. Sharing data between languages is my favorite use case. I'd love to see YAML in the Perl, Python, Ruby and Java cores for that reason alone. > Why: > - The full spec is rather difficult to implement completely. > - POY is relatively easy. > - POY covers the 80% of YAML that humans use. > - POY removes all the really confusing parts > - Easier to document > - Easier to convince people of YAML's utility > - People are going to implement subset parsers anyway, might as well have > one official subset rather than N ad-hoc ones. > > > Why Not: > - Some parts of POY make no sense once others are removed, except to > preserve forward compatibilty > - reserved characters > - space after the comment > - It "waters down" the official spec. In the final analysis, I'm not against competing implementations of YAML, but I don't think we'll be well served to stop and finalize what those subefforts should all look like. Keep working on your implementation. It can only lead to more knowledge of the YAML realm. Cheers, Brian |
From: <ir...@ms...> - 2002-12-05 22:44:36
|
I'm just catching up on the yaml-core mail from the past month. On Wed, Dec 04, 2002 at 04:23:39PM -0800, Michael G Schwern wrote: > I'm proposing that YAML have an > official subset language to guide people who want to write small YAML > parsers. But some users need this, and other users need that. For instance, I like document end (...), which you excluded. More to the point would be to simply prescribe a common format for documenting the differences between each POY (including the existing YAML implementations) and the YAML spec. That would make them easy to compare side by side. (including the existing YAML implementations) and the YAML spec. And it would be much less work than pinning down an official POY spec. Actually, a common POY spec may spontaneously emerge from this anyway, one based on actual usage. The format you used would be a good start: - A list of YAML features that are missing - A list of YAML features that are tentative - A list of "forward compatibility" features - A list of features incompatible with YAML - A list of use cases - Text explaining the rationale for the above > In those cases, YAML is merely a > convenience, not an essential part of the program. Making a dependency on a > full YAML parsing library might seem like overkill to an author or not be > possible. Using a small parser may be easier. ... and may be necessary in embedded systems. (Java doorknobs, anyone?) > Other Solutions: > - Include in the YAML spec a recommended order of implementation so users > at least have a guideline of what features are likely to be implemented > and what are not. This might be worthwhile. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Michael G S. <sc...@po...> - 2002-12-06 00:54:55
|
On Thu, Dec 05, 2002 at 06:57:28PM -0500, Steve Howell wrote: > It's cool that Michael has brought up the idea of POY (PieceOfYaml). I > don't think we need much formality with POY, but I like the idea of > encouraging subset implementations. I wonder, though, if we could steer > Michael away from Perl and toward other languages that need POY more. Michael knows Perl and enough C to clumsily patch perl. He is interested in learning Python and Ruby. Michael is not interested in learning PHP and would take far too long getting up to speed on C to be worthwhile. Its not like the exercise isn't worthwhile. If nothing else I'm learning the spec in detail which makes helping Ingy much easier. > POY for Perl is YAGNI. Perl's already got IMPBOY (Ingy' Much Bigger > Piece Of YAML). Perl porter politics perplex me. What about POY could > possibly make it it easier to install than IMBPOY? The yaml.pm that I > remember was a couple thousand lines tops, all in one file, and it had > no dependencies. Are Perl Porters scared of the extra text bits? Putting a new module into the Perl core is not a small decision. Its partially one of size, but its also one of future maintenance and compatibility. Once its in there, you can't get rid of it, the interface cannot break backwards compatibility and it has to work Everywhere. Above and beyond that is a general unfamiliarity with YAML and what its useful for, and some "we should use XML instead" arguments. With the former driving much of the latter. For most on p5p it was the first they'd heard of YAML so they didn't really grok it or why you'd want to use it for change logs and tests and module metadata files. So alot of time was spent just correcting misconceptions. The thing to combat is that unfamiliarity. I would like to sneak some YAML into the core of perl, the change log and tests, without having to go through the process of adding a new module. That way when people ask "What do we need YAML for?" we can point out all the places its already being used and they didn't even notice. :) Since there were no serious objections, a simple frontal attempt to get YAML.pm in might work, too. > I also like the idea of libpoy in C. It would be a good end run around > the Perl porters. Implement it in C, and patch Perl directly with POY. While a C library is a very good idea, this will be just as hard as getting a pure Perl module into the Perl core. Outside the core its harder to distribute a C library in Perl than a pure Perl module since most Windows users don't have compilers. -- Michael G. Schwern <sc...@po...> http://www.pobox.com/~schwern/ Perl Quality Assurance <pe...@pe...> Kwalitee Is Job One Don't ask me lady, I live in beer. |
From: Steve H. <sh...@zi...> - 2002-12-06 01:20:09
|
On Thu, 2002-12-05 at 19:53, Michael G Schwern wrote: > On Thu, Dec 05, 2002 at 06:57:28PM -0500, Steve Howell wrote: > [...] > > POY for Perl is YAGNI. Perl's already got IMPBOY (Ingy' Much Bigger > > Piece Of YAML). Perl porter politics perplex me. What about POY could > > possibly make it it easier to install than IMBPOY? The yaml.pm that I > > remember was a couple thousand lines tops, all in one file, and it had > > no dependencies. Are Perl Porters scared of the extra text bits? > > Putting a new module into the Perl core is not a small decision. Its > partially one of size, but its also one of future maintenance and > compatibility. Once its in there, you can't get rid of it, the interface > cannot break backwards compatibility and it has to work Everywhere. > [...] If you get POY into Perl, POY's implementation will become the de facto specification for indentation-structured data files in Perl. |
From: Steve H. <sh...@zi...> - 2002-12-06 01:32:19
|
On Thu, 2002-12-05 at 19:53, Michael G Schwern wrote: > [...] > For most on p5p it was the first they'd heard of YAML so they didn't really > grok it or why you'd want to use it for change logs and tests and module > metadata files. So alot of time was spent just correcting misconceptions. > > The thing to combat is that unfamiliarity. I would like to sneak some YAML > into the core of perl, the change log and tests, without having to go > through the process of adding a new module. That way when people ask "What > do we need YAML for?" we can point out all the places its already being used > and they didn't even notice. :) > What's a good place to find YAML examples on the web? I don't know. I'll be launching a PyYaml site soon. It's gonna be sprinkled with YAML. YAML is conspicuously absent from www.yaml.org's home page. YAML test suites totally rock. YAML.pm is a good place to start. I think Ingy should just put that somewhere up on the web where folks can easily click through it. |