[Prev][Next][Index][Thread]

# Re: Dynamic variable typing?

- Date: Tue, 23 Jul 1996 12:34:47 PDT
- From:
- 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

Follow-Ups:

- Re: Dynamic variable typing?

- From: hpa@trantor.zytor.com (H. Peter Anvin)

References:

- 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

Home | Subject Index | Thread Index