Loading ...
Sorry, an error occurred while loading the content.

1053Re: JSON syntax grammar is missing 'undefined' literal value

Expand Messages
  • Shelby Moore
    May 26 12:08 PM
    • 0 Attachment
      Douglas Crockford wrote:
      > I anticipate that there will be other languages that are based on or
      > inspired by JSON. These will push the model in interesting directions.
      > But there will be always be a simple JSON because there is a benefit
      > in having something that is reliable and minimally adequate.

      Agreed this is an exciting frontier, based on a conceptually
      RISC-like, yet data complete model that is JSON. A point I grasped
      probably due to your writings (your blog included) over the past year.
      However, even after reading your much appreciated insight and
      experience, I still think JSON is missing one crucial literal type.

      > In my view, JavaScript's undefined was a mistake. There are too many
      > similar falsy values in the the language.

      In my view, false, null, and undefined are not all similar, and each
      is a critical fundamental primitive for the semantic web. Boolean and
      null Object both are referent data types. The Boolean false is
      fundamental binary gate of digital logic. The null Object means
      semantically we require an Object, but we don't know which object.
      Requiring an Object is not the same as requiring a true/false outcome.
      Requiring an Object and getting a null outcome, is not the same as
      requiring a Boolean and getting false. Those are very different semantics.

      The undefined Object means we know the identifier that refers, but the
      referent (to which it refers) is unspecified. Thus, undefined is
      necessary for distinguishing between unspecified data and data that
      the application does not contemplate. If we use null to represent
      unspecified data, then we no longer have a way to distinguish between
      unspecified data (no referent) and specified data (referent) that has
      no value.

      If I have an application that expects a data structure with two
      members, "one" and "two", then if it receives:

      { "one" : null }

      then it is clear that "one" is specified as no value, but it is
      ambiguous whether the received data is saying that "two" is
      unspecified, or if it is saying that "two" is not even contemplated.
      In the latter case, the sending application might be in error, because
      it doesn't even contemplate "two" in it's output.

      If { "one" : null, "two" : null } is received, then it is ambiguous
      whether "one" and "two" are specified as no value, or whether they
      were contemplated but are not specified.

      Whereas, if { "one" : null, "two" : undefined } is received, then
      there is no ambiguity.

      The distinction between null and undefined becomes more noticeable,
      when one gets into specifying semantics in data structures, as became
      evident when I decided to use the pair names as the semantic data
      types implicitly, to avoid the overhead (and reduction in human
      readability) of an orthogonal schema language. In my formulation, the
      data is the schema, via inheritance. Thus the critical need to
      distinguish between optional, unspecified and required, no value in
      inheritance.


      > Most programmers are
      > confused about the differences.

      That may be true. Douglas, afaik your web site (crockford.com) has
      helped clarify many things about JavaScript, perhaps my explanations
      above may be helpful in this regard at some point. I claim no
      copyright nor recognition. Be it as it may.

      > The undefined property is
      > inconsistent. It indicates a missing member, but it can be the value
      > of present members.

      As I detailed above, I think it is critical to view undefined as the
      type of the identifier, not of the referent. Then there is no
      inconsistency, because undefined is not concerned with assignment, as
      it is not a property of the referent of the identifier. You are not
      asking "is the identifier not attached to a referent?", but instead
      "was this identifier assigned to undefined?". Per my first post of
      this thread, one can distinguish from a property identifier which was
      never assigned to undefined, using the 'in' operator, but that is
      orthogonal to the question that "=== undefined" asks about the identifier.

      > As a name, it is implemented as a writable global
      > variable, a feature with alarming security and reliability
      > consequences.

      Thanks for making me aware that this.undefined is a writable property
      of the global this object. I did some testing in Firebug's console,
      and even after undefined has been modified (e.g. this.undefined =
      null;), new instances of uninitialized var or missing properties,
      still get assigned to the original undefined object. So it means to be
      safe against malicious code, we need to re-initialize upon any call backs:

      var undefined;
      this.undefined = undefined;


      > This is not a feature to fight for. It is a mistake that
      > cannot be rectified.

      Why can't the writeable security hole be rectified?


      > At the time I formulated JSON, JavaScript was not a popular language,
      > and it was generally held in very low esteem. One of my design goals
      > was to hide JavaScript's defects. That is why keys must be quoted in
      > JSON, because I did not want to explain JavaScript's absurd reserved
      > word policy in the JSON spec. The undefined value was excluded for the
      > similar reasons.

      I am not following you? If undefined was a literal in JSON, afaics it
      would work fine in eval(), as long as this.undefined is patched up
      before calling eval, just in case it was overwritten.


      > JavaScript could use a generalized serialization format, something
      > that understands functions and prototypes and undefined. That language
      > could be derived from JSON, but JSON should never be that language
      > because it would violate the goal of being minimal, stable, and
      > independent.

      That may be true, but that is not at all what I am here for. I am
      also working on a language agnostic, minimalistic primitive syntax. I
      am merely trying to enable the minimum necessary to launch the
      Semantic Web, in much simpler manner than all that RDF+XML complexity.
      I simply believe that automated code reuse is not only for science
      fiction. And I believe OpenSocial, MySpace, FaceBook, etc are all
      wrong and very vulnerable.
    • Show all 19 messages in this topic