[plt-scheme] AOP interactions with (PLT) Scheme

I can certainly do that, and probably will.  I was just curious: this problem seemed like it could be neatly solved using AOP but I can't see a way to implement AOP w/ the restrictions on statically knowing names and bindings required by the module and macro systems.  So largely I wanted to hear the opinions of those more knowledgeable than I: is AOP fundamentally at odds w/ hygienic macros/the module system, or is there some way to unify them?  I'm aware of AspectScheme but my understanding is that it doesn't work with the module system.

N.


----- Original Message ----
From: Robby Findler <robby at cs.uchicago.edu>

Do you really need to make the decision at compile time? Can you have
them all expand to the same thing, but then have some parameter or
something like that control the actual behavior of the expanded
expression?

Robby

On 2/16/07, Noel Welsh <noelwelsh at yahoo.com> wrote:
> Context:
>
> I'm trying to add a new feature to SchemeUnit.  In SchemeUnit:
>
>   Test = Test-Suite String (list-of Test) | Test-Case String Thunk
>
> A number of people would like SchemeUnit to automagically add test-cases to a default test-suite (so test cases are no longer values).  A number of others  would like the existing behaviour to remain.
>
> This seems suspiciously AOPish.  In some context an expression like
>
>   (test-case "Foo" (check-= 1 2))
>
> [Note: this is a macro that expands to make-test-case]
>
> evaluates to a value (a Test-Case).  In other contexts it evaluates to a side-effect like
>
>   (add-to-default-suite! <a test case value>)
>
>
>
> The Problem:
>
> I'd like my implementation to have these properties:
>
> 1. There are a bunch of things that expand into test-case.  They should be oblivious as which context they are in.
>
> 2. Ideally the context would be module scoped and chosen based on which SchemeUnit collection is required.  So
>
>   (require (planet "test.ss" ("schematics" "schemeunit.plt")))
>
> get the original context and
>
>   (require (planet "littleunit.ss" ("schematics" "schemeunit.plt"))))
>
> gets the new automagic context
>
> 3. The original SchemeUnit code should be oblivious to the fact it is being used with aspects.
>
> Clearly if I modify the original SchemeUnit code (breaking requirement 3) I can get what I want.  I just need to make test-case aware of the current context.
>
>
>
>
> Finally, The Question:
>
> It seems that all 3 requirements can't be implemented in PLT Scheme.  I think my requirements break hygiene and break the module system's prohibition on redefining names.
>
> So:
>
> 1. Is there a way to implement what I want?
>
> 2. Does anyone have any enlightenment to pass on regarding the tradeoffs made wrt hygiene/the module system and meta/aspect-oriented programming?  Are they fundamentally at odds, or can they be unified with some encompassing concept?
>
>
> Many thanks,
> Noel
>
>
>
>
> ____________________________________________________________________________________
> Never miss an email again!
> Yahoo! Toolbar alerts you the instant new Mail arrives.
> http://tools.search.yahoo.com/toolbar/features/mail/
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>





 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/