From: Braòo T. <ti...@ds...> - 2004-10-05 09:14:23
|
PGRlbHVyaz4NCnRyYW5zLiAoVC4gT25vbWEpIHdyb3RlOg0KPiBJc24ndCB0aGUgcm9vdCBvZiB0 aGUgZXZpbCB0aGF0IHRhYnMgaGF2ZSBhbiBhbWJpZ3VvdXMgcmVwcmVzZW50YXRpb25zIG9mIA0K PiBsZW5ndGggcmVsYXRpdmUgdG8gdGhlIHNwYWNlPyBQZXJoYXBzIGp1c3QgZW5mb3JjaW5nIGEg Zml4ZWQgbGVuZ3RoIHBvbGljeSANCj4gd291bGQgaGVscCwgc2F5LCAyIHNwYWNlcyBmb3IgZXZl cnkgdGFiIC0tSSB0aGluayB0aGF0J3MgdGhlIG1vc3QgY29tbW9uIHVzZS4gDQoNCkknZCBzYXkg NCBzcGFjZXMgcGVyIHRhYiBpcyBqdXN0IGFzIGNvbW1vbiBhcyAyIChpbiBwZXJsL3B5dGhvbi9y dWJ5IHdvcmxkIHByb2JhYmx5IGV2ZW4gbW9yZSkuDQpBbmQgZGVmYXVsdCBpbiBlZGl0b3JzIGlz IGFsbW9zdCBhbHdheXMgOC4gVGhlcmUgaXMgbm8gbWFnaWMgc3BhY2VzLXBlci10YWIgY29uc3Rh bnQuDQoNCj4gQWx0aG91Z2ggSSBoZXNpdGF0ZSB0byBzdWdnZXN0IGl0LCBwZXJoYXBzIGEgZGly ZWN0aXZlIHRvIHNldCB0YWIgc3BhY2luZyBpZiANCj4gb3RoZXJ3aXNlLg0KDQpEaXJlY3RpdmUg aXMgYWxzbyBubyBnb29kIC0gaXQgd291bGQgZm9yY2UgaHVtYW4gcmVhZGVycyAoSFIpIHRvIHVz ZSBvbmx5IHByb2dyYW1zIHRoYXQgdW5kZXJzdGFuZCBZQU1MLg0KSWYgZWFzZSBvZiByZWFkaW5n IGZvciBIUiBpcyByZWFsbHkgdG9wIGNvbmNlcm4sIGFsbCBjb25mdXNpbmcgdXNlcyBzaG91bGQg YmUgZGlzYWxsb3dlZC4gVGh1czoNCg0KPiBPciBiZXR0ZXIgeWV0LCBqdXN0IGRvbid0IGFsbG93 IHRhYnMgOykNCg0KcHJvcG9zYWw6DQogIC0gZG9uJ3QgYWxsb3cgdGFicyBhcyBpbmRlbnRhdGlv bg0KICAtIGRvbid0IGFsbG93IHRhYnMgaW4gcGxhaW4gc2NhbGFycw0KICAtIGRvbid0IGFsbG93 IHRhYnMgaW4gdW5xdW90ZWQgc2NhbGFycw0KIyBhcmUgbGFzdCB0d28gcnVsZXMgYWN0dWFsbHkg dGhlIHNhbWUgb3IgaXMgdGhlcmUgZGlmZmVyZW5jZSBpbiAncGxhaW4nIGFuZCAndW5xdW90ZWQn Pw0KDQpUaGVuIHRhYnMgd291bGQgYmUgYWxsb3dlZCBvbmx5IGluIGNvbnRleHRzIHRoYXQgYXJl IGFscmVhZHkgbWFya2VkIGFzICJiZXdhcmUsIHNvbWV0aGluZyBzcGVjaWFsIg0KKElJUkMgaS5l LiBmb2xkZWQgdGV4dCBpcyBpbnNwaXJlZCBieSBmb2xkaW5nIGluIEhUTUwsIHdoZXJlIHRhYiBh bmQgbmwgYWxyZWFkeSBzZXJ2ZSBhcyBzaW5nbGUgd2hpdGUgc3BhY2UpLg0KDQpianQNCjwvZGVs dXJrPg0K |
From: Oren Ben-K. <or...@be...> - 2004-10-05 20:58:35
|
On Tuesday 05 October 2004 11:14, Braoo Tich=C3=BD wrote: > I'd say 4 spaces per tab is just as common as 2 (in perl/python/ruby > world probably even more). And default in editors is almost always 8. > There is no magic spaces-per-tab constant. +1. > Directive is also no good +1. We've been down that road a while back. Doesn't work. > If ease of reading for HR is really top concern, all confusing uses > should be disallowed. +1. We thought we got them all. The comment-after-block-scalar case is a sneaky one. > proposal: > - don't allow tabs as indentation That's the current state of affairs. > - don't allow tabs in plain scalars Hmmm. > - don't allow tabs in unquoted scalars > # are last two rules actually the same or is there difference in > 'plain' and 'unquoted'? There are also block scalars (literal and folded) which aren't "quoted" but that's a different thing - there's no problem with tabs there. > Then tabs would be allowed only in contexts that are already marked > as "beware, something special" (IIRC i.e. folded text is inspired by > folding in HTML, where tab and nl already serve as single white > space). Actually tabs are preserved in a folded scalar, and they most definitely are preserved in a literal scalar. I expect that under this proposal tabs would not be allowed in separation white space anywhere - they would only allowed inside non-plain scalars. Interesting. Forbidding tabs inside plain scalars is rather extreme, however. I admit to being tempted... but I think it would be impossible to defend such a broad restriction. Its one thing to forbid tabs when block indentation is an issue - people see why that makes sense. Its another thing to forbid tabs when {}/[] are used to denote structure - people would be justified in expecting such structures to follow the same rules they do in every programming language, which means that white space is immaterial and hence tabs are allowed. So I fear we'll have to file that in the "great notion, but people being people it won't work" drawer. I guess by now its a whole cabinet rather than a single drawer :-) Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2004-10-06 15:12:41
|
On 05/10/04 22:58 +0200, Oren Ben-Kiki wrote: > On Tuesday 05 October 2004 11:14, Braoo Tich?=BD wrote: > > Then tabs would be allowed only in contexts that are already mark= ed > > as "beware, something special" (IIRC i.e. folded text is inspired= by > > folding in HTML, where tab and nl already serve as single white > > space). >=20 > Actually tabs are preserved in a folded scalar, and they most > definitely are preserved in a literal scalar. >=20 > I expect that under this proposal tabs would not be allowed in > separation white space anywhere - they would only allowed inside > non-plain scalars. >=20 > Interesting. Forbidding tabs inside plain scalars is rather extreme= , > however. I admit to being tempted... but I think it would be imposs= ible > to defend such a broad restriction. My gut feeling is to eschew tabs as much as possible. They really nee= d to be allowed in literal blocks. That's a primary intent of the literal form. I'm not sure we need to allow them anywhere else. So I'll raise the bet. As a strawman, let's not allow tabs in a YAML = stream except in literal scalars. Cheers, Brian |
From: trans. (T. Onoma) <tra...@ru...> - 2004-10-06 19:54:20
|
On Wednesday 06 October 2004 11:16 am, Brian Ingerson wrote: | So I'll raise the bet. As a strawman, let's not allow tabs in a YAML stream | except in literal scalars. By literal you mean quoted? If so that's basically the bush I'm beating. T. |
From: Clark C. E. <cc...@cl...> - 2004-10-07 00:18:51
|
On Wed, Oct 06, 2004 at 03:54:13PM -0400, trans. (T. Onoma) wrote: | On Wednesday 06 October 2004 11:16 am, Brian Ingerson wrote: | | So I'll raise the bet. As a strawman, let's not allow tabs in a | | YAML stream except in literal scalars. | | By literal you mean quoted? http://yaml.org/spec/#syntax-scalar-literal *bings* Clark |
From: trans. (T. Onoma) <tra...@ru...> - 2004-10-07 02:23:54
|
On Wednesday 06 October 2004 08:18 pm, Clark C. Evans wrote: | On Wed, Oct 06, 2004 at 03:54:13PM -0400, trans. (T. Onoma) wrote: | | On Wednesday 06 October 2004 11:16 am, Brian Ingerson wrote: | | | So I'll raise the bet. As a strawman, let's not allow tabs in a | | | YAML stream except in literal scalars. | | | | By literal you mean quoted? | | http://yaml.org/spec/#syntax-scalar-literal | | *bings* Oh! Right. Even better. T. |
From: Clark C. E. <cc...@cl...> - 2004-10-07 14:22:52
|
On Wed, Oct 06, 2004 at 10:23:25PM -0400, trans. (T. Onoma) wrote: | On Wednesday 06 October 2004 08:18 pm, Clark C. Evans wrote: | | On Wed, Oct 06, 2004 at 03:54:13PM -0400, trans. (T. Onoma) wrote: | | | On Wednesday 06 October 2004 11:16 am, Brian Ingerson wrote: | | | | So I'll raise the bet. As a strawman, let's not allow tabs in a | | | | YAML stream except in literal scalars. | | | | | | By literal you mean quoted? | | | | http://yaml.org/spec/#syntax-scalar-literal | | | | *bings* | | Oh! Right. Even better. Well, it might clean up some productions and would make parsing perhaps a bit quicker (my IS_SPACE macro would just check for ' ' character). It might even make parsing easier, I'm not sure if the impact would be significant though. However, this arbitrary limitation would prevent, key: value--->#comment where ---> is a single tab. I can go either way here. Best, Clark P.S. Oren is now mostly completed with updating the 1.1 productions, I'm sure he'll be happy to change them again... but only if they get shorter. ;) |
From: trans. (T. Onoma) <tra...@ru...> - 2004-10-07 14:29:43
|
On Thursday 07 October 2004 10:21 am, you wrote: | Well, it might clean up some productions and would make parsing | perhaps a bit quicker (my IS_SPACE macro would just check for ' ' | character). It might even make parsing easier, I'm not sure if the | impact would be significant though. However, this arbitrary | limitation would prevent, | | key: value--->#comment | | where ---> is a single tab. I can go either way here. No error. Just treat as if a space --except in literals. T. |
From: Oren Ben-K. <or...@be...> - 2004-10-07 15:59:55
|
Brian wrote: > So I'll raise the bet. As a strawman, let's not allow tabs in a YAML > stream except in literal scalars. Talk about an extreme solution... Note The problem isn't tabs inside scalars. The problem is tabs as separation spaces getting mixed up with indentation. This can't happen inside block or quoted scalars, so we can allow tabs there. There's no reason why the following should be invalid: --- quoted: "--->" # value is a tab. folded: > folded text --->* bulleted --->* list ... The problem only arises because we allow tabs to be used as separation white space when indentation "isn't an issue". The problem is this distinction is subtle. Watch the slippery slope: ---># comment --- key: value---># comment --- key:---># comment value---># comment --- key:---># comment ---># comment value---># comment ---># comment --- flow:---># comment {--->key:---># comment ---># comment value--->}--># comment --- literal:--->|---># comment value ---># ??? --- The first comment is "clearly" not related to indentation. When you get to '???' the tab "clearly" is related to indentation. So, the question is, where do you draw the line? - Restrictive (Brian's strawman, relaxed just a bit): Never allow tabs as separation white space. Only allow them inside quoted and block scalars. You'd have to forbid them in plain scalars, otherwise things would get strange fast with tabs trailing a plain value. - Relaxed: forbid tabs in indentation and in a comment line immediatly following a block scalar. There's no problem allowing tabs as separation white space and in all the scalar styles, including the plain style. Onoma suggested: > No error. Just treat as if a space --except in literals. And quoted, and indentation - so it boils down to the "relaxed" option above. The current spec tended towards the "relaxed" option, so the set of productions I'm honing uses it. Going towards the "restrictive" would mean a change in the intent (in theory, it would break existing files). I'm rather torn bewteen these options... Have fun, Oren Ben-Kiki |
From: Clark C. E. <cc...@cl...> - 2004-10-07 16:47:26
|
On Thu, Oct 07, 2004 at 05:59:10PM +0200, Oren Ben-Kiki wrote: | The first comment is "clearly" not related to indentation. When you get | to '???' the tab "clearly" is related to indentation. So, the question | is, where do you draw the line? | | - Restrictive (Brian's strawman, relaxed just a bit): Never allow tabs | as separation white space. Only allow them inside quoted and block | scalars. You'd have to forbid them in plain scalars, otherwise things | would get strange fast with tabs trailing a plain value. | | - Relaxed: forbid tabs in indentation and in a comment line immediatly | following a block scalar. There's no problem allowing tabs as | separation white space and in all the scalar styles, including the | plain style. The 'Relaxed' case causes complexity in the productions, parsing code, and probably interoperability. How about Restrictive plus allowing tabs _following_ a # but before a new line; no point in forbidding tabs in a line-comment. | The current spec tended towards the "relaxed" option, so the set of | productions I'm honing uses it. Going towards the "restrictive" would | mean a change in the intent (in theory, it would break existing files). I'm all for the restricted variety (ie, allowing it in content, but not in separation spaces). While we are at it, can we forbid unicode carriage returns in separation spaces? Clark |
From: Brian I. <in...@tt...> - 2004-10-07 20:37:25
|
On 07/10/04 12:47 -0400, Clark C. Evans wrote: > On Thu, Oct 07, 2004 at 05:59:10PM +0200, Oren Ben-Kiki wrote: > | The first comment is "clearly" not related to indentation. When you get > | to '???' the tab "clearly" is related to indentation. So, the question > | is, where do you draw the line? > | > | - Restrictive (Brian's strawman, relaxed just a bit): Never allow tabs > | as separation white space. Only allow them inside quoted and block > | scalars. You'd have to forbid them in plain scalars, otherwise things > | would get strange fast with tabs trailing a plain value. > | > | - Relaxed: forbid tabs in indentation and in a comment line immediatly > | following a block scalar. There's no problem allowing tabs as > | separation white space and in all the scalar styles, including the > | plain style. > > The 'Relaxed' case causes complexity in the productions, parsing > code, and probably interoperability. How about Restrictive plus > allowing tabs _following_ a # but before a new line; no point in > forbidding tabs in a line-comment. > > | The current spec tended towards the "relaxed" option, so the set of > | productions I'm honing uses it. Going towards the "restrictive" would > | mean a change in the intent (in theory, it would break existing files). > > I'm all for the restricted variety (ie, allowing it in content, but > not in separation spaces). While we are at it, can we forbid unicode > carriage returns in separation spaces? I am of the opinion that that *only* place to allow tabs is in the use case of cutting and pasting a piece of structured data. Definitely needed in the literal. Perhaps in the folded. Double quotes have a tab escape \t so I would say don't relax my proposal for quoted stuff. Nobody should ever type a hard tab into a yaml stream. Period. I really want YAML to be tab free and throw errors otherwise. Read my lips ;) Cheers, Brian |
From: Oren Ben-K. <or...@be...> - 2004-10-07 22:01:23
|
> On 07/10/04 12:47 -0400, Clark C. Evans wrote: > > How about Restrictive plus > > allowing tabs _following_ a # but before a new line; no point in > > forbidding tabs in a line-comment. Any non-break character is valid in a comment, tabs included. > > I'm all for the restricted variety (ie, allowing it in content, but > > not in separation spaces). While we are at it, can we forbid > > unicode carriage returns in separation spaces? Why? On Thursday 07 October 2004 22:34, Brian Ingerson wrote: > I am of the opinion that that *only* place to allow tabs is in the > use case of cutting and pasting a piece of structured data. > Definitely needed in the literal. Perhaps in the folded. > Double quotes have a tab escape \t so I would say don't > relax my proposal for quoted stuff. There's no \t in single quotes... I think forbidding tabs in quoted scalars goes just a bit too far. There's no technical reason for it, and I'm reluctant to add rules on purely aesthetical grounds (even if I agree with them). > Nobody should ever type a hard tab into a yaml stream. Period. Cut & paste of line noise into single/double quoted YAML text is also a reasonable use case. The wind seems to be blowing towards being restrioctive - nobody has spoken in favor of being relaxed. OK, I'll fix the productions accordingly... Have fun, Oren Ben-Kiki |
From: Peter W. <pwo...@qu...> - 2004-10-05 16:46:32
|
Please excuse this uninvited comment re spaces vs. tabs: Python attempts to address the space/tab issue by treating two "leading space strings" as equivalent if and only if they contain the same total number of spaces *and* the same total number of tabs (there's no tab =3D X spaces formula, but *order* is ignored). But rejecting tabs outright (at least inside "leading space strings") seems like the best way for language syntax to discourage the same sorts of space/tab transmogrification that cause source control systems to barf. And that's really all that language syntax can do, since the space/tabs problem really belongs to the world of text editors (eg MVS tabs set to 4 by default, vi tabs set to 8 by default) and source control systems (eg CVS). Peter -----Original Message----- From: Brano Tich=FD [mailto:ti...@ds...] Sent: Tuesday, October 05, 2004 2:14 AM To: yam...@li... Subject: Re: [Yaml-core] Comments, spaces and tabs <delurk> trans. (T. Onoma) wrote: > Isn't the root of the evil that tabs have an ambiguous representations = of=20 > length relative to the space? Perhaps just enforcing a fixed length = policy=20 > would help, say, 2 spaces for every tab --I think that's the most = common use.=20 I'd say 4 spaces per tab is just as common as 2 (in perl/python/ruby = world probably even more). And default in editors is almost always 8. There is no magic = spaces-per-tab constant. > Although I hesitate to suggest it, perhaps a directive to set tab = spacing if=20 > otherwise. Directive is also no good - it would force human readers (HR) to use = only programs that understand YAML. If ease of reading for HR is really top concern, all confusing uses = should be disallowed. Thus: > Or better yet, just don't allow tabs ;) proposal: - don't allow tabs as indentation - don't allow tabs in plain scalars - don't allow tabs in unquoted scalars # are last two rules actually the same or is there difference in 'plain' = and 'unquoted'? Then tabs would be allowed only in contexts that are already marked as = "beware, something special" (IIRC i.e. folded text is inspired by folding in HTML, where tab and nl = already serve as single white space). bjt </delurk> N=18=ACHY=DE=B5=E9=9A=8AX=AC=B2=9A'=B2=8A=DEu=BC=88L=FA=E8v=E7-=1A=E8=9Dz= =89=C8L=C6=A7j=07=AB=B0=9A.=AEv=A5R=C7=88N=9A=E8v=E7-=B2)=F2=A2=EA=DB=BA=C8= =A7z=CB=13zYn=B3=08Z=B7*.=B6=18=A7=92=87=ED=85=E9=86=8A=F7=AE=B1=8A.=AC=EA= b=9E*'=B0g=AD=16=B7=9EN=18=A7=90g=9E=90h=9F=B4'=AB=B6'=E2q=AB^=B0)brKh~)=DD= =A2=EBf=A2=B7=A1=B6=DA=7F=FE=9A=E8v=E7-=82=E8=9Dz+fjv=A0z=BB#=A2=EA=E7jW(= =9B=F8.=89=D7=A9=AE=89=A8=B6jea=A9=A5r=8A=DE=99=A8=A5=8Ax%=8A=CBXji\=A2=B7= =A5=8A=CBl=B2=8B=ABq=E7=E8=AE=07=A7z=D8m=B6=9B?=FEX=AC=B6=CB(=BA=B7=1E~=8A= =E0zw=AD=FEX=AC=B6=CF=E5=8A=CBb=9D=FA?=C9=A9=A5r=8A=DE |
From: Clark C. E. <cc...@cl...> - 2004-10-06 18:50:53
|
On Tue, Oct 05, 2004 at 09:45:47AM -0700, Peter Wolfenden wrote: | Python attempts to address the space/tab issue by treating two | "leading space strings" as equivalent if and only if they contain the | same total number of spaces *and* the same total number of tabs | (there's no tab = X spaces formula, but *order* is ignored). First, Guido has also lamented this decision. So while it may be a precedent, it is one that has well documented downsides. Using tabs is also a problem with Makefile usage -- it is a common problem with first year unix programmers. While Python's tab policy can work acceptably well in groups that can agree on a tab style, it is easy to shoot your foot when moving code between groups with different indentation policies. Second, YAML is not a programming language. YAML data files cannot be tightly controlled by a few developers, instead, they are shared between development groups and even among users. Trying to get a consistent tab policy across all of these groups... or even attempting to explain what a TAB is to an end-user is a non-starter. Kind Regards, Clark |