[plt-scheme] Typed-Scheme and structs

From: Sam TH (samth at ccs.neu.edu)
Date: Sun Mar 22 10:28:36 EDT 2009

2009/3/22 Paulo J. Matos <pocmatos at gmail.com>:
> On Sun, Mar 22, 2009 at 1:48 PM, Sam TH <samth at ccs.neu.edu> wrote:
>> Sure, I'll try to do that.  Can you submit a bug report with the
>> feature request?  In general, I prefer to have these requests as bug
>> reports to keep track of them more easily.
>>
>> Also, are you sure you really want auto fields?  Auto fields, as they
>> exist right now, are only useful with mutation, and are fairly
>> inconvenient to use.  What are you planning to use them for?
>>
>
> In my case, I use it for constant fields. For example:
> I have a specification language whose expressions have an attached
> type. So, untyped, the structure looks like:
> #lang scheme
>
> (define-struct Type-Integer
>  ())
>
> (define-struct Variable
>  (name type))
>
> (define-struct Integer-Literal
>  (value
>   (type #:auto))
>  #:auto-value (make-Type-Integer))
>
> If I try to type it, I end up not being able to assign a constant to
> the Integer Literal. Anyway, that's not a big problem because I can
> set it automatically when I create the structure or export a
> make-Integer-Literal that sets it automatically.

Ok, that makes sense.

> Another issue is, I have several structures defining all the
> expression types in my language and I have a function get type that
> accesses the type field of each structure and returns it by converting
> the structure to a vector and returning the last vector field. This
> doesn't seem to work in typed-scheme. Should I file it as a bug?

No, this can't be made to work with Typed Scheme.  `struct->vector'
inherently exposes the implementation details of whatever struct it is
given.  For example, if you hide extra fields in a substructure,
`struct->vector' exposes them.  Also, `struct->vector' changes its
behavior based on the (dynamic) inspector hierarchy, which Typed
Scheme does not track.

> The alternative it to use match on the structures and get the type
> field but this intuitively seems a lot slower than converting to
> vector and getting its last field.

The following match pattern:

(define-struct y (a))
(match x
  [(struct y (pat)) ...])

is equivalent to

(if (y? x)
    (let ([pat (y-a x)]) ...)
    (error 'fail))

which shouldn't be any slower, and is probably faster, than using
`struct->vector'.

> Any alternative designs suggestions are welcome.

You could have your superstructure have a 'type' field, and then
accessing that would just be a single accessor.

-- 
sam th
samth at ccs.neu.edu


Posted on the users mailing list.