Re: [Yaml-core] %IMPLCIT declaration?

[T. O. <tra...@ru...>]

On Sunday 08 August 2004 03:50 pm, Clark C. Evans wrote:
> Regarding implicit types, there are a few things that must be done:
>
>   (a) Update the main specification to make it absolutely clear
>       that implicit typing is optional
>
>   (b) Update the type repository to be consistent with examples
>       and with itself.
>
> Personally, I don't like implicit types; at least not the "ambiguous"
> ones we currently have.  It makes for a big wart in the specfication
> where we carry a plain-type flag all the way into the representation
> (aka graph) model for items which could-possibly-be-impliclty-typed.
> Frankly, it's ugly.

What is implicit typing really? Isn't it nothing more than a pattern match on 
scalar values to instruct the backend how to interpret them? But it is up to 
the backend to decide what to do with those instructions --so they are just 
suggestive really. The %IMPLICIT directive your proposing doesn't change 
that. It just decides which and whether to provide those suggestions or not. 
Now, in 99% of the cases those suggestions will be on the money. In the other 
1% they can be easily handled as long as the implementations allows it. That 
is to say, one can tell the YAML parser to ignore implicit typing and just 
provide !str --and hell, even implement an alternate typing schema. And 
there's the matter in a nutshell, really. Implicit typing is ultimately to be 
controlled by a Yaml Schema. But right now there is no definite schema, so 
the backend languages handle those needs. That is to say, the backend 
languages are the currnt Schema system. So Implicit typing is a good thing 
b/c it allows us to easily handle the majority of the cases, yet the 
implementations can still give us control to deal with the odd cases. So we 
don't need an %IMPLICIT directive in the Yaml.

So I don't think its ugly at all from this perspective. The Yaml specification 
lays down a standard for implicit typing --for which there is standard 
support in all implementations (as far as the language itself allows). As 
long as they also provide for user-defined alternatives.

My 2 cents. thanks.

							trans.