Re: Implicit typing & the principal of least surprise

On Thu, 2007-05-10 at 13:41 -0700, Burt Harris wrote:
> I very much like the idea of restricting the set of implicit type conversions
> to those needed for JSON compatibility.

You mean *by default*. We definitely want to allow application (schema)
specific extensions.

> I'll suggest that the complete set
> of implicit type regex's actually belongs in section 3.3.2 of the core spec,
> rather than distributed through the type repository.

Yes, but again only if we are talking about the core/default/basic set
of implicit types.

> This section should
> say triggering condition for implicit typing is a non-specific tag of '?', rather
> than plain scalar, helping to make clear that it's a composing, rather than
> parsing function.

I'm not certain what you mean. The spec says:

    During parsing, nodes that omit the tag are given a non-specific
    tag: “?” for plain scalars and “!” for all other nodes.

The parsing phases and the behavior of implicit typing is pretty well
covered - with the glaring omission of a default/core/basic set of
implicit types, which we will rectify.

> I'm not so sure that << belongs in the set.

The set is still TBD. I'm not sure that '<<' does/not belong there
myself, either :-)

> One thought
> that crossed my mind would be to replace use of << with the !!merge tag,

Actually the '<<' key has the tag 'merge'...

> The other implicit typing ambiguity introduced by reading the type repository
> is the option that an untagged sequence of single-key mappings might be
> interpreted as an !!omap implicitly.

Depending on the schema, definitely not by default!

> Given my level of YAML understanding,
> the no duplicate keys implication would be surprising. I recognize this is
> optional, but suggest it may be worth removing all implications of implicit
> typing from the type repository given Oren's explanation of the intent.

I'm not certain I follow. A schema may do one of several things:

- Define the exact type of everything. No need for either tags or
implicit typing then; everything is "hard wired". This is actually the
most common case.

- Leave some things as polymorphic, but allow implicit typing so no
explicit tags are required. Polymorphic fields are rare, but when you do
need them, you _really_ need them, and being able to skip explicit tags
for each and every one is a great boon for humans. For example, a PHP
schema may state that "if it looks like an omap, it is an omap" because
omap is such a basic data type for PHP. This would allow PHP-friendly
YAML files to be written with a single generic php tag at the root node,
instead of having to tag each and every omap.

- Leave some things as polymorphic, and require explicit tags for each
one. If I understand correctly, this is what you are proposing. IMO this
is too restrictive.

So, both in the spec itself, and in the distributed/dynamic type
repository, there is a role for implicit typing. There's no way we can
really eliminate this, as long as humans "automagically" read 5 as a
number and true as a boolean...

Have fun,

	Oren Ben-Kiki


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core