MOO-cows Mailing List Archive


Re: Dynamic variable typing?

On Mon, 22 Jul 1996, RICHARD JACOB CONNAMACHER wrote:
> * Make binary strings a separate data type.  Let me give my reasons for
> that:
>   I noticed a problem when I was programming the 1.8.0-friendly upgrade
> to BayWeb.  What I wanted to do is allow for extended character sets,
> like Latin1, using binary strings to represent the high range
> characters.  The problem is, when is $http to know whether the
> string is a binary string (ie extended) or whether it is a standard
> string (ie not extended)?  It is impossible to distinguish them from one
> another.  I could make it assume the output to be ascii unless other
> specified, but that complicates things that should, IMHO, be kept
> simple.  I'd like to see a BIN data type that allows for binary strings,
> and keep the STR data type as it was pre-1.8.0.

If you're going to distinguish between binary strings and ordinary
strings, then you might as well take the plunge and allow user-definable
data types.  Ideally, the server would allow these to be created within
the database (instead of at compile time).  Then we would need a uniform
way to deal with these typed variables.  So then you could code
   binary_string theData = "foo";
and now theData is tagged as having type "binary_string".  Or maybe
   latin1string theData = "something cool";

Then maybe we could have expressions like
   if(dynamic_typeof(theData) == "binary_string") {
	work with it in a way peculiar to binary strings
   } else {
        work with it as an ordinary string

or things like

   Vector a = {1, 2, 3};
   Vector b = {4, 5, 6};
   c = a+b ; /* c's type determined already by dynamic_typeof a and b */

Ideally, the behavior of these user-defined types could either be set at
compile-type (for efficiency) or be described in-db in terms of the basic
server types (for flexibility) -- your choice.  For example,

   Vector a = {1, 2, 3};

might be translated into

   a = $type_Vector:instantiate({1, 2, 3});

which might do nothing more than return the vector {1, 2, 3}
(possibly after doing some sanity checks)


   a + b

might translate into

   $type_Vector:+(a, b)

which might perform

   for(i=1; i<=length(a); i=i+1)
     a[i] = a[i] + b[i];
   return a;

(with suitable error-checking thrown in)

Similarly, you could create functions in-db to handle your binary_string
types in any way you see fit. After a suitable amount of prototyping and
testing, you could decide to translate it all into C and make it a formal
(local) server extension.

Of course, there are plenty of difficult questions, such as how to handle
type casts or functions/operators taking multiple arguments (and hence
multiple types), and in general what sort of syntax to adopt, but I would
rather see a flexible system like this than have N different (mandated)
flavors of basic variable types (such as strings and lists).  This would
also be a good topic to discuss before introducing server types for
dictionaries or frobs or whatever...

What does everyone else think?


Follow-Ups: References:

Home | Subject Index | Thread Index