I don't find the behavior strange.
1. Declaring dialog generic in mg-1 and mg-2 and merge generics in
mg-3 solves the mg-3 case.
2. When exporting dialog in mg-4 the system automatically undefine the
dialog symbol imported. By in stead using :re-export (dialog) the mg-4
case
is solved.
The ques
For the mg-3 case, Actually, only (merge-generics) in mg-3 is needed,
the
accessors are automatically generics.
/Stefan
On Saturday, February 23, 2013 08:54:09 AM Daniel Hartwig wrote:
> For those parts specific to racket, did you consider the (language
> racket ..) namespace, where an eventual language definition could be
> placed also?
Hmm, my problem with this is that to cover the racket lang is a
monumental eff
That makes sense, but if the promotion ever happens, then there might be a
bunch of old code using (compat racket ...) that would need to be
converted, and we would have to keep the (compat racket ...) modules around
for compatibility with old code. If there's any possibility that we will
want to r
Hello,
On Fri, Feb 22, 2013 at 9:32 PM, Ian Price wrote:
> Daniel Hartwig writes:
>
> > For those parts specific to racket, did you consider the (language
> > racket ..) namespace, where an eventual language definition could be
> > placed also?
>
> That sounds somewhat misleading, since Racket i
Let me illustrate the problem.
Consider macro syntax-parse written in (language racket). My view is
that the
sourcecode for that code should just have been copied from the racket
sources in order to keep the code maintainable. Could we use that
macro from whithin a guile scheme program? sometimes
