From: Brian I. <in...@tt...> - 2003-01-04 06:48:43
|
Can I bring these up again? Rich's private message below got me thinking. I actually favor seq_in_seq, but think seq_in_map is more trouble than it's worth. I seem to remember an abiguity in seq_in_seq, but can't remember it now. seq_in_seq: --- - - foo - bar - - foo - bar #same as --- - - foo - bar - [foo, bar] ... --- - - - - - foo #is --- - - - - - foo #is --- - - - - - foo ... seq_in_map: --- foo-barred again!: - foo - bar ... Cheers, Brian PS Note to Oren. (In the friendliest of tones :) If approved you will assuredly be tempted to go ammend the spec. Please resist, and help with the Test Suite instead. It is here that we find bugs and deficiencies. And we could use your help. The spec will always be there to ammend. Let's bang a little harder on our theory. Pretty please? We can keep a running stack of approved proposals and then apply them all enmasse in a few months. ----- Forwarded message from Brian Ingerson <in...@tt...> ----- From: Brian Ingerson <in...@tt...> Date: Fri, 3 Jan 2003 22:08:46 -0800 To: Rich Morin <rd...@cf...> Cc: Brian Ingerson <in...@tt...> Subject: Re: [Yaml-core] encoding sequences of sequences? User-Agent: Mutt/1.2.5i On 03/01/03 21:40 -0800, Rich Morin wrote: > I've gotten this to work: > > - implies > - > - and > - [ isa, '?TRANSFER', TransferringPossession ] > - [ fromPossessor, '?TRANSFER', '?FROM' ] > - [ isa, '?FROM', SocialBeing ] > > so I'm a bit happier. I'm also (perversely) relieved to find out that > I had been running into a bug. I was beginning to feel _awfully_ lame. > > I'll take a look at the test suite, but I can't promise much. I'm so > murky about the spec that I'm guessing a lot (:-). Well, that's not much of an excuse. If your tests are at least close, we can easily fix them. > BTW, is there some reason that this: > > - implies > - - and > - [ isa, '?TRANSFER', TransferringPossession ] > - [ fromPossessor, '?TRANSFER', '?FROM' ] > - [ isa, '?FROM', SocialBeing ] > > shouldn't be allowed to work? Perhaps we can bring it up on the list. I think we've been down this path, but I really can't figure out why we disallowed it. I'll propose it. More simply: this: - - - foo is this: - - - foo Cheers, Brian ----- End forwarded message ----- |
From: Oren Ben-K. <or...@be...> - 2003-01-05 07:25:48
|
> Brian Ingerson wrote: > Can I bring these up again? I don't recall we've discussed this option. AFAIR map-in-seq wasn't easy to sell; at the time I doubt seq-in-seq would have made it. > this: > - - - foo > is this: > - > - > - foo Hmmm. There's no technical reason not to allow it. We need Clark... Have fun, Oren Ben-Kiki |
From: why t. l. s. <yam...@wh...> - 2003-01-13 02:23:33
|
Oren Ben-Kiki (or...@be...) wrote: > > > this: > > - - - foo > > is this: > > - > > - > > - foo > > Hmmm. There's no technical reason not to allow it. We need Clark... > I spent some time this weekend updating YAML.rb based on the new changes in the 2003 Jan 10 spec. I'm getting a reduce/reduce trying to implement this seq-in-seq. It's getting hung up on this case: - - Is that a sequence with a !boolean false? Or a multi-dimensional with a !null? I also think the triple '-' seq-in-seq is too much like a doc seperator. --- - - - --- - : - --- - - - : - Are these valid documents? _why |
From: Rich M. <rd...@cf...> - 2003-01-13 07:38:19
|
At 7:34 PM -0700 1/12/03, why the lucky stiff wrote: >I spent some time this weekend updating YAML.rb based on the new changes >in the 2003 Jan 10 spec. I'm getting a reduce/reduce trying to implement >this seq-in-seq. It's getting hung up on this case: >... >Is that a sequence with a !boolean false? Or a multi-dimensional with a >!null? >... >I also think the triple '-' seq-in-seq is too much like a doc seperator. >... >Are these valid documents? If stacking up dashes is actually ambiguous, I certainly wouldn't want the feature to go into the language. If, OTOH, it's merely an issue of parser complexity or imprecise specification, I would still ask for it. I find stacked-up dashes to be much cleaner (read, less annoying) than the stair-step equivalent. I think this is more important than the (slight, IMHO) possibility that someone might confuse "- - -" with "---". -r -- email: rd...@cf...; phone: +1 650-873-7841 http://www.cfcl.com/rdm - my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection |
From: why t. l. s. <yam...@wh...> - 2003-01-13 23:41:50
|
On Monday 13 January 2003 12:30 am, Rich Morin wrote: > > If stacking up dashes is actually ambiguous, I certainly wouldn't want > the feature to go into the language. If, OTOH, it's merely an issue of > parser complexity or imprecise specification, I would still ask for it. > It's just another feature that complicates writing a YAML parser. For=20 YAML.rb, it simply means an extra rule in the grammar. I personally don't find the stacked up dashes to be of any use. If I'm d= oing=20 a multi-dimensonial array, I would likely use inlines. It's not often th= at=20 you have multi-dimensional arrays that have scalar blocks in them. But I also find the boolean '+' and '-' to be expendable. I'd certainly = like=20 to get rid of them, as they add some complexity to dash parsing. I'd lik= e to=20 get rid of this test: - : The key should be false. And make it an error. We can't have both and I don't like either. _why |
From: Brian I. <in...@tt...> - 2003-01-14 01:53:51
|
On 13/01/03 16:52 -0700, why the lucky stiff wrote: > On Monday 13 January 2003 12:30 am, Rich Morin wrote: > > > > If stacking up dashes is actually ambiguous, I certainly wouldn't want > > the feature to go into the language. If, OTOH, it's merely an issue of > > parser complexity or imprecise specification, I would still ask for it. > > > > It's just another feature that complicates writing a YAML parser. For > YAML.rb, it simply means an extra rule in the grammar. > > I personally don't find the stacked up dashes to be of any use. If I'm doing > a multi-dimensonial array, I would likely use inlines. It's not often that > you have multi-dimensional arrays that have scalar blocks in them. > > But I also find the boolean '+' and '-' to be expendable. I'd certainly like > to get rid of them, as they add some complexity to dash parsing. I'd like to > get rid of this test: > > - : The key should be false. > > And make it an error. We can't have both and I don't like either. I never was a fan of the boolean type. Especially the '+'/'-' implicits. seq_in_seq is nice for YAML symetry though IMO, even if it doesn't show up in my personal use cases. I'll cast a vote for dropping these boolean implicits. We'll have to wait for Oren to get back from his vacation. Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2003-01-15 13:05:47
|
Brian Ingerson [mailto:in...@tt...] wrote: > I never was a fan of the boolean type. Especially the '+'/'-' > implicits. seq_in_seq is nice for YAML symetry though IMO, > even if it doesn't show up in my personal use cases. I'll > cast a vote for dropping these boolean implicits. We'll have > to wait for Oren to get back from his vacation. I have returned from my vacation earlier than I expected (see below if you want a good laugh at my expense). So... Thanks, why, for catching this ambiguity. Note that the problem isn't seq_in_seq, because now we allow flow scalars to start at the next line even this becomes ambiguous: Boolean: - Seq: - 1 Ambiguous: - Hence I agree with Brian. The only practical solution is to drop -/+ as implicit Booleans. Changing the sequence enter indicator from '-' to something else would also work, but isn't practical. In retrospect we shouldn't have tried to push this special case into the spec. So let's just take it out. I do wish we had some nice short, universal (i.e., non-English) implicits for Booleans... Looking at my keyboard I can't come up with anything reasonable, though. I guess we are stuck with the English words. Sigh. I do suggest, however, that we also allow y/n/Y/N, for brevity (the use case I'm thinking of is people writing config files). Thoughts? As for why's point: > I also think the triple '-' seq-in-seq is too much like a doc seperator. I agree with Rich Morin: > I find stacked-up dashes to be much cleaner (read, less annoying) > than the stair-step equivalent. I think this is more important > than the (slight, IMHO) possibility that someone might confuse > "- - -" with "---". Have fun, Oren Ben-Kiki P.S. About my vacation... As you may know I left on a two-week skiing vacation. I enrolled in a ski course to improve my style (for the first week). There was a large group of advanced students so the first day was somewhat of a "sorting day", quite tiring, and I was happy by the end of the day to have managed well. Tired and happy. Tired enough so when I got out of my gear I managed to bump by foot on the bed frame. Ouch. The next day that foot was painful, unless I was using a perfect ski position (properly leaning forward). So I did even better (it is amazing what instant feedback does for improving physical skills). This was a good thing as we went cruising through the world cup slope and the black slopes that follow it (highly recommended skiing area, BTW). However by the end of the lesson (afternoon) my foot was giving me hell, perfect ski position or no perfect ski position. So the instructor referred me to a doctor nearby who would "give me a painkiller and get me back on the slope for tomorrow". The doctor, a nice fellow, took some X-rays of the afflicted area and cheerfully informed me that: - My little toe is broken in two places; - I'm crazy to have skied this way; - I'm not the craziest he's seen, since there was always the German guy who skied for 3 hours on a broken shin bone (just below the kneecap); - Nevertheless, second place is respectable, and he doesn't recommend going for the record; - He's going to put my foot in plaster for a month; - This would impair my skiing ability somewhat for the duration, as can be imagined. Protests about the relative size and importance of a 5mm bone in a toe one doesn't use anyway were to no avail. So I packed what was left of my dignity (which wasn't much at that point) and hobbled back home on my plastered foot. I'm now spending the rest of my "vacation" at home. I've saved the money for the hotel, ski pass etc. (they were all very nice and refunded or canceled the payments), so I've decided to shift it to takeaways, cabs etc. for the duration instead, and just rot in home playing computer games. Oh, and do some YAML work, too :-) I figured the main good point about the above is that it would give a good laugh to my friends. It did, after all, give one to the doctor, the ski instructor, the hotel manager, and anyone else who heard about it, so I don't see why everyone else should be denied the pleasure. Go right ahead, then. Laugh. |
From: why t. l. s. <yam...@wh...> - 2003-01-15 16:45:07
|
On Wednesday 15 January 2003 06:05 am, Oren Ben-Kiki wrote: > - My little toe is broken in two places; > - I'm crazy to have skied this way; > - I'm not the craziest he's seen, since there was always the German guy > who skied for 3 hours on a broken shin bone (just below the kneecap); > - Nevertheless, second place is respectable, and he doesn't recommend > going for the record; > - He's going to put my foot in plaster for a month; > - This would impair my skiing ability somewhat for the duration, as can > be imagined. This list parses as valid YAML and I intend to put it the testing suite=20 straightaway! Good to hear you are in good spirits, though. I recently = had=20 a close call with my collarbone, which killed for two weeks, though I cou= ld=20 still manage most runs and was very skiddish of falling. I can't help but laugh, though! On the post of your bed! Poor Oren! _why |
From: Oren Ben-K. <or...@be...> - 2003-01-15 19:53:14
|
why the lucky stiff wrote: > This list parses as valid YAML and I intend to put it the > testing suite straightaway! Great! I did promise Brian I'll help with the test suite after all :-) Have fun, Oren Ben-Kiki |
From: Chris M. <cj...@fr...> - 2003-01-22 02:09:53
|
Hi YAML folks I have only just discovered the joys of YAML, it seems to be a very nice alternative to XML for readbility and editability. I have a project called Stag ( http://stag/sf/net ) which comprises two modules, one of which is released on CPAN called Data::Stag see http://search.cpan.org/author/CMUNGALL/Data-Stag-0.02/Data/Stag.pm Stag is for manipulating hierarchical tag/value data structures which are equivalent to a subset of XML (attributeless and no mixed content). When I saw YAML my first thought was to try and fold the functionality of Stag into YAML. However, it looks like the YAML model is a bit more complex than the Stag simple tag-value tree. However, I wonder if there might be ways to make my modules more YAML friendly. It seems we have both hit upon similar pythonesque syntax: http://search.cpan.org/author/CMUNGALL/Data-Stag-0.02/Data/Stag.pm#INDENTED_TEXT_REPRESENTATION Stag also allows lisp style S-Expression syntax - have you considered anything similar for YAML? http://search.cpan.org/author/CMUNGALL/Data-Stag-0.02/Data/Stag.pm#S_Expression_Lisp_representation Two of the reasons I developed Stag, rather than using existing XML modules were: * I wanted a functional-programming style of querying and transforming, instead of XPath/XSLT * I wanted simple data objects - the nodes in Stag act as if they are objects, with autogenerated methods for getting/setting and querying sub elements Is either of these of interested to YAMLers? Would it be worthwhile converging on a similar API, or are the models too different? One of Stag's main uses is in another module I am writing, for converting between relations and Stag datastructures. Seeing as there is at least superficial overlap in what we are doing, I thought I would try and solicit your opinions on Stag. Are there any obvious flaws? Is anything particularly insane about it? Is there any path for Stag / YAML convergence beyond via an xml bridge? Thanks for listening -- Chris |
From: Rich M. <rd...@cf...> - 2003-01-22 03:25:20
|
>Stag also allows lisp style S-Expression syntax - have you considered >anything similar for YAML? I have been playing with recasting CycL (a Lisp variant; see www.opencyc.org) into YAML. I call the result YACycL, FWIW. Here is some CycL: (#$implies (#$and (#$isa ?TRANSFER #$TransferringPossession) (#$fromPossessor ?TRANSFER ?FROM)) (#$isa ?FROM #$SocalBeing)) and the corresponding YACycL: [ implies, [ and, [ isa, ?TRANSFER, TransferringPossession ], [ fromPossessor, ?TRANSFER, ?FROM ] ], [ isa, ?FROM, SocialBeing ] ] Although yaml.pl won't currently parse the latter rendition, the spec. says it _should_, so it probably will (in the fullness of time :-). More generally, when you say that "the YAML model is a bit more complex than the Stag simple tag-value tree", you've said a mouthful. I consider XML's limited data model to be a severe deficiency; XML can't be used (in any reasonable way) to encode oddball structures (e.g., cyclic graphs). If you can find a way to add power to YAML, great, but please don't try to constrain YAML's set of constructs. -r -- email: rd...@cf...; phone: +1 650-873-7841 http://www.cfcl.com/rdm - my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection |
From: Oren Ben-K. <or...@be...> - 2003-01-22 07:28:40
|
STAG takes the following approach: - It is using Minimal-XML, as defined by SML-DEV (that is, using only XML elements, not allowing mixed content, plus many other restrictions on XML). It can't be used for most of the XML out there. - The data model is a subset of the XML data model (array of single-key hash tables). It can't be used for many data structures out there. It is agreed that YAML's data model is more complex (three basic constructs instead of two, plus type families). Likewise XML's model is more complex. The difference is that YAML's model maps directly to normal structures, while XML's doesn't. So you can think of STAG as the intersection between YAML and XML - the least common denominator. This is useful to have. Have fun, Oren Ben-Kiki |
From: Chris M. <cj...@fr...> - 2003-01-22 19:37:36
|
On Tue, 21 Jan 2003, Rich Morin wrote: > >Stag also allows lisp style S-Expression syntax - have you considered > >anything similar for YAML? > > I have been playing with recasting CycL (a Lisp variant; see www.opencyc.org) > into YAML. I call the result YACycL, FWIW. Here is some CycL: > > (#$implies > (#$and > (#$isa ?TRANSFER #$TransferringPossession) > (#$fromPossessor ?TRANSFER ?FROM)) > (#$isa ?FROM #$SocalBeing)) > > and the corresponding YACycL: > > [ implies, > [ and, > [ isa, ?TRANSFER, TransferringPossession ], > [ fromPossessor, ?TRANSFER, ?FROM ] ], > [ isa, ?FROM, SocialBeing ] ] very very nice! hmmmmmmm - possibly insane thought - can you put coderefs in there, and add a basic interpreter for some mad perl/lisp hybrid? > Although yaml.pl won't currently parse the latter rendition, the spec. > says it _should_, so it probably will (in the fullness of time :-). > > > More generally, when you say that "the YAML model is a bit more complex > than the Stag simple tag-value tree", you've said a mouthful. I consider > XML's limited data model to be a severe deficiency; XML can't be used (in > any reasonable way) to encode oddball structures (e.g., cyclic graphs). yep, agreed > If you can find a way to add power to YAML, great, but please don't try > to constrain YAML's set of constructs. Certainly not my intention > -r > |
From: Rich M. <rd...@cf...> - 2003-01-22 20:01:45
|
At 12:37 PM -0800 1/22/03, Chris Mungall wrote: >very very nice! It should ease the pain considerably, though I still have to deal with CycL's semantics. The things I like about YACycl are that: * Going from Perl <-> YACycL <-> CycL is trivial. * I find YACycL easier to read than CycL (:-). >hmmmmmmm - possibly insane thought - can you put coderefs in there, and >add a basic interpreter for some mad perl/lisp hybrid? You certainly could; the question is whether you would want to. YAML is a nifty way of dealing with the syntactic and structural levels; the semantic level is up to you. In my configuration files, I'm embedding Perl extended regular expression components into field descriptions: - name: pid head: PID patt: '\s*(\d+)' <----- type: canonical integer attr: [ static, unique ] defn: 'process ID' note: 'The pid is recycled, eventually.' I plan to stack the "patt" elements up in the running script and use them to parse the output of a command (e.g., ps). The "attr" elements then tell my script how to handle the resulting data. A "static" value only needs to be collected once; a "unique" value can be used as a key. One of the Lisp's big wins is its regularity (read, lack of :-) syntax. This lets Lisp programmers build "little languages", at will. I see no problem with using YAML in the same way... -r -- email: rd...@cf...; phone: +1 650-873-7841 http://www.cfcl.com/rdm - my home page, resume, etc. http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc. http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection |