[gambit-list] Figuring out opaque:, and macros expanding to macros

Álvaro Castro-Castilla alvaro.castro.castilla at gmail.com
Mon Apr 21 06:38:43 EDT 2014


Hi,

Although this may seem a very obvious question, none of the obvious answers
are true. I think many Gambit users would benefit of really knowing how to
use this, since there is barely any code that you can use as reference, no
documentation and no google results:

https://github.com/search?l=Scheme&q=opaque%3A&ref=advsearch&type=Code
https://www.google.es/search?q=gambit+opaque&oq=gambit+opa&aqs=chrome.0.69i59j69i57j69i60j0j69i64.1665j0j1&sourceid=chrome&es_sm=91&ie=UTF-8

False hypothesis I could come up with:

* Opaque types make their fields not accessible to extending types so you
can't access them using the parent type's procedures
* Opaque types make the fields unprintable by default
* Opaque types have R6RS semantics: [The opaque? flag must be a boolean. If
true, the record type is opaque. If passed an instance of the record type,
record? returns #f. Moreover, if record-rtd (see “Inspection” below) is
called with an instance of the record type, an exception with condition
type &assertion is raised. The record type is also opaque if an opaque
parent is supplied. If opaque? is #f and an opaque parent is not supplied,
the record is not opaque.] This doesn't hold true either for Gambit's types
and you don't have such inspection procedures.
* Opaque makes the predicates yield #f for instances of the type always
* Opaque makes the predicates of the parent types yield #f for inherited
types' instance
* Opaque disables the generation of a type exhibitor
* Opaque generates different code somehow. At least, I can't see a single
difference.
* Opaque types can't be serialized and deserialized with object->u8vector

Is there any other obvious possibility that I'm missing out?

Thank you








On Tue, Apr 15, 2014 at 8:54 PM, Álvaro Castro-Castilla <
alvaro.castro.castilla at gmail.com> wrote:

> That's an awesome trick, Marc. Thanks!
>
> But still.. I don't see any difference:
>
> > (define-type context
>   id: a0000000-0000-0000-0000-000000000000
>   constructor: macro-make-context
>   macros:
>
>
>   ;; opaque: WITHOUT OPAQUE
>   unprintable:
>   a)
>
> (begin
>   (##define-macro (macro-make-context p1) (##list '(let () (##declare
> (extended-bindings)) ##structure) ''#<type #19 context> p1))
>   (##define-macro (make-constant-context p1)
> (##define-type-construct-constant 'make-constant-context '#<type #19
> context> p1))
>   (##define-macro (context? obj) `((let () (##declare (extended-bindings))
> ##structure-direct-instance-of?) ,obj
> ,''##type-1-a0000000-0000-0000-0000-000000000000))
>   (##define-macro (context-a obj) (##list '(let () (##declare
> (extended-bindings)) ##direct-structure-ref) obj 1 ''#<type #19 context>
> #f))
>   (##define-macro (context-a-set! obj val) (##list '(let () (##declare
> (extended-bindings)) ##direct-structure-set!) obj val 1 ''#<type #19
> context> #f)))
>
> > (define-type context
>   id: a0000000-0000-0000-0000-000000000000
>   constructor: macro-make-context
>   macros:
>   opaque: ;; WITH OPAQUE
>   unprintable:
>   a)
>
> (begin
>   (##define-macro (macro-make-context p1) (##list '(let () (##declare
> (extended-bindings)) ##structure) ''#<type #20 context> p1))
>   (##define-macro (make-constant-context p1)
> (##define-type-construct-constant 'make-constant-context '#<type #20
> context> p1))
>   (##define-macro (context? obj) `((let () (##declare (extended-bindings))
> ##structure-direct-instance-of?) ,obj
> ,''##type-1-a0000000-0000-0000-0000-000000000000))
>   (##define-macro (context-a obj) (##list '(let () (##declare
> (extended-bindings)) ##direct-structure-ref) obj 1 ''#<type #20 context>
> #f))
>   (##define-macro (context-a-set! obj val) (##list '(let () (##declare
> (extended-bindings)) ##direct-structure-set!) obj val 1 ''#<type #20
> context> #f)))
>
>
> There is no difference!
> I noticed that some attributes produce no difference in the output, but
> will somehow set some internal flag of Gambit. That's the case of
> :unprintable, which makes a difference when pretty-printing the object but
> produces no difference in the generated function/macros. If this is the
> case, what does opaque: actually do?
>
>
> Thanks a lot!
>
>
>
>
>
>
>
>
>         Álvaro Castro-Castilla
>           Digital Experiences.   --   visit The Blog<http://blog.fourthbit.com/>
>
>  <http://fourthbit.com>
>
>
>
> On Tue, Apr 15, 2014 at 4:57 PM, Marc Feeley <feeley at iro.umontreal.ca>wrote:
>
>>
>> On Apr 15, 2014, at 9:59 AM, Álvaro Castro-Castilla <
>> alvaro.castro.castilla at gmail.com> wrote:
>>
>> > Hi!
>> >
>> > I've been figuring out all the attributes available with define-type in
>> Gambit. Testing and thanks to:
>> >
>> >
>> https://mercure.iro.umontreal.ca/pipermail/gambit-list/attachments/20090226/af2ee44c/attachment-0001.txt
>> >
>> https://mercure.iro.umontreal.ca/pipermail/gambit-list/2004-December/000043.html
>> >
>> > I could understand all but one: opaque. The ways to "learn" how things
>> work with macros producing code is generally the trick (pp (lambda ()
>> (macro...)) 'asdf). But what about macros that produce macros? In that case
>> you get an empty form with 'asdf, so no way to know what has been generated.
>> >
>> > That of course applies to define-type. There is no difference in
>> generated code with opaque: keyword, so I assume that it only affects
>> non-generative types. Can I see the generated code in such case?
>> >
>> > Reading Gambit's code in nonstd.scm doesn't clarify things either.
>> >
>> >
>> > Thank you!
>> >
>>
>> Try:
>>
>> (set! ##define-type-expansion-show? #t)
>>
>> Marc
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20140421/5f8c748d/attachment.htm>


More information about the Gambit-list mailing list