YAML Ain't Markup Language

> | > 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

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

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

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

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

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

| > 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

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

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

| 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

Clark C . Evans [mailto:cce@...] 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

Clark C . Evans [mailto:cce@...] 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

Oren Ben-Kiki [mailto:orenbk@...] 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

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

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

On 30/11/01 10:50 +0200, Oren Ben-Kiki wrote:
> Clark C . Evans [mailto:cce@...] 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

On 30/11/01 11:28 +0200, Oren Ben-Kiki wrote:
> Oren Ben-Kiki [mailto:orenbk@...] 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

| > 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

| > 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

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