YAML Ain't Markup Language

At 4:48 PM -0700 1/19/03, why the lucky stiff wrote:
>I've just completed support for the seq-in-seq in YAML.rb.  I tell ya!
>You can write some funky YAML with this thing!
>
>   - - - one
>     - - two
>     - three:
>       - four:
>       - - five
>   - six
>
>Loads in YAML.rb as:
>
>   [[["one"], ["two"], {"three"=>[{"four"=>nil}, ["five"]]}], "six"]

When I try to format this up as bracketed YAML, I get:

   [
     [
       [ "one" ],
       [ "two" ],
       { "three":
         [
           { "four": nil },
           [ "five" ]
         ]
       }
     ],
     "six"
   ]

The peculiar thing is that the indentation changes!  Perhaps the
YAML should be indented as:

    - - - one
      - - two
      -   three:
        -   four:
        - - five
    - six

Is this a real issue or is it just that it's a weird structure?

-r
-- 
email: rdm@...; 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

> -----Original Message-----
> From: yaml-core-admin@...
> [mailto:yaml-core-admin@... Behalf Of why the lucky
> stiff
> Sent: Sunday, January 19, 2003 3:49 PM
> To: yaml-core@...
> Subject: [Yaml-core] Seq-in-seq and boolean implicits

<snip>

> My suggestion:
>
>   true: .+
>   false: .-
>
> The dot is already used in several implicits?  YAGNI or what?

My personal opinion (as a non-implementer), your mileage may vary, void where
prohibited:

Yuck. reminds me of O'Caml and its lack of function overloading. I'd sooner go for
(+) and (-), but four (hold down shift and press =,9, and 0) and five (hold shift,
press 9, release both, press -, hold shift, press 0) keypresses also stinks in its
own way.
Maybe it's the complete lack of y-axis symmetry that's getting me.

Rich Morin (rdm@...) wrote:
> 
> The peculiar thing is that the indentation changes!  Perhaps the
> YAML should be indented as:
> 
>    - - - one
>      - - two
>      -   three:
>        -   four:
>        - - five
>    - six
> 

I believe the above would be loaded as:

  [
    [ 
      [ 'one' ],
      [ 'two' ]
    ],
    { 'three' => nil },
    [ 'four' => nil } ],
      [
        [ 'five' ]
      ]
    ],
    'six'
  ]

So different meaning altogether.  The primary reason being that a
mapping's indentation opens where the unquoted keys begin.  So the
'three' mapping starts at character 6.  The following sequence starts at
character 5 and closes the mapping.

In fact, now that I look at it, the above isn't valid YAML.  No wonder
YAML.rb wouldn't parse it. ;)

It's the same principle by which this is invalid:

    three:
  - four
  - five

> Is this a real issue or is it just that it's a weird structure?

Not an issue.  There should be no ambiguities with the shortcut.  It's
just interesting how YAML looks these days.

_why

Nathan Sharfi [mailto:nisharfi@...] wrote:
> > My suggestion:
> >
> >   true: .+
> >   false: .-
> >
> > The dot is already used in several implicits?  YAGNI or what?
> 
> My personal opinion (as a non-implementer), your mileage may
> vary, void where prohibited:
> 
> Yuck.

:-) I tend to agree, however.

> I'd sooner go for
> (+) and (-), but four (hold down shift and press =,9, and 0)
> and five (hold shift, press 9, release both, press -, hold 
> shift, press 0) keypresses also stinks in its own way.

Yes, not to mention both variants aren't very intuitive. I suggest that
as an interim step we'll allow y/Y/n/N as Boolean shorthands (that's a
common usage anyway):

    true: y
    false: N

In addition, I figured out a way that we can keep '-' and '+' as
implicit Booleans (sort of). However it is... Well... Judge for yourself
:-)

We could allow '-' as a plain value only when it is not ambiguous. The
full list of cases where it is not ambiguous is:

    As *in-line* value: -
    As next line *typed* value:
        ! -
    ! - : As a *typed* key
    In flow map: { - : false, false: - }
    In flow seq: [ -, + ]

It would only be ambiguous when used as non-typed key or non-typed
next-line plain scalar:

    - : Ambiguous # Null map-in-seq key)
      Ambiguous:
        - # Null seq entry?

Neither of these are common use cases. The only common use case we
really care about, for config files etc., is the use as in-line value
above.

So we could leave '-' and '+' in as implicit Booleans by qualifying the
'plain' productions with the appropriate restrictions. I'm not certain
that the undeniable benefits of allowing -/+ for Booleans outweigh the
costs of adding such a complication to the YAML specifications.
Thoughts?

Have fun,

	Oren Ben-Kiki

is the whole problem of using -/+ booleans steming from ambiguity with th=
e=20
sequence indicator - ? hmmm.... maybe * could have been used, but its too=
=20
late for such anyway.

don't have my spec handy so i can't check against conflicts to be sure so=
 i'll=20
just throw out alternate notions and see if any of them stick:

(true) (false)
--------------
 | .

 | ()

 + _
=20
 ||  |

well that's all i can think of off hand. probably not worth a hill of bea=
ns,=20
but i thought i'd give it a shot.

-transami

p.s. is tilde (~) still nil?

Oren Ben-Kiki (oren@...) wrote:
> 
> We could allow '-' as a plain value only when it is not ambiguous. The
> full list of cases where it is not ambiguous is:
> 
>     As *in-line* value: -
>     As next line *typed* value:
>         ! -
>     ! - : As a *typed* key
>     In flow map: { - : false, false: - }
>     In flow seq: [ -, + ]
> 
> It would only be ambiguous when used as non-typed key or non-typed
> next-line plain scalar:
> 
>     - : Ambiguous # Null map-in-seq key)
>       Ambiguous:
>         - # Null seq entry?
> 

*shiver*

I'm sorry, but this is just too much work to implement with too little
gain.  In addition, we'd have to instruct users about this sort of
exception to the rule.

Let's just stick to what we have and perhaps a better alternative will
surface.

_why

On 20/01/03 09:16 -0700, why the lucky stiff wrote:
> Oren Ben-Kiki (oren@...) wrote:
> > 
> > We could allow '-' as a plain value only when it is not ambiguous. The
> > full list of cases where it is not ambiguous is:
> > 
> >     As *in-line* value: -
> >     As next line *typed* value:
> >         ! -
> >     ! - : As a *typed* key
> >     In flow map: { - : false, false: - }
> >     In flow seq: [ -, + ]
> > 
> > It would only be ambiguous when used as non-typed key or non-typed
> > next-line plain scalar:
> > 
> >     - : Ambiguous # Null map-in-seq key)
> >       Ambiguous:
> >         - # Null seq entry?
> > 
> 
> *shiver*
> 
> I'm sorry, but this is just too much work to implement with too little
> gain.  In addition, we'd have to instruct users about this sort of
> exception to the rule.
> 
> Let's just stick to what we have and perhaps a better alternative will
> surface.

Hate to say it, but "YAGNI". 

Actually I love to say it. :)

Boolean implicits are so yagni. You can use any string you want. 

    verbose_log: no
    #email_on_error: 0
    email_on_error: ingy@...

Just let the application make sense of it. It's a *config file* for
goodness sake. I've never used boolean objects for configuration
switches. yagni.

Booleans for serialization may be needed, but in that use case

    ---
    - !bool 1
    - !bool false

is fine.


Cheers, Brian