#lang racket (struct human (group)) (struct human-group (humans)) ; identifier already defined in: human-group :disappointed: me want . as field separator

Here’s a word of advice: (define-syntax (struct+ stx) ...) :wink:

Well, several words. One line.

if based on struct, the fields will still be defined, or do you know a way to not or un-define them?

Could be based on vectors otherwise

You don’t really need to undefine them I think. Just generate them in macro scope, so that they are not visible anywhere else, but in macro, alias them with names you generate that are not in macro scope.

What about the non-field bindings? You need to ‘alias’ them too, it’s quite annoying

Yeah…

Another possibility

Generate a submodule

Use filtered-out to rename only things that you want to rename

filtered-out can work on regex, as shown in the example, so it’s kinda hacky, but also effective for your use case I think

aha, that’s interesting

Well, actually

If you know the prefix already

there’s no need to even use regex

but that won’t be for today, I just renamed to (struct human (the-group)) and be done with it :slightly_smiling_face:

lol

I guess another disadvantage of this solution is that you can’t define struct in internal definitions.

thing I want: a way for an identifier to be define-syntax’d to a list of other identifiers, and when you do a.b it looks up b in the list

(and for this to be integrated with structs, match patterns, syntax-parse, scribble, etc.)

so structs, but use . instead of - as a symbol joiner? doesn’t sound too hard to make

not a symbol joiner, I want them to be actual namespaces

\|a.b\|.b should be possible

oh, got it

that’ll be an interesting one

and module->exports should list a as the only provided binding

I’m a big proponent of namespaces in langauges, this would be nice to make in racket

this is definitely possible to make too, it just needs lots of work to integrate it with other stuff

from the last line of the python zen: > Namespaces are one honking great idea — let’s do more of those!

heh, yup :p

so you’re suggesting some sort of infix syntax where \|foo\|.\|bar\| could be resolved(?) to a \|bar\| inside of \|foo\|, right?

right, yup