records generated from UBF

Joe Armstrong joe@REDACTED
Tue Apr 22 10:46:06 CEST 2003


Good point :-) - I guess there should be one more operator meaning
undefined - The obvious choice would be "?"

This looks like something for UBF-2 (if there ever is a UBF-2 :-)

Otherwise you could use just # which is the nil terminator at the
end of a list - but you'd have to change the parser etc. (and the contract
checker to do this).

I haven't though about it a lot but at first sight using "?" might allow
a simplification of the contract rules using "?" instead of ANY - which
would make then more readable and possibly more powerful (a la Prolog)

/Joe



> 
> I have a new concern too -- how to represent null (i.e. missing, blank) 
> values?
> 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?
> 
> 3. It seems impossible to represent a null tagged integer -- it would 
> be indistinguishable from a plain constant.
> 
> 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!
> 
> Thanks,
> 
> Erik.
> 
> 
> 
> >
> > /Uffe
> >
> >
> Erik Pearson
> Adaptations
> desk +1 510 527 5437
> cell +1 510 517 3122
> 




More information about the erlang-questions mailing list