On Wed, Feb 14, 2001 at 05:37:35PM -0500, Ilya Zakharevich wrote: > On Wed, Feb 14, 2001 at 02:27:26PM -0600, Jarkko Hietaniemi wrote: > > > On the scale of disasters in the Perl design, IMO this is less than > > > the qu// horror, but on par with forcing h2xs to produce a > > > backwards-incompatible code, v3.4.5 thingies, or using REx-opcodes > > > which switch their unicode-face at runtime. > > > > I won't comment on the IV/UV matters but on this I feel personally > > obliged to say something on these. Polymorphic REx-opcodes are a necessity > > because out data is polymorphic in its Unicodeness, in compile-time > > you cannot know what the data will be. I see no way out of that. > > I explained a simple way out of it many times already: make a PMOP > have two pointers to a REx instead of one. Switch *the whole REx at > once* instead of making a switch in each opcode individually. > > Do not remember any objection from you (or anybody) on this... No objections. It's just that implementations speak much louder than words. If you or anybody produces such a patch that solves the problems in matching Unicode, I won't have no problems ripping my solution out and applying the new one. If the new code is faster than the current scheme, or simpler, all the nicer. (I confess that I really liked getting rid of dozens of essentially duplicated opcodes with my solution, though: ALNUM vs ALNUMUTF8, yechhh...) > > About the proposed qu//: it's not a perfect solution, but it is a > > compromise. It gives for those of who need us the way to produce > > UTF-8: compactly and in compile-time, as opposed to pack("U", ...). > > There is a mechanism for this already. It is called overloaded > constants. I have a mechanism that can replace Perl: it's called Turing's machine. Or an abacus, for that matter. More details on your proposed solution would be conducive for further discussion. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen