Jesus Christ. This happens whenever I mention this, no matter how much I try to assure people I know what I am talking about.
Sorry for misunderstanding. However, it was partly your own fault for presenting a poorly explained problem with little or no explanation, a lack of use-cases, and a brief allusion to a subject where many people think they need something like this when they don't. I made an assumption that you were doing as many people do - not that you were doing something much more esoteric.
I have it all working, infact I have made some rather clever modifications to the standard algorithm to make mine more effecient.
But in a problem domain some of the symbols in a language are constants.
Like for example a drawing domain.
The operations are things like
move pen vertically X
and change pen colout Y
The user needs to be able to say what can fit in the X and Y slot.
For X it would be a float
for Y it would be
There is nothing you describe here that differs from standard AST-based GP. Since you still haven't explained fully, it's not entirely clear whether your terminals are all strings (i.e. user can type them into a soft config file) although I get the impression this is your approach.
In that case, you need them to declare typing some other way - which you haven't mentioned - or be using a type-inference system a la ML. Neither sounds particularly desirable; hence I'm still unsure what you're trying to do (which makes it hard to suggest helpful approaches).
Now some people think I should make the user to specify a class to be loaded dynamically. This means the user has to write trivial enumeration classes for his problem domains... very naff
"Naff"? Or just "obvious, easy, and standard practice"?
Personally, for java, I'm a fan of each terminal and non-terminal being a UID-keyed immutable object, with children of non-terminals being passed in as args to the evaluate method, so that your AST's can be stored as something extremely compressed (both in memory and when serialized) hardly more verbose than a compressed bit-string (using a sensible tree-to-string conversion) but are still simple to execute using an execution layer you only need write once and never fiddle with.
"pure OOP" class structures are much easier to write and to debug, but the memory requirements are punitive in java, unless you start getting fancy and using structs or something (which I've wanted to try for a long time now, but never had the spare time yet).
(infact my system is slightly more complex than that becuase my GP produces typed syntax trees)
Right hopefully someone will now beleive me when I say I would like to program a class that parses a RE and generates random string from that definition.
I agree with the earlier poster that this seems a poorly thought-out aim. I'll provide you with one that just provides a plus followed by an infinitely long string of digits followed by a dot followed by another infinitiely long string of digits (the only limits being how long before your system runs out of RAM to hold the number of digits I'm amassing). This is entirely consistent with the regexp you cited, yet I struggle to see how it's anything but useless to you.
Now, if you were to guarantee a finite limit on the number of occurrences of each state [sorry, can't remember the mathemetical term /me blushes]
(thereby severely limiting the number of regexps possible) then I could suggest sensible implementations. But then, if that were all you wanted, it seems you wouldn't be asking, because that's pretty trivial to code
Maybe preverting the Pattern class itself. I have looked at the source but its a bit weird so I dunno.
If my last para is indeed what you want to do then I agree you'd want to try and take advantage of the FSM that is pre built when you instantiate a pattern; you might want to take a look at the open-source Apache regexps which might be easier to break apart (nb: I *think* that's what became of the OROinc regexp implementation, which was a pretty good one).
But then again, I still don't understand what you're after, so ...