records generated from UBF

[Shawn Pearce]

Erik Pearson <erik@REDACTED> wrote:
> Thanks, I didn't notice the comma sneaking in there as whitespace. 
> However, I am still somewhat concerned:
> 
> - how do you disambiguate {"Hi" 'greeting', "world" 'planet'}? It seems 
> that this could be either {Obj1 Obj2 Obj3 Obj4} or {Obj1 Obj3 Obj4} or 
> {Obj1 Obj2}.

Its clearly {Obj1 Obj2 Obj3 Obj4}.  ' ' (space) and ',' (comma) are both
whitespace characters to UBF.  Thus its {"Hi"'greeting'"world"'planet'},
which is a 4 object tuple.  Now UBF(B) may define that the atom
'greeting' represents a type which is called greeting, however a
type can only be made of up simple types.  Thus in order to create
a UBF(B) type of 'greeting' it would be necessary to encode as

{"Hi" {'greeting', "world"}, 'planet'}

which if you look at Erlang records is exactly how a greeting record
would be encoded.  (Tuple holding the tuple name as the first term
and the values as the rest. So clearly the example you give cannot
even be a UBF(B) type.

> I must be missing something crucial here.
> 
> I have a new concern too -- how to represent null (i.e. missing, blank) 
> values?

Use an atom.  In Erlang (which UBF has borrowed a lot from), null
is generally defined (by convention) to be the atom 'undefined'.
Thus if you want a null string or a null integer, the UDF(B) must
allow either an Int or the atom 'undefined'.  Otherwise you cannot
define a null Int.  (Same for the other types.)

> For strings it would be
> "" $
> 
> for constants
> '' $
> 
> for binary
> 0 ~~ $
> 
> (or
> ~0~~ $
> if the tilde prefix is preferable),
> 
> but for integers it would be
> 
>  $
> 
> .. that is, a blank. But this raises a few issues:
> 
> 1. How do you carry the type information for a blank integer?
> 
> 2. Is there a valid concept of typeless null? That is not only is the 
> value blank, but it also carries not type information?

Yes, the atom 'undefined' does this by convention, but this of course
means you cannot use the atom 'undefined' to mean a non-typless-null
value.  :)  It sounds ugly, but in practice it works better than say
the typeless SQL null.

> 3. It seems impossible to represent a null tagged integer -- it would 
> be indistinguishable from a plain constant.

Erlang has no concept of a null integer, it uses 'undefined' (by
convention).  You could define the atom 'null' or 'nullint' or 'nan'
to mean the same thing(s), but its your code that must define the
meaning of these atoms.  I much prefer the Erlang system of doing it
by convention, rather than forcing it on you.

> Do you or does anyone else have experience with confronting these 
> issues?
> 
> I can see that UBF(B) might help with some of these issues, since the 
> usage of values within a particular context would imply their type. 
> However, at this point I'm just concerned with getting plain old UBF(A).
> 
> Also, one of the things I'm trying to keep an eye on is places where 
> the spec introduces more work for the parser-builder. In my case, I 
> would like to use this with multi-vendor data and message exchange. In 
> these cases, having a clear, easy-to-implement spec is very important. 
> People need to implement this stuff in all sots of weird languages and 
> often in a hurry!

I'm not quite sure what you mean here.  Almost every language/system
I have worked in this far has a concept of a linked list, a concept
of an array, of a constant (atom), and numerics/strings/binaries.  Thus
you should be able to quickly read the UBF(A) spec and see the mapping
to your language environment, and just map it.  Perhaps the UBF(A) spec
just isn't clear on how one would handle null values?

One thing I like about UBF(A) is that it should only take a few days
to write a parser, while XML is estimated to take about 3 weeks.  Thus
most developers should be able to bring a UBF(A) parser online in a very
short time, perhaps about the same amount of effort required to just
write a simple SAX or DOM parser (which uses an existing parser).  :)

-- 
Shawn.

  When smashing monuments, save the pedstals -- they always come in handy.
  		-- Stanislaw J. Lem, "Unkempt Thoughts"