YAML Ain't Markup Language

On Saturday 07 August 2004 00:58, Jeremy Rice wrote:
> ...Thinking a bit outside the box: no need to restrict yourself to
> one-character, neh?

Right. We could use something like:

    true: .+
    false: .-

or:

    true: ++
    false: --

or

>   true:  =
>   false: !=

Bit none of the above seems elegant/intuitive, somehow.

> or
>
>   true:  +
>   false: {}
>
> (Which might make you grumpy for other reasons, I realize.)

Like {} meaning an empty mapping :-)

> ...Just trying to stimulate thought; don't have any arguments to support
> the notion.  :)

No, its a good notion. Its just that none of the two-character combinations I 
came up with seems to "work".

Let's keep this on the back burner until Clark returns and make a decision 
then. Maybe someone will hit on a brilliant idea in the meanwhile.

Have fun,

	Oren Ben-Kiki

On 07/08/04 10:49 +0300, Oren Ben-Kiki wrote:
> On Saturday 07 August 2004 00:58, Jeremy Rice wrote:
> > ...Thinking a bit outside the box: no need to restrict yourself t=
o
> > one-character, neh?
>=20
> Let's keep this on the back burner until Clark returns and make a d=
ecision=20
> then. Maybe someone will hit on a brilliant idea in the meanwhile.

    true:  |
    false: O
    true:  /
    false: \
    true:  S
    false: $
    true:  8
    false: %
    true:  /
    false: X
    true:  =3D
    false: #
    true:  ^
    false: A
    true:  =E2=98=BA
    false: =E2=98=BB

Cheers, Brian

On Saturday 07 August 2004 18:31, Brian Ingerson wrote:
>     true:  |
>     false: O
Too cute. The 'O' is too much of a string, and with the inevitable confusio=
n=20
with 0 - I don't think so.

>     true:  /
>     false: X
Make it:
    true: +
    false: x
Not that bad, actually.  However, 'x' is a letter, and is used by itself as=
 an=20
identifier:
    coordinate: x
That said, if there's overwhelming support for 'x' over '!', I'll go with i=
t.

>     various line noise
Obscure, some are inherently invalid (using '#').

>     true:  =E2=98=BA
>     false: =E2=98=BB
This displays as line noise in my e-mail client. And VIM. I wouldn't be abl=
e=20
to type it even if I did see it. Unicode just isn't there yet.

The +/! combination is still the less bad option.

Have fun,

    Oren Ben-Kiki

On 07/08/04 19:04 +0300, Oren Ben-Kiki wrote:
> On Saturday 07 August 2004 18:31, Brian Ingerson wrote:
> >     true:  ??=F7
> >     false: ??=BB
> This displays as line noise in my e-mail client. And VIM. I wouldn'=
t be able=20
> to type it even if I did see it. Unicode just isn't there yet.

This is the only point worth responding as I was just kidding.
Completely. :P

Anyway I wrote the email in vim (inside mutt). I cut and pasted a whi=
te
smiley and a black smiley, and they displayed fine as wide characters=
.

Now they also appear as garbage to me now. Something happened
along they way.

Unicode seems harder to round trip than YAML ;)

But my point to you is that vim is all up to date unicode-wise. It ma=
y
be a bear getting your terminal and your input methods all set up
right, but vim is a champ here. You should really check it out my heb=
rew
speaking friend. :)

hmmmm

    true: :)
    false: :(

Thoughts? ~_~

Cheers, Brian

On Sat, 2004-08-07 at 16:31, Brian Ingerson wrote:
> > Let's keep this on the back burner until Clark returns and make a dec=
ision=20
> > then. Maybe someone will hit on a brilliant idea in the meanwhile.
>=20
>     true:  |
>     false: O
>     true:  /
>     false: \
>     true:  S
>     false: $
>     true:  8
>     false: %
>     true:  /
>     false: X
>     true:  =3D
>     false: #
>     true:  ^
>     false: A
>     true:  =E2=BA
>     false: =E2=BB
Absolute bloody genius!!!

Common COBOL practice of old

  true: 1
  false: .

You would see strings of these for bit flags,

  11...1.1..1

Can't use the 1, but a few other things could work just as well like / maybe.

Just thought I throw that out there.

T.

On Saturday 07 August 2004 00:49, Oren Ben-Kiki wrote:
> On Saturday 07 August 2004 00:58, Jeremy Rice wrote:
> > ...Thinking a bit outside the box: no need to restrict yourself to
> > one-character, neh?
>
> Right. We could use something like:
>
>     true: .+
>     false: .-

I think true/false works well enough.  If a language to describe implicit 
schemas comes along, then perhaps worry about mapping true/false to other 
languages or neutralizing it with '==' and '<>' values.

Anyway, I think of implicits as a function of the loader.  It's great to have 
it in the spec, and quite handy when they load automatically in Ruby, but 
perhaps the base spec should just be map/seq/string, and implicit types 
should be up to the loading mechanism and the programmers who invoke it.

	Sean O'Dell

On Wednesday 11 August 2004 01:45, Sean O'Dell wrote:
> I think true/false works well enough.  If a language to describe implicit
> schemas comes along, then perhaps worry about mapping true/false to other
> languages or neutralizing it with '==' and '<>' values.

Well, yes, but its nice to have a language-agnostic format. I think + and ! 
are OK for that. At any rate...

> Anyway, I think of implicits as a function of the loader.  It's great to
> have it in the spec, and quite handy when they load automatically in Ruby,
> but perhaps the base spec should just be map/seq/string, and implicit types
> should be up to the loading mechanism and the programmers who invoke it.

That's the case already, We are NOT discussing how to define bool in the spec 
- the spec doesn't define the !bool tag in any way. We are discussing how to 
define the !bool tag in the type respository, which serves as a recommended 
set of tags for the loader you mention.

Have fun,

	Oren Ben-Kiki