Something to parse into...

[Ben Hyde <bh...@pobox.com>]

This is a proposal to add some dynamicly typed data structures to
Apache 2.0.   

I'm asuming...
 1) that we desire such a facility.
 2) that we want it embedded in the pool hierarchy we know and love.
 3) we would parse some portion of requests into instances of these.
 4) we would parse configruation data into instance of these.
 5) that the raw C data should be accessible if only because supporting
    the old APIs will demand it.

I'm avoiding the issue of the printed representation for these, but
I'd assume we'd do the usual things for debugging reasons.

Do we want something like this?

   - ben

The type hierarchy of these would be pretty shallow, for now it
wouldn't be extensible into the structs like response_rec and
core_dir_config.

 ap_dynamic_t -- parent type of the following.
   ap_integer -- has a 64 bit signed value.
   ap_symbol  -- has a name, a plist, and a pool.
   ap_cons    -- has a car and cdr both of type dynamic_t
   ap_vector  -- has a length an that many 
   ap_string8 -- has a length and that many 8bit characters
   ap_table   -- has a set of key, value pairs.
   ap_pointer -- has a kind (a symbol) and 32 bit unsigned value
   ap_unbound_type -- unique type with only one instance

Instances of dynamic_t which contain pointers (cons, vector,
pointer, and symbol) must ever contain a pointer into a pool
who's life is shorter than the pool they reside in.  That's
why a symbol has to have a pool so plist insertions can
allocate from the correct pool.

I presume we will parse requests and configuration files into
instances of these data structures.

Operations on ap_dynamic_t:
  ap_symbol *type_of(ap_dynamic_t *x)

Operations on ap_integer:
  ap_integer *ap_make_integer(pool *p, sint64 v)
  sint64 ap_integer_value_of(ap_integer *x)
  sint64 ap_aset_integer_value(ap_integer *x, sint64 v)

Operations on ap_symbol:
  ap_symbol *ap_intern_raw(pool *p, char *name)
  ap_symbol *ap_intern(pool *p, ap_string8 *name)
  ap_string8 *ap_symbol_name(ap_symbol *x)
  pool *ap_symbol_pool(ap_symbol *x)
  ap_list *ap_symbol_plist(ap_symbol *x)
  ap_list *ap_set_symbol_plist(ap_symbol *x)

Operations on ap_vector:
  ap_vector *ap_make_vector_raw(pool *p, uint16 length)
  ap_dynamic_t *ap_vector_aref_raw(ap_vector *x, uint16 index)
  ap_dynamic_t *ap_vector_sref_raw(ap_vector *x, uint16 index, ap_dynamic_t *v)
  ap_vector *ap_make_vector(pool *p, ap_integer length)
  ap_dynamic_t *ap_vector_aref(ap_vector *x, ap_integer index)
  ap_dynamic_t *ap_vector_sref(ap_vector *x, ap_integer index, ap_dynamic_t *v)

Operations on ap_string8
  ap_string8 *ap_make_string(pool *p, uint16 length, char *inital_valueQ)
  char *ap_string_contents(ap_string8)

Operations on ap_table
  ap_table *ap_make_table(pool *p);
  ap_dynamic_t *ap_get_table_value(ap_table *x, ap_dynamic_t *key, ap_dynamic_t *default);
  ap_dynamic_t *ap_set_table_value(ap_table *x, ap_dynamic_t *key, ap_dynamic_t *value);

  deftype ap_table_generator; /* Opaque type for iteration over ap_tables */

  ap_table_generator ap_reset_tgenerator(ap_table_generator *g, ap_table *x)
  boolean ap_tgenerator_next(ap_table_generator *g)
  ap_dynamic_t *ap_tgenerator_key(ap_table_generator *g)
  ap_dynamic_t *ap_tgenerator_value(ap_table_generator *g)

Operations on ap_pointer
   ap_make_pointer(ap_symbol *kind, void *address)
   ap_symbol *ap_pointer_kind(ap_pointer *x);
   void *ap_pointer_value(ap_pointer *x);

Globals
   ap_symbol *ap_nil;
   ap_symbol *ap_t;
   ap_unbound_type *ap_unbound;

Re: Something to parse into...

[Ben Hyde <bh...@pobox.com>]

Roy T. Fielding writes:
>>This is a proposal to add some dynamicly typed data structures to
>>Apache 2.0.   
>[...]
>>Do we want something like this?
>
>I am not a big believer in replacing entire type systems with dynamic
>equivalents.  

Nor i in this kind of system.  There is a kind of imperialism about
dynamic typing that spreads thru systems :-).

> I am even less of a fan of Lisp constructs.
> ...  but not reinventing Java or C++.

and then there is XML.

There is a lot of craft knowledge in these three communities
that it is helpful to leverage.  It is difficult to firewall
out all the design patterns in these three communities.

I'm not adding a garbage collector, nor an interpreter.

> I think a
>good set of abstract data types that match what we intend to parse,
>with an internal representation that is efficient for C, would be
>a better design.  That still means defining things like lists and
>queues, ...

That was my intent, except I non-parsing uses I'd like to address
(request pattern matching for example).

To me it would seem the harder problems are
   (a) where it gets used,
   (b) how the perimeter is handled, and
   (c) what's it's relationship to XML?
Of those I only tried to address (b) in the proposal.

>Just my opinion.

It would be good for other people to opine where they want
the chips to fall.

>....Roy