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