> Macros would not help here, they have a strictly local look on the AST only .
> But they had to inspect different modules, they had to access the entire
> environment.
Well, there is `macrocache` which offers non-local AST storage, could help to
at least simulate these - how do we call them,
> The "pragmatic workaround" would probably be "Don't export the fields,
> then.", which works until there is a fourth module which actually needs
> access to them...
This will simply not happen because types being abstract remain abstract, they
can't be opened with the underlying type or field
So we have two separate problems, IIUC:
1) The intermediate abstraction leaks exported fields of `TOb` into the top
layer.
2) `mdlabst.Tcon` doesn't present the API of a matching type to the top layer.
The reason for #1 is probably that the Nim compiler doesn't evaluate generics
like concepts
> Is that the separation you wanted?
You just tried to achieve separation with inclusion, look at your imports. But
additional boilerplate code does not address the problem:
> # should probably have been `v.b = v.a + 5` in the original code
You got the point and missed it at the same time.
I i
> Unfortunately, run() does not have access to any of the abstract
> (constructor, operator) functions provided by mdlimpl. This is bizarre
> because Tcon , provided and exported by mdlabst , just checked that they are
> available!
The job of `Tcon` is to check whether `TOb` supports a certain
I have a couple of modules : mdlimpl, mdlabst and mdlprog. mdlimpl implements
(you guess it) some basic functionality. mdlabst (abstraction) imports mdlimpl
and operates on a type `TOb` given by mdlimpl, but the type gets not revealed
in mdlabst. To achieve this, functions defined by mdlimpl onl
