Re: Datatyping Summary

My responses to Brian's issue list.
Note none of my "can't live with" issues made it to the list, I hope Brian
can correct this.

B1: property bloat in S
=======================

I can live with this.
I haven't yet discussed this with my colleague who is going to do the
implementation. If he can't live with it, I will change my position.

B2: multiple lexical representations
====================================
I like this, I do find it a strength in S.

B3: log:implies
===============
Since this is DanC's private implementation anything he says about it is
more likely to be correct than anything I say.
I think this is better addressed under B4.

B4: TDL breaks existing code
============================
False.
If you want complete backward compatibility then under TDL it is possible
to:
- use an empty set of datatypes
- always refer to the literal string not the value part of the pair
representation.

If you want datatyping in existing code then some parts of existing code
break in any proposal.
TDL differs from S in the following sense:
- TDL differentiates between the (untyped) lexicalization and the (typed)
value.
- S-B does not give access to the typed value.
Hence a TDL oriented API will have potentially distinct methods to access
the lexicialization and the typed value. Since old APIs will have one method
to access the string label, any old code will need to be reviewed as to
which is more appropriate.
For migration purposes mapping the old string label method onto the new
lexical form method will suffice, and code will not break.
It is not clear to me how S (particularly idiom B) helps improve existing
(or new) code.

B5: 	Storage
=============
This is a red herring that has been adequately addressed in my view.
If anyone seriously wants an account of how to do "tidy" TDL storage with
"untidy" access methods I will add that to my queue.
Sergey, do you withdraw this objection?



Jeremy

Received on Wednesday, 30 January 2002 04:38:50 UTC