On 29.03.2011 1:47, bearophile wrote:
Dmitry Olshansky:

http://dsource.org/projects/dmdscript-2. Note that I haven't touched it
in couple of dmd releases, it may need cosmetic fixes.
I will try it.


No problem, feel free to report any issues. There should be working bugtracker if I remember correctly.
http://swtch.com/~rsc/regexp/regexp1.html, it could be a starting point,
Before fully embracing the contents of that page, look at its critics too.


I've seen them, and they are expected, also I thought I clearly presented some of logical considerations.
3) When I saw Don's comments on fixing CTFE, I remembered something D
can do _better_  than most others mainstream compiled languages -
metaprogramming. So having a StaticRegex compiled at compile-time
(inevitable calambour) would give us an  edge over comparative
implementations.
But it inflates the binary too, if overused, because each RE pattern becomes a 
compiled function (or more than one).

Well, in case that result would be a data structure or bytecode created at the compile-time using CTFE. The function for matching or replacing using the resulting structure/program would be the same as run-time one. It's "inflating" binary like any static data. Then StaticRegex!"whatever" should be convenience wrapper hiding all this complexity. Anyway I partly agree, there are limitations and considerations when using such technique. And it would rely on CTFE that does not leak memory like hell.

Another thing to sort out is style: are we sticking with ECMA or
switching to Perl / GNU? Shall we provide also different versions of
syntax?
One RE syntax in a language is more than enough :-) But there are some features 
of the Python REs that I'd like to see bolted-on to the ECMA REs used by D.
BTW which ones? Now is the time to propose them.

So I suggest a superset of ECMA.

Your vote counted ;)

Bye,
bearophile


--
Dmitry Olshansky

Reply via email to