From: Oren Ben-K. <or...@be...> - 2002-12-25 12:10:12
|
Following are latest discussions, I'm going over the draft making the following changes: - Have comments start with ' #' instead of ' # '. - Make directives start with '%' instead of '#'. - Allow flow values to start on the next line. I'm also doing a quick review of the data types. The biggest headache is the time type. It is basically adequate for the purpose of defining a point in time, though we the following open issues: - Whether '2002-01-01' is the same as '2002-01-01 00:00:00 Z' or '2002-01-01 12:00:00 Z' - Whether a time zone is required if there's a time part, or whether to make 'Z' the default. In addition, this data type is obviously unfit for specifying durations. I had the notion that we can avoid defining a timeperiod data type for this by allowing base 60 numbers, using ':'. For example: --- # The following are equal integers - 450 - 420:30 - 1:1:30 # One hour and a minute and a half # The following are equal floats - 450.17 - 420:30.17 - 1:1:30.17 # An hour, a minute and 30.17 seconds # Useful for other stuff too... - 57:33:20.35 # 57 degrees, 33 minutes and 20.25 seconds ... The semantics would be that a ':' indicates the value to its left is multiplied by 60 and added to the value to its right (which should be less than 60, followed by '.' or ':'). In floats, ':' would only be permitted on the left of the '.'. This would similar to using base 8 and base 16 for enhanced readability. Just like UNIX permissions are most readable when written in octal, and binary words are most readable written in hexadecimal, time periods (and angles, and geographical coordinates) would be most readable when written in base 60. Thoughts? Another issue is the proper name for the ordered map data type. We have 'map' for unordered set of unique-key/value pairs, 'pairs' for an ordered set of duplicate-key/value pairs, and currently 'omap' for ordered set of unique-key/value pairs. 'omap' is a horrid name, and perhaps this horrid data type deserves it - but I'd still be happy if anyone can come up with a better name for it. The only language that I know of that has this type as a native data type is PHP, where it is called 'array', which is obviously unacceptable to us. I wanted to call it 'dict', as it is exactly what you find when you open a real-world dictionary. Clark has vetoed that because 'dict' is used in some languages to mean 'map' (specifically, Python :-). Searching for synonyms, the best I could find is 'lexicon' or 'glossary' which I feel are too obscure. It seems we are stuck with 'omap' - unless <hopeful>can someone up with something better?</hopeful> Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2002-12-25 22:36:55
|
NOTE: It would be groovy if you could indent your YAML code in emails. Putting characters like '-' in column 1, confuses my eyes and my mailer. Thanks. On 25/12/02 14:09 +0200, Oren Ben-Kiki wrote: > Following are latest discussions, I'm going over the draft making the > following changes: > > - Have comments start with ' #' instead of ' # '. > - Make directives start with '%' instead of '#'. > - Allow flow values to start on the next line. Everyone agrees except Clark, who seems to have disappeared. > I'm also doing a quick review of the data types. The biggest headache is > the time type. It is basically adequate for the purpose of defining a > point in time, though we the following open issues: > > - Whether '2002-01-01' is the same as '2002-01-01 00:00:00 Z' or > '2002-01-01 12:00:00 Z' > - Whether a time zone is required if there's a time part, or whether to > make 'Z' the default. > > In addition, this data type is obviously unfit for specifying durations. > I had the notion that we can avoid defining a timeperiod data type for > this by allowing base 60 numbers, using ':'. For example: One meta point about types. YAGNI. Let real users bring up there issues as they need them. This is why we ripped types out of the spec. If you're trolling for stuff to debate, let's do it in the realm of implementations. Spec stuff is soooo 2002, man. > --- > # The following are equal integers > - 450 > - 420:30 > - 1:1:30 # One hour and a minute and a half > # The following are equal floats > - 450.17 > - 420:30.17 > - 1:1:30.17 # An hour, a minute and 30.17 seconds > # Useful for other stuff too... > - 57:33:20.35 # 57 degrees, 33 minutes and 20.25 seconds > ... > > The semantics would be that a ':' indicates the value to its left is > multiplied by 60 and added to the value to its right (which should be > less than 60, followed by '.' or ':'). In floats, ':' would only be > permitted on the left of the '.'. > > This would similar to using base 8 and base 16 for enhanced readability. > Just like UNIX permissions are most readable when written in octal, and > binary words are most readable written in hexadecimal, time periods (and > angles, and geographical coordinates) would be most readable when > written in base 60. > > Thoughts? > > Another issue is the proper name for the ordered map data type. We have > 'map' for unordered set of unique-key/value pairs, 'pairs' for an > ordered set of duplicate-key/value pairs, and currently 'omap' for > ordered set of unique-key/value pairs. 'omap' is a horrid name, and > perhaps this horrid data type deserves it - but I'd still be happy if > anyone can come up with a better name for it. > > The only language that I know of that has this type as a native data > type is PHP, where it is called 'array', which is obviously unacceptable > to us. I wanted to call it 'dict', as it is exactly what you find when > you open a real-world dictionary. Clark has vetoed that because 'dict' > is used in some languages to mean 'map' (specifically, Python :-). > Searching for synonyms, the best I could find is 'lexicon' or 'glossary' > which I feel are too obscure. It seems we are stuck with 'omap' - unless > <hopeful>can someone up with something better?</hopeful> Methinks Oren is trying to avoid writing code by digging up spec ghosts. I for one will not take the bait. Sorry Oren. I *am* one tasty fish. :) --- Sorry to sound grumpy. I do have the fact that is Christmas day, and I'm low on caffeine, backing me up. But hey... I actually do have some constructive things to bring to the table. Why and I had a chat this week about revamping the testing suite. In a very real way, the Testing Suite is the defacto spec for YAML. It shows compliance in real numbers. In my mind it is the number one most important thing for YAML at the moment. The traditional spec is really only important for implementors of the Testing Suite. How's that for a new spin? I like it. Currently we have a testing suite but it is fairly shallow and one sided. ... time passes ... ... coffee is consumed ... I have some really exciting ideas. I'll put them into a new post. --- Cheers: Brian |
From: Oren Ben-K. <or...@be...> - 2002-12-26 20:23:49
|
Brian Ingerson wrote: > > - Have comments start with ' #' instead of ' # '. > > - Make directives start with '%' instead of '#'. > > - Allow flow values to start on the next line. > > Everyone agrees except Clark, who seems to have disappeared. I'll just go ahead then. > One meta point about types. YAGNI. Let real users bring up > there issues as they need them. This is why we ripped types > out of the spec. Sure thing. > If you're trolling for stuff to debate, > let's do it in the realm of implementations. Spec stuff is > soooo 2002, man. I'm doing my best to keep it so :-) Sorry for my lack of progress in the last weeks - I'm between jobs so I've been investing a lot of CPU cycles into several business ventures I may choose to join/start; it didn't leave me much time. > Methinks Oren is trying to avoid writing code by digging up > spec ghosts. I for one will not take the bait. Sorry Oren. I > *am* one tasty fish. :) Curses, foiled again! :-) Anyway, note that all these 'ghosts' refer to the types, and have no effect on the spec itself, and similarly should have little effect on implementations (the parser is insulated from the types, right?). I was just, er, fishing for a reaction from users - and implementers. > The traditional spec is really only important for > implementors of the Testing Suite. How's that for a new spin? > I like it. Fair enough. And I promise I'll focus on the test suite, first thing after I have a spec to work from. Have fun, Oren Ben-Kiki |