[plt-scheme] naming convention for structure constructor vs. wrapper?

Why not use a module or a unit to re-export
the thing with the right name: make-foo

(module foo mzscheme

   (define-struct foo (i))

   (define (create-foo i)
     (if (number? i) (make-foo i) (error))

   (provide (rename create-foo make-foo)))

Or do it as a macro. Look at Chez's define-structure, too.

-- Matthias


On Jun 30, 2004, at 7:33 PM, Robby Findler wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> I usually use build-XXX in that case (esp. when it is a procedure).
>
> Robby
>
> At Wed, 30 Jun 2004 18:45:04 -0400, Doug Orleans wrote:
>>   For list-related administrative tasks:
>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>> I often find myself defining a wrapper around a structure constructor,
>> either a procedure that takes a different number of arguments (e.g. to
>> provide default values) or a macro that provides some syntactic sugar
>> for construction (or both).  I want to provide both the wrapper and
>> the underlying constructor, so I have to come up with a new name for
>> one or the other.  Is there a naming convention for this pattern?
>> I've been renaming the `make-foo' constructor to `make-foo*' and then
>> naming the wrapper `make-foo', but I'm thinking this is an abuse of
>> the `*' convention (which is already somewhat abused: in the case of
>> `let*' or `send*' it implies serial repetition, whereas in
>> `syntax-case*' and `class*' it implies extra arguments).  I was
>> thinking of using `foo' for the wrapper if it's a macro (and keeping
>> `make-foo' as the constructor procedure), similar to `generic'
>> vs. `make-generic', but then this clashes with the syntax binding
>> produced by `define-struct', which I want to keep so that users can
>> define subtypes (or use match, etc).  Any other ideas?
>>
>> --dougo at place.org