Sorry, I think I was being very unclear. I was only discouraging
something `defadvice`-like mutating the behavior of normal Racket
procedures, which looks like what was probably originally described:
> (define (greet name)
(println (string-append "Hi, " name)))
[...]
> (before greet ~a) ; argument to greet is now passed to ~a before
greet gets it
> (greet 'bob)
"Hi, bob!"
I think the most the likely reason one would do `before` like this [1]
(rather than simply altering the definition source code of `greet` in
the normal fashion, or defining a `greet` or `greet2` that wraps the
original `greet`), is that you want to change the behavior of `greet`
for other modules/environments, even though you don't normally control
the module/environment in which `greet` is defined. So you're mutating
a normal procedure object that continues to be used in other
environments, which I think defies expectations in Racket.
In current Racket, the defining module wasn't expecting its own
procedure definition to change out from under it, and other users of
that module also weren't expecting it to change.
Racket semantics for procedures seems good for software engineering, as
well as for tools static analysis, and as a foundation for DSLs and
other languages implemented as transformations to Racket, and I don't
want to break all that.
When we want polymorphism, we can use something like generics, which
normally tells both humans and tools that a particular different
abstraction is happening (even if you implemented it with normal
procedures -- the code and documentation would tell you of the
abstraction). Whether to do that is also a decision of the module that
provides the procedure/generic definition and documents it.
[1] However, if `before` in the quoted example is actually only
syntactic sugar for `define` with `apply`, then it's not mutating the
original procedure, so I can put down the fire extinguisher. In that
syntactic sugar case, whether to do it is a very local decision, of each
module that internally opts to use that sugar. Maybe that sugar makes
sense, for those particular modules that use it, within whatever
project/organization maintains that source code.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
