I came across this "mutable-define" by Eli (3+ years back)... ;; http://paste.lisp.org/display/67203 ;; this is a PLT version, translate as necessary
(define-syntax-rule (define-mutable name expr) (begin (define b (box expr)) (define-syntax name (syntax-id-rules (set!) [(set! name new) (set-box! b new)] [(name . xs) ((unbox b) . xs)] [name (unbox b)])))) ;(define x 1) ;(define x 2) ...which seems beautifully concise for the job. The only problem is that it only seems to work in the interactions window in drracket. Is there a way to have it working inside a module? ... hopefully so that all the tweaks would take place inside the very module, rather than "required" from elsewhere (that would keep it an GP individual's property/"gene"). This is obviously what Danny is trying to explain me - "...language variant of Racket where "define" acts like redefinition at the module toplevel..." - but once again, I seem to be reaching out things before understanding them. br, jukka > > >>> The offspring is basically a module source code. Due to GP's crossover >>> and >>> mutation functions, the offsprings source code can suggest function >>> redefinitions in (atleast) two ways. For example >> >> You might consider a customized module language that's more amendable >> to the kinds of code mutations you're considering. That is, it's >> possible to have a language variant of Racket where "define" acts like >> redefinition at the module toplevel. I have an example of something >> like this in my Arctangent toy language (Refernce: see the definition >> of 'def' in >> https://github.com/dyoo/arctangent/blob/master/language.rkt) >> > > Thanks Danny, I got lots of new ideas from this. A customized language is > a great possibility. However, there's quite a lot of existing "creatures" > which I'd rather keep valid and intact. What I'm now thinking, is either.. > > A) "Inject" the kind of def/arctangent definition to a > individual/population and see if it takes off. > > B) Allow individuals to use the new "def" function if they ever come > across it (by crossover/mutation e.g.). This would be a part of the > initial environment "require". > > C) Try to find a way to replace the original "define" definition with the > "def". This would be the fastest way to deploy it, but I'd need to be > careful not to break the earlier work. > > Propably a combination of A and B might be the best bet. The initial > environment is expanded to cover a new function def1 (as a primitive, but > not the source), and some individuals could be injected with def2 > including the source. Having the source included, exposes it to > evolutionary changes. So, you would end up having three variants (define, > def1 def2) available to choose from. If these were interchangeable, > mutation could easily handle it. And new variants could evolve faster than > spontaniously (who knows if there is something like that already in the > population :) > > And I may end up creating a new #lang in the end, if necessary. > > >> >> >> I don't think redefinition should be the default, given that standard >> Racket's approach is to generally make mutation an explicitly >> represented feature. That is, if I want to see that something stays >> the same, I grep for 'set!' in my code, and if I don't see it, I can >> assume that I don't mutate my toplevel. >> > > Makes sense, I agree. But if there was a commandline option like > > $ racket -allow-redefinitions ... > > available, that would be great. Or if you could somehow enable it by code. > > > br, jukka > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > ____________________ Racket Users list: http://lists.racket-lang.org/users