Re: Dynamic variable typing?

• Date: Tue, 23 Jul 1996 12:34:47 PDT
• From:
  Michael Brundage <anomaly@u.washington.edu>
• Cc: moo-cows@parc.xerox.com
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-To: <Pine.SOL.3.91.960722221754.7477B-100000@pluto>

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)

while

   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];
   endfor
   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?


michael
brundage@ipac.caltech.edu

• Re: Dynamic variable typing?
• From: hpa@trantor.zytor.com (H. Peter Anvin)

• Re: New MOO Maintainer: Me
• From: RICHARD JACOB CONNAMACHER <phantom@sfsu.edu>

• Prev: DB Crash
• Next: Re: Dynamic variable typing?
• Index: MOO-cows
• Thread: MOO-cows