[racket-dev] cstruct and properties

From: Tobias Hammer (tobias.hammer at dlr.de)
Date: Mon Nov 12 04:11:19 EST 2012

On Sun, 11 Nov 2012 17:39:07 +0100, Matthew Flatt <mflatt at cs.utah.edu>  
wrote:

> At Wed, 7 Nov 2012 20:00:51 +0100, Tobias Hammer wrote:
>> i am currently playing around with properties attached to cstructs and  
>> ran
>> into some problems.
>>
>> Normally, with racket structs, i can access a property without an  
>> instance
>> of the struct via the struct type descriptor (struct:S). There seems to  
>> be
>> nothing similar for cstructs, so the only way i found to check for or
>> access a property is to create a dummy instance solely for this purpose.
>> Would it be possible to add a similar type descriptor for cstructs? To
>> account for the incompatibility with the one for structs it might make
>> sense to name it different, maybe cstruct:S or similar.
>
> I've added it as `struct:cpointer:S' --- sticking with "struct:"
> because it is a structure type in the usual sense, but adding
> "cpointer:" because it corresponds to the wrapper struct, and not
> really to `S' instances.

The naming is perfectly reasonable and now everything works as expected.
Thanks!

>
>> If such a descriptor would exists it should be included in the  
>> transformer
>> bindings for cstructs. Another info i am really missing there is the
>> super-type field. As far as i can see, it would be a valid semantic to  
>> set
>> it to the identifier if the cstruct was created by type and to set it #f
>> if it got its super-type by cpointer.
>
> After looking into this, I'm not sure what you had in mind after all.
>
> I fixed a related issue, which is that a cstruct subtype now inherits
> its parent's wrapper and properties. For example,
>
>  (define-values (p p? p-ref) (make-struct-type-property 'my-p))
>  (define-cstruct _S ([a (_array _byte 23)])
>     #:property p (lambda () _S))
>  (define-cstruct (_T _S) ())
>  (p? (ptr-ref (malloc _T) _T))
>
> produces #t.
>
> But I think that's not all that you were getting at, so maybe an
> example would help.

You are right, that not what i had in mind. What i tried to suggest is to
adjust the transformer time information for cstructs to bring them closer
to the ones of normal structs. I got a bit confused by the code, so scratch
that last part about super-type by cpointer.

Example:

#lang racket
(require (for-syntax racket/list
                      racket/struct-info)
          ffi/unsafe)
;; 1
(struct A (a))
(struct B A ())

;; 2
(define-cstruct _S ([a _int]))
(define-cstruct (_T _S) ())

(define-syntax (a stx)
   (printf "1: ~a\n2: ~a\n"
           (sixth (extract-struct-info (syntax-local-value #'B)))
           (sixth (extract-struct-info (syntax-local-value #'T))))
   #'(void))
(a)

=>
1: #<syntax:/home/hamm_to/tmp/racket-testing/cstruct-super-info.rkt:7:10 A>
2: #t

I would expect the syntax-object for identifier S at 2. #t says T has no
super-type and thats clearly not the case.

>
>> But one more thing on properties. A source of really nasty bugs is if  
>> you
>> try to use the ctype of a cstruct inside the property:
>>
>> (define-values (p p? p-ref) (make-struct-type-property 'my-p))
>> (define-cstruct _S ([a (_array _byte 23)])
>>    #:property p _S)
>
> Fixed in a way that turns that into an error for a too-early use of
> `_S', as we discussed.

Great, one less source of ugly segfaults.



-- 
---------------------------------------------------------
Tobias Hammer
DLR / Institute of Robotics and Mechatronics
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.hammer at dlr.de

Posted on the dev mailing list.