[racket] Generics and modules

From: Tobias Hammer (tobias.hammer at dlr.de)
Date: Wed Aug 28 05:07:52 EDT 2013

On Tue, 27 Aug 2013 20:03:43 +0200, Greg Hendershott  
<greghendershott at gmail.com> wrote:

>> I've been wondering whether it would be more practical for  
>> struct-generated
>> names to concatenate with colon (":") as a separator, rather than with  
>> minus
>> ("-").
>
> 1. Yes. In addition to name conflicts, it's harder on human code
> readers (or at least, me) when '-' is overloaded. Especially if the
> struct name and/or field name have a hyphen. Quick, is 'a-b-c' a
> struct 'a' with a field 'b-c', or a struct 'a-b' with a 'c' field?
> Using ':' would be clearer. (If '.' weren't a special reader char,
> that would be even better, wrt other langs.)  It's not a huge deal,
> but it's a bit more cognitive load when learning Racket and even (for
> me) reading code after a few years.

. is only special when surrounded by spaces abc.def is a perfectly valid
variable name (as is abc. and .abc). Btw i adapted to a kind of
c-style /t suffix, although i don't really like it.

> 2. Also, although I haven't given it deep thought and maybe it's a
> poor idea, I'd like structs to join the `dict` club to which almost
> everything else belongs.
>
> That way, if `r` were an instance of a `roomba` struct with a
> `protocol` field, you could say something like
>
>     (dict-ref r 'protocol)
>
> And further, if you're willing to pay more runtime cost of redefining
> #%app, you could also sugar as:
>
>   (r 'protocol)

Attaching a prop:procedure would be sufficient and only impacts the struct
access itself, not every statement.

> Plus a threading macro can make nested struct references nearly as
> concise as in a {} lang.

I don't know what you exactly mean but if implementing short-cut access
(r 'protocol 'version) might be an easy and concise option.

> Maybe this is a silly idea because, if I _really_ want this, today I
> could simply choose some dict such as a hasheq instead of using a
> struct. Well, for my own data definitions; there's still the matter of
> working with other collects.

But you would loose all the other struct features like inheritance,  
properties,
generics etc. Not really a good trade-off.

Tobias

Posted on the users mailing list.