From: Oren Ben-K. <or...@ri...> - 2001-11-29 09:21:49
|
Brian Ingerson [mailto:in...@tt...] wrote: > > Point #2: New syntax due to in-line collections. The intent > > is to provide > > the same capabilities in today's spec but in a way that > > doesn't castrate > > YMLT, YPATH etc. I agree with Clark that this is important > > enough so we > > either drop in-line collections or do them properly. > > Agreed. But we can readdress them later if we drop it for now. As the cost of changing the indicators - so converting all the files. Which means we'll have to settle it by YAML 1.0; *it can't be a YAML 1.1 thing*... So we *must* settle it before YAML 1.0 is announced. > > Point #4: If we do in-line map and seq properly, then IMVHO > > the right set of > > indicators to use is , for list, ; and = for maps... > > Disagree. See my post with subject "Inline Collections". I > really don't see a need for implicits beyond string, int and real. > Use the long form otherwise. I think allowing for dates, IP addresses, and other *scalar* types is very useful. I agree with you that ^<alpha> should be an implicit !str regexp. > > Point #6: In-line collections rock when it comes to simple > > scalars with > > internal structure such as names, complex numbers, 3D and > > 2D data, etc.: > > > > center = !point ,1,2,3 > > rotate = !quaternion ,0,0,1,0.5 > > price = !currency ,NIS,2.45 > > hmm. all strings, ints and reals here :) Sure, these are collections! But see how much more readable the above is compared to: center = !point , 1 , 2 , 3 rotate = !quaternion , 0 , 0 , 1 , 0.5 price = !currency , NIS , 2.45 Not to mention: this: 14:30 compared to: !time "14:30" > > OK, questions: > > > > Question #1: Do we move quoted to a style? > > yes OK. > > Question #2: Do we change the indicators to , for series > > and ; = for keyed? > > no Can we discuss this further? :-) > > Question #3: Do we add the in-line collection syntax (doing > > #2), or do we > > drop in-line collections? > > leaning towards drop. I agree as far as implementation "now" is concerned; I'm less certain about YAML 1.0, however. Still having fun :-) Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-11-29 19:38:18
|
Brian Ingerson wrote: > On 29/11/01 12:40 -0500, Clark C . Evans wrote: > Brian, thank you for humoring in-line collections, let's > > try to get a resolution quickly, or come up with a mechanism > > where we can defer the decision to a later date. Following > > is a proposal that allows us to defer this decision till > > later by reserving @ and % indicators. That said, if > > we get agreement in the next day or so, I'd rather not defer. > > OK I agree. I think Clark hit on something we can all agree on. I also rather not defer. > > center: !point @ 1,2,3 > > price: !currency @ USD,345.23 > > OK. > > > empty: @ > > If we also limit this to a single line, I approve. Now this is interesting: I suggest we revisit the idea that implicit scalars must be single line, period. I know clark likes: this: is a multi-line plain scalar (new terminology) But IMVHO if we restrict it to: this: \ is a multi-line plain scalar (new terminology) We aren't losing anything. If anything it is clearer. This way making the in-line collections be single lines would be a natural thing rather than an arbitrary restriction. > > in-line: !point % x=34,y=23 OK. > > If we go with an in-line sequence; between each > > comma would have to be a in-line scalar form. > > Otherwise we loose alot of power, as it would be > > impossible to have compact use of integers, dates, etc. > > OK OK > > The only "problem" with the above is that it doesn't > > have a similar syntax for to our "next-line" sequence > > or mapping styles. First, I'm not so sure that > > we want them to have a similar syntax since the rules > > are so very different. Second, I'm not positive > > that we should re-visit our existing "core" syntax. > > Agree. Agree. Agree. Disagree :-) This is *not* a problem. Just like for leaf nodes there's a different in-line and next-line format (next-line uses \ or | as indicator), for branch nodes also have different formats for in-line and next-line. Same principle. > > table: > > -@ name , rank , serial > > -@ John Edwards, Private First Class , '392-283-3828' > > -@ Martha Quip , Corporal , '328-383-4823' > > -@ Pip Rothe , Sergeant , '248-283-2824' Nice. > OK. So we allow *single_line* implicit and single line quoted. Great. Yes. No multi-line in-line, regardless of whether it is quoted, implicit, or a collection. in-line => one line; if it is more than one line starting at the next line shouldn't be a burden. > > Given that the above syntax should work, and be > > backwards compatible addition in the future; I'm > > happy to defer till later. > > Wow. Even better. I hadn't thought of that. I'm not very happy with defering, because: 1. We need to agree to limit implicit/quoted to one line. 2. I want a spec I can give people and say "this is it". Especially #2. If we agree on the above I think we can start implementing and finalize the spec in parallel - Clark has done a great job in doing the info model stuff, so we really aren't that far from a spec we can give people as "what YAML probably will be". If we leave things like in-line collections out, we don't have such a thing. To summerize what I understand to be the consensus: - Leaf nodes have \ \\ | || styles as today. - Otherwise an in-line leaf is ONE LINE only. - A "double quoted" in-line leaf is escaped. "" and \" represent ". - A 'single quoted' in-line leaf isn't escaped; '' represents '. - Any quoted in-lines leaf is !str by default. - Otherwise an in-line leaf is implicitly transfered. - An ^<alpha> implicit leaf is implicitly transfered as !str. - @ and % are BRANCH in-line styles. - They are ONE LINE just like the leaf in-line style is. - They are not otherwise related. - In line branches use , for separation; maps use key=value. - Entries are in any in-line leaf style and may have properties (anchors or transfer methods). The above is a nice merge of the good points of all the proposals we discussed so far. I suggest we agree on that, spec it and implement it. I have Aegis, the JDK and JUnit installed on my laptop already :-) I'll also be happy to do the productions work this weekend. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-11-29 19:59:30
|
| > OK. So we allow *single_line* implicit and single line quoted. Great. | | Yes. No multi-line in-line, regardless of whether it is quoted, implicit, or | a collection. in-line => one line; if it is more than one line starting at | the next line shouldn't be a burden. Big change. OK. No "spilling". This puts the nails in the RFC 822 compatibility coffin. ;) | - Leaf nodes have \ \\ | || styles as today. | - Otherwise an in-line leaf is ONE LINE only. | - A "double quoted" in-line leaf is escaped. "" and \" represent ". | - A 'single quoted' in-line leaf isn't escaped; '' represents '. | - Any quoted in-lines leaf is !str by default. | - Otherwise an in-line leaf is implicitly transfered. | - @ and % are BRANCH in-line styles. | - They are ONE LINE just like the leaf in-line style is. | - They are not otherwise related. | - In line branches use , for separation; maps use key=value. | - Entries are in any in-line leaf style and may have | properties (anchors or transfer methods). Ok. The key=value thing is ok. | - An ^<alpha> implicit leaf is implicitly transfered as !str. Fine with me, but given the single quote mechanism, is this needed any more? | The above is a nice merge of the good points of all the | proposals we discussed so far. I suggest we agree on that, | spec it and implement it. Good with me. Best, Clark |
From: Brian I. <in...@tt...> - 2001-11-30 02:12:41
|
Sorry to come in late. Very hectic day. Great work guys. I agree with everything, at least in part. I did have one more proposal but I was to swamped to do it until now. Even now I'm in a big rush to make a dinner date. OK... On 29/11/01 15:11 -0500, Clark C . Evans wrote: > | > OK. So we allow *single_line* implicit and single line quoted. Great. > | > | Yes. No multi-line in-line, regardless of whether it is quoted, implicit, or > | a collection. in-line => one line; if it is more than one line starting at > | the next line shouldn't be a burden. > > Big change. OK. No "spilling". This puts the nails > in the RFC 822 compatibility coffin. ;) I guess this works out ok. Are keys covered? I'll have to sleep on it, but my gut says OK. > | - Leaf nodes have \ \\ | || styles as today. Cool > | - Otherwise an in-line leaf is ONE LINE only. Sleeping on it... :) > | - A "double quoted" in-line leaf is escaped. "" and \" represent ". OK. Do we really need ""? It *is* escaped. > | - A 'single quoted' in-line leaf isn't escaped; '' represents '. OK > | - Any quoted in-lines leaf is !str by default. Yes! > | - Otherwise an in-line leaf is implicitly transfered. Yes! > | - @ and % are BRANCH in-line styles. Well here's the idea I've had all day but couldn;t say until now. I have a different proposal. I'd just like us to consider it. - { foo = bar, foo foo = 12:00, "quoted\n" = 3.1415 } - [ 5, 7, 9] - [ 3.14, foo bar, { time = 12:00 } ] - [] - {} Girlfriend just called. I'm in trouble. I hope you get the idea. The only advantage above is the ability to nest small vectors. Might be nice. The syntax is also crystal clear to Perl People. > | - They are ONE LINE just like the leaf in-line style is. Definitely. > | - They are not otherwise related. Yup. > | - In line branches use , for separation; maps use key=value. Right! > | - Entries are in any in-line leaf style and may have > | properties (anchors or transfer methods). > > Ok. The key=value thing is ok. cool. > | - An ^<alpha> implicit leaf is implicitly transfered as !str. yes. > Fine with me, but given the single quote mechanism, > is this needed any more? > > | The above is a nice merge of the good points of all the > | proposals we discussed so far. I suggest we agree on that, > | spec it and implement it. That sounds really good. Great work guys. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-11-30 02:33:10
|
On Thu, Nov 29, 2001 at 06:12:33PM -0800, Brian Ingerson wrote: | Sorry to come in late. Very hectic day. Great work guys. | I agree with everything, at least in part. Good deal. | > Big change. OK. No "spilling". This puts the nails | > in the RFC 822 compatibility coffin. ;) | | I guess this works out ok. Are keys covered? I'll have | to sleep on it, but my gut says OK. Yes. Keys would be single line as well... unless you use ? \ to have a next-line scalar key. I think Oren proposed this since it'll clean up the productions and will probably make the parser easier to write as well (since the in-line scalar form will be more uniform, less special cases). It may even make it easier to learn, less exceptions. And, if we really miss "spilling" in the next few weeks, we can always add it back (before the spec goes out). But I think removing it now would be good. | > | - A "double quoted" in-line leaf is escaped. "" and \" represent ". | | OK. Do we really need ""? It *is* escaped. We don't need "" -- I'd like this to be an err, no? | Well here's the idea I've had all day but couldn;t say until now. I have a | different proposal. I'd just like us to consider it. | | - { foo = bar, foo foo = 12:00, "quoted\n" = 3.1415 } | - [ 5, 7, 9] | - [ 3.14, foo bar, { time = 12:00 } ] | - [] | - {} | | The only advantage above is the ability to nest small vectors. Might be | nice. The syntax is also crystal clear to Perl People. 1) I'm not sure nesting is desireable. If someone has something this complex; perhaps it should be multiple lines (so indentation shows structure). 2) The pairing mechanism (Familar to most programmers) invites someone to write multi-line lists, and do nesting. This will then subvert our indention mechanism. So, while it's a nice idea; given your previous post where you clearly praise the nested structures via indentation... the above seems like a departure. But, then again, TMTOWTDI, right? I suggest if we do go this way, we should revisit the "spilling" question, or we'll have to have this as one of the first things in the FAQ: item: [ this spans multiple, lines so it is, NOT LEGAL ] Winks, Clark |
From: Brian I. <in...@tt...> - 2001-11-30 17:49:12
|
On 29/11/01 21:45 -0500, Clark C . Evans wrote: > On Thu, Nov 29, 2001 at 06:12:33PM -0800, Brian Ingerson wrote: > | I guess this works out ok. Are keys covered? I'll have > | to sleep on it, but my gut says OK. > > Yes. Keys would be single line as well... unless > you use ? \ to have a next-line scalar key. Seems good. > | > | - A "double quoted" in-line leaf is escaped. "" and \" represent ". > | > | OK. Do we really need ""? It *is* escaped. > > We don't need "" -- I'd like this to be an err, no? Error? - I didn't mean: "" - I meant: "Brian \"Ingy\" Ingerson" - Instead of: "Brian \"Ingy"" Ingerson" > | Well here's the idea I've had all day but couldn;t say until now. I have a > | different proposal. I'd just like us to consider it. > | > | - { foo = bar, foo foo = 12:00, "quoted\n" = 3.1415 } > | - [ 5, 7, 9] > | - [ 3.14, foo bar, { time = 12:00 } ] > | - [] > | - {} > | > | The only advantage above is the ability to nest small vectors. Might be > | nice. The syntax is also crystal clear to Perl People. > > 1) I'm not sure nesting is desireable. If someone has > something this complex; perhaps it should be multiple > lines (so indentation shows structure). I think that math people with want simple matrices like: - [[1, 3], [2, 4]] > 2) The pairing mechanism (Familar to most programmers) invites > someone to write multi-line lists, and do nesting. This > will then subvert our indention mechanism. Well, I can't stop someone from breaking the law. The law is "One Line". :) > So, while it's a nice idea; given your previous post > where you clearly praise the nested structures via > indentation... the above seems like a departure. But, > then again, TMTOWTDI, right? Well to be honest, I really couldn't have really suggested this in my previous post although I wanted to. My strongest intent was to keep this to one line. But if we do stick to the one line premise, I think [] gives us way more flexibility than @. One last point. If you consider these as our one line forms: - implicit - "quoted escaped" - 'quoted plain' - [inline, list] - {inline = map} There's a very nice symmetry in that the non-implicit ones all begin and end with a quoting (grouping) character. > > I suggest if we do go this way, we should revisit the > "spilling" question, or we'll have to have this as > one of the first things in the FAQ: > > > item: [ this spans multiple, lines so it is, > NOT LEGAL ] By all means. Lock that cheater up for life! Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-11-30 19:09:00
|
| > We don't need "" -- I'd like this to be an err, no? | | Error? | | - I didn't mean: "" | - I meant: "Brian \"Ingy\" Ingerson" | - Instead of: "Brian \"Ingy"" Ingerson" Exactly. The latter example is an error. | I think that math people with want simple matrices like: | | - [[1, 3], [2, 4]] Perhaps. But in this case, they would probably have their own "matrix" data type and not want it to parse into a list of lists... *grin* | - implicit | - "quoted escaped" | - 'quoted plain' | - [inline, list] | - {inline = map} | | There's a very nice symmetry in that the non-implicit ones | all begin and end with a quoting (grouping) character. Not a bad argument. I'll buy it. | > I suggest if we do go this way, we should revisit the | > "spilling" question, or we'll have to have this as | > one of the first things in the FAQ: | > | > | > item: [ this spans multiple, lines so it is, | > NOT LEGAL ] | | By all means. Lock that cheater up for life! I'm not so sure I want to have this question appear on the list again and again. Could someone from the audience pipe in here? Clark |
From: Clark C . E. <cc...@cl...> - 2001-11-30 03:19:41
|
| Well here's the idea I've had all day but couldn;t say until now. I have a | different proposal. I'd just like us to consider it. | | - { foo = bar, foo foo = 12:00, "quoted\n" = 3.1415 } | - [ 5, 7, 9] | - [ 3.14, foo bar, { time = 12:00 } ] | - [] | - {} Ok. I'm going to put on my psychic hat and guess that Brian doesn't like the @ and % indicators. Imagine the following two examples... --- -@ name , hr, avg, rbi -@ Mark McGwire, 65, .278, 147 -@ Sammy Sosa , 63, .288, 141 --- !org.clarkevans.vector-graphics.image - !.circle center: !.point % x=23, y=29 radius: 7 - !.line % x=2,y=4,h=23,w=19 Imagine three limitations on implict scalars: 1) they are one line only (previous limit) 2) they do not contain the equal sign 3) they do not contain the comma If we did this, we could drop the indicator all together.... --- - name , hr, avg, rbi - Mark McGwire, 65, .278, 147 - Sammy Sosa , 63, .288, 141 --- !org.clarkevans.vector-graphics.image - !.circle center: !.point x=23, y=29 radius: 7 - !.line x=2,y=4,h=23,w=19 It's a bit cleaner (not much). We pay for this simpler syntax with a wee bit of of look-ahead (exactly three tokens) but I don't mind this too much since it's limited to a single line. I can't think of why I'd use an equal sign... and I can quote in this case. Lastly, commas may be useful for things like someone's name.... "Evans, Clark", but once again, I can quote in this case... or better yet, just treat the name as a small sequence "as god had intended". Since we don't have the "spill" case, someone won't try to put a paragraph here (and be frustrated that the comma turns their paragraph into two chunks). So. We can do this... but we really must stick with the one line limitation... no spilling. Thoughts? Clark |
From: Brian I. <in...@tt...> - 2001-11-30 17:54:00
|
On 29/11/01 22:31 -0500, Clark C . Evans wrote: > | Well here's the idea I've had all day but couldn;t say until now. I have a > | different proposal. I'd just like us to consider it. > | > | - { foo = bar, foo foo = 12:00, "quoted\n" = 3.1415 } > | - [ 5, 7, 9] > | - [ 3.14, foo bar, { time = 12:00 } ] > | - [] > | - {} > > Ok. I'm going to put on my psychic hat and guess that > Brian doesn't like the @ and % indicators. Imagine the > following two examples... Wow. Amazing insight. I have some other questions to ask you about my future... :) > --- > -@ name , hr, avg, rbi > -@ Mark McGwire, 65, .278, 147 > -@ Sammy Sosa , 63, .288, 141 > > > --- !org.clarkevans.vector-graphics.image > - !.circle > center: !.point % x=23, y=29 > radius: 7 > - !.line % x=2,y=4,h=23,w=19 > > Imagine three limitations on implict scalars: > 1) they are one line only (previous limit) > 2) they do not contain the equal sign > 3) they do not contain the comma > > If we did this, we could drop the indicator > all together.... > > --- > - name , hr, avg, rbi > - Mark McGwire, 65, .278, 147 > - Sammy Sosa , 63, .288, 141 > > > --- !org.clarkevans.vector-graphics.image > - !.circle > center: !.point x=23, y=29 > radius: 7 > - !.line x=2,y=4,h=23,w=19 > > It's a bit cleaner (not much). We pay for this simpler > syntax with a wee bit of of look-ahead (exactly three > tokens) but I don't mind this too much since it's limited > to a single line. I can't think of why I'd use an equal > sign... and I can quote in this case. Lastly, commas > may be useful for things like someone's name.... > "Evans, Clark", but once again, I can quote in this > case... or better yet, just treat the name as a small > sequence "as god had intended". Since we don't have > the "spill" case, someone won't try to put a > paragraph here (and be frustrated that the comma > turns their paragraph into two chunks). So. We > can do this... but we really must stick with the > one line limitation... no spilling. > > Thoughts? Wow again Clark! This is a really great idea. It does preclude any simple nesting, but I do like it over @ %. Great insight. +1 Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2001-11-29 19:46:01
|
Clark C . Evans wrote: > But I'm not happy with the equal sign in the > mapping syntax; I'd rather use the colon since > we've given the equal sign a meaning, it is > the default value of the mapping. So, I was > just thinking we could use the colon (separated > by commas). Date values!!!!! in-line-mapping: !meeting when=14:30,where=Room 12,who=Boss Please keep it '='... > I'm not sure if we > should allow a single-line double quoted. Given > that we have to support it in other places, I don't > see the harm. We don't need to support multi-line quotes anywhere. > If we have full agreement on the implications > (which seem rather local so I'm not too worried > about them), then it might be good to include > this in the first draft. IMHO, the usecases > are compelling enough: Agreed. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-11-30 08:43:24
|
Clark C . Evans [mailto:cc...@cl...] wrote: > | > | - A "double quoted" in-line leaf is escaped. "" and \" > | > | represent ". > | > | OK. Do we really need ""? It *is* escaped. > > We don't need "" -- I'd like this to be an err, no? OK. No "". Just \" in " ... " and '' in ' ... ' > | Well here's the idea I've had all day but couldn;t say > | until now. I have a > | different proposal. I'd just like us to consider it. > | > | - { foo = bar, foo foo = 12:00, "quoted\n" = 3.1415 } > | - [ 5, 7, 9] > > 1) I'm not sure nesting is desireable. If someone has > something this complex; perhaps it should be multiple > lines (so indentation shows structure). +1 > 2) The pairing mechanism (Familar to most programmers) invites > someone to write multi-line lists, and do nesting. This > will then subvert our indention mechanism. ++1 > I suggest if we do go this way, we should revisit the > "spilling" question, or we'll have to have this as > one of the first things in the FAQ: > > item: [ this spans multiple, lines so it is, > NOT LEGAL ] Enough said :-) Keep @ and % as indicators, and let [] and {} be used for other things. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-11-30 08:49:58
|
Clark C . Evans [mailto:cc...@cl...] wrote: > Ok. I'm going to put on my psychic hat and guess that > Brian doesn't like the @ and % indicators. You know, we only use @ and % because of their Perl ancestry. It is sort of funny to have Brian of all people not like them :-) > Imagine the > following two examples... > > --- > -@ name , hr, avg, rbi > -@ Mark McGwire, 65, .278, 147 > -@ Sammy Sosa , 63, .288, 141 > > > --- !org.clarkevans.vector-graphics.image > - !.circle > center: !.point % x=23, y=29 > radius: 7 > - !.line % x=2,y=4,h=23,w=19 > > Imagine three limitations on implict scalars: > 1) they are one line only (previous limit) > 2) they do not contain the equal sign > 3) they do not contain the comma So instead of having a prefix indicator, here we have an infix one (contains '=' -> keyed; contains ',' -> series). Hmmm... I guess I could go with that... > If we did this, we could drop the indicator > all together.... > > --- > - name , hr, avg, rbi > - Mark McGwire, 65, .278, 147 > - Sammy Sosa , 63, .288, 141 > > > --- !org.clarkevans.vector-graphics.image > - !.circle > center: !.point x=23, y=29 > radius: 7 > - !.line x=2,y=4,h=23,w=19 It does look much better, I admit. > So. We > can do this... but we really must stick with the > one line limitation... no spilling. > > Thoughts? I'll go with it if Brian likes it. Otherwise use @ and %. NOT [] and {}. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-11-30 09:27:54
|
Oren Ben-Kiki [mailto:or...@ri...] wrote: > So instead of having a prefix indicator, here we have an > infix one (contains '=' -> keyed; contains ',' -> series). A problem with that. Using @ and %, we allow quoted values in in-line collections: in-line: % "," = separator, "%" = keyed, "@" = series A similar problem: how does one give properties to the first key or entry: dates: !deadlines @ ! 2001-11-31 12:50:00, ! 2001-12-01 08:30:00 So: we must - keep the indicators, or - require that all keys/values must be unquoted (always implicitly transfered) scalars without any property annotation. I say we keep the indicators. And I still don't like [] and {} :-) Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-11-30 18:20:29
|
On 30/11/01 11:28 +0200, Oren Ben-Kiki wrote: > Oren Ben-Kiki [mailto:or...@ri...] wrote: > > So instead of having a prefix indicator, here we have an > > infix one (contains '=' -> keyed; contains ',' -> series). > > A problem with that. Using @ and %, we allow quoted values in in-line > collections: > > in-line: % "," = separator, "%" = keyed, "@" = series I don't see the problem. I could definitely parse that without conflict. > A similar problem: how does one give properties to the first key or entry: > > dates: !deadlines @ ! 2001-11-31 12:50:00, ! 2001-12-01 08:30:00 The first property goes to the first element. One simply cannot give properties to the inline collection as a whole. They need to use the normal structure in this case. This is perfectly reasonable since this mechanism is supposed to be for simple things. > So: we must > - keep the indicators, or > - require that all keys/values must be unquoted (always implicitly > transfered) scalars without any property annotation. > > I say we keep the indicators. And I still don't like [] and {} :-) Or not. :) Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-11-30 19:05:41
|
| > dates: !deadlines @ ! 2001-11-31 12:50:00, ! 2001-12-01 08:30:00 | | The first property goes to the first element. One simply cannot give | properties to the inline collection as a whole. They need to use the normal | structure in this case. Close, but let's do it the other way since the common case one would want the properties to bind to the in-line mapping/sequence. So, if someone uses an indicator after the comma, it is an error. center: !!point 4,5 Best, Clark |
From: Brian I. <in...@tt...> - 2001-11-30 18:02:01
|
On 30/11/01 10:50 +0200, Oren Ben-Kiki wrote: > Clark C . Evans [mailto:cc...@cl...] wrote: > > Ok. I'm going to put on my psychic hat and guess that > > Brian doesn't like the @ and % indicators. > > You know, we only use @ and % because of their Perl ancestry. It is sort of > funny to have Brian of all people not like them :-) It *is* ironic in one sense. But in another I guess I just want them to be used in an elegant way. I guess just haven't felt that yet. > I'll go with it if Brian likes it. Otherwise use @ and %. NOT [] and {}. I'm cool with it as long as we can reserve [] and {} for consideration of my propsed use in the future. Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2001-11-30 19:39:48
|
Clark C . Evans wrote: > | I think that math people with want simple matrices like: > | > | - [[1, 3], [2, 4]] Rather than: - -@ 1, 3 -@ 2, 4 > Perhaps. But in this case, they would probably have > their own "matrix" data type and not want it to parse > into a list of lists... *grin* But we *would* want the matrix members to be addressible via YPATH - that's the whole idea. So Brian does have a point. I'm warming up towards using '[]' and '{}' due to his argument: > | - implicit > | - "quoted escaped" > | - 'quoted plain' > | - [inline, list] > | - {inline = map} > | > | There's a very nice symmetry in that the non-implicit ones > | all begin and end with a quoting (grouping) character. And are all in-line one-line formats! > Not a bad argument. I'll buy it. I guess I can buy it too - if we are fanatical about keeping it one-line: lunch: !meeting { time = ! 12:30, place = Palm } Otherwise it is back to the indicators: lunch: !meeting % date = ! 2001-11-30 12:30:00, place = Palm You can't do the above without either '%' or {}, and it is too useful to give up (dates!!!). > | > I suggest if we do go this way, we should revisit the > | > "spilling" question, or we'll have to have this as > | > one of the first things in the FAQ: > | > > | > > | > item: [ this spans multiple, lines so it is, > | > NOT LEGAL ] > | > | By all means. Lock that cheater up for life! > > I'm not so sure I want to have this question > appear on the list again and again. Could someone > from the audience pipe in here? Brian likes {}/[] better than @/%. I tend towards the indicators, but if both of you agree I'll go with either choice - not for the indicator-free format. Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-11-29 16:52:01
|
> | > I really don't see a need for implicits beyond > | > string, int and real. Use the long form otherwise. > | > | I think allowing for dates, IP addresses, and > | other *scalar* types is very useful. > | > | I agree with you that ^<alpha> should be an implicit !str regexp. I'd like !date and !time at the minimum, !currency would also be a nice implicit. I these three scalar types are found more often in my data than floats. They are "core" data types to me. > Well, if time, ip and currency *were* implicits then > we could just do: > > lunch: 14:30 > ip: 192.168.2.1 > price: $10.5 > > I don't see what this argument has to do with > Inline Collections Correct. This doesn't have anything to do with inline collections. However, it is a slight indicator/production complexity which must be managed carefully. When time 10:30 is used as a key, it must be escaped. So, if we want it to be unquoted as a value, we need yet-another scalar type... (7 of them), this seventh is the "implicit-key". That said, I think we need the implicit-key anyway to restrict the keys from containing new lines. Best, Clark |
From: Clark C . E. <cc...@cl...> - 2001-11-29 17:28:57
|
Brian, thank you for humoring in-line collections, let's try to get a resolution quickly, or come up with a mechanism where we can defer the decision to a later date. Following is a proposal that allows us to defer this decision till later by reserving @ and % indicators. That said, if we get agreement in the next day or so, I'd rather not defer. ... The use-case driving us are small sequences, especially coordinates, well-known tuples, etc. Without in-line sequences, both of the examples below become multi-line. center: !point @ 1,2,3 price: !currency @ USD,345.23 The examples above re-introduce the @ indicator for the in-line sequence, where all items in an in-line sequence are separated by a comma. We could even use this as an implict way to mark an empty sequence; as the in-line or next-line are just styles. empty: @ ... I have less sympathy for the in-line mapping. In my opinion, this can be happliy omitted. However, if we do decide to go there. I think it could also have a radically different syntax. in-line: !point % x=34,y=23 I don't see why we have to merge our syntaxes for some hope of consistency. ... If we go with an in-line sequence; between each comma would have to be a in-line scalar form. Otherwise we loose alot of power, as it would be impossible to have compact use of integers, dates, etc. ... The only "problem" with the above is that it doesn't have a similar syntax for to our "next-line" sequence or mapping styles. First, I'm not so sure that we want them to have a similar syntax since the rules are so very different. Second, I'm not positive that we should re-visit our existing "core" syntax. table: -@ name , rank , serial -@ John Edwards, Private First Class , '392-283-3828' -@ Martha Quip , Corporal , '328-383-4823' -@ Pip Rothe , Sergeant , '248-283-2824' I like the different syntax actually... and note the use of implicit scalar. Serial would have matched the date format, so it had to be quoted. ... Given that the above syntax should work, and be backwards compatible addition in the future; I'm happy to defer till later. Best, Clark |
From: Brian I. <in...@tt...> - 2001-11-29 18:37:19
|
On 29/11/01 12:40 -0500, Clark C . Evans wrote: > Brian, thank you for humoring in-line collections, let's > try to get a resolution quickly, or come up with a mechanism > where we can defer the decision to a later date. Following > is a proposal that allows us to defer this decision till > later by reserving @ and % indicators. That said, if > we get agreement in the next day or so, I'd rather not defer. OK > The use-case driving us are small sequences, especially ================================= collections Absolutely. > coordinates, well-known tuples, etc. Without in-line > sequences, both of the examples below become multi-line. > > center: !point @ 1,2,3 > price: !currency @ USD,345.23 > > The examples above re-introduce the @ indicator for the > in-line sequence, where all items in an in-line sequence > are separated by a comma. We could even use this as an > implict way to mark an empty sequence; as the in-line > or next-line are just styles. > > empty: @ If we also limit this to a single line, I approve. > I have less sympathy for the in-line mapping. In > my opinion, this can be happliy omitted. However, > if we do decide to go there. I think it could > also have a radically different syntax. Agree on all counts. Especially the point that we are allowed to be different in this case. > in-line: !point % x=34,y=23 > > I don't see why we have to merge our syntaxes for > some hope of consistency. This was my struggle as well. Perl is heavy on the concept of "lexical texture". Making things look different so they are not tiresome on the mind. Trying to reduce things to a single syntax is more of an optimization for computers than humans. > If we go with an in-line sequence; between each > comma would have to be a in-line scalar form. > Otherwise we loose alot of power, as it would be > impossible to have compact use of integers, dates, etc. OK > The only "problem" with the above is that it doesn't > have a similar syntax for to our "next-line" sequence > or mapping styles. First, I'm not so sure that > we want them to have a similar syntax since the rules > are so very different. Second, I'm not positive > that we should re-visit our existing "core" syntax. Agree. Agree. Agree. > > table: > -@ name , rank , serial > -@ John Edwards, Private First Class , '392-283-3828' > -@ Martha Quip , Corporal , '328-383-4823' > -@ Pip Rothe , Sergeant , '248-283-2824' > > I like the different syntax actually... and note > the use of implicit scalar. Serial would have > matched the date format, so it had to be quoted. OK. So we allow *single_line* implicit and single line quoted. Great. > Given that the above syntax should work, and be > backwards compatible addition in the future; I'm > happy to defer till later. Wow. Even better. I hadn't thought of that. Great work. Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-11-29 19:07:24
|
Great. A few thoughts on the specific in-line collection syntax. I personally like the in-line sequence syntax presented. But I'm not happy with the equal sign in the mapping syntax; I'd rather use the colon since we've given the equal sign a meaning, it is the default value of the mapping. So, I was just thinking we could use the colon (separated by commas). in-line-mapping: !point % x:34,y:23 | > table: | > -@ name , rank , serial | > -@ John Edwards, Private First Class , '392-283-3828' | > -@ Martha Quip , Corporal , '328-383-4823' | > -@ Pip Rothe , Sergeant , '248-283-2824' | | OK. So we allow *single_line* implicit and single | line quoted. Great. And as you said, we limit these forms so that they do not contain the new line. I'm not sure if we should allow a single-line double quoted. Given that we have to support it in other places, I don't see the harm. Also above I wrote '-@ ' instead of '- @ ' it would be nice if this was allowd by the syntax productions; but not necessary. | > Given that the above syntax should work, and be | > backwards compatible addition in the future; I'm | > happy to defer till later. | | Wow. Even better. I hadn't thought of that. If we have full agreement on the implications (which seem rather local so I'm not too worried about them), then it might be good to include this in the first draft. IMHO, the usecases are compelling enough: 1. We can be a better syntax for SVG than XML through our "point" structure. 2. We pretty much have CSV built-in for very clear expression of tables; in other words, YAML can be great for returing hierarchial SQL result sets. Beautyful in fact. Best, Clark |