Hi,

First of all thanks for your work on re2c. It's nice to see that the
project is moving again.

Disclaimer: I'm not talking for the PHP community. I'm just one of the dev
maintaining piece of re2c code and this is only my personal opinion and
also info about how we use it in PHP.

We use re2c in PHP quite a lot as you probably know (one of your tests is
for zend_language_scanner...). I think there are 4 scanners (language, ini
system, phar path check and serialization) in PHP 5. I have recently added
another one which is a json scanner (
https://github.com/php/php-src/blob/master/ext/json/json_scanner.re ) which
will be part of upcoming PHP 7.

Re2c is a required dependency for building PHP from source (It means that
everyone who builds PHP has to install re2c :)). There also is a version
check but the range of supported version is from 0.13.4 ( you can find the
whole ac check logic in
https://github.com/php/php-src/blob/master/acinclude.m4#L2173 ). The reason
is a flexibility for users building PHP because the re2c version in the the
most distros is 0.13.5 AFAIK.

The reason why I write all of this is that I think we will have to support
for some time old and new versions until we increase the the supported
version.


On Tue, Feb 10, 2015 at 5:44 PM, Ulya Fokanova <skvad...@gmail.com> wrote:

>  I'm going to rename old primitives as well:
>
> YYCURSOR -> RE2C_CURSOR
> YYMARKER -> RE2C_MARKER
> ...
> yych  -> re2c_ch
> yy123 -> re2c_123
> ...
>
> This will break backward compatibility.
> I'll make a switch "--old-names" that will enable old names
> and try to make good error messages when possible.
>
>
This will basically break all our scanners. I don't think that it's a good
idea to break it without giving any time for preparation. We could just add
switch for specific version and keep the old name. However I don't think
that this is a good solution of the migration problem.I think it would be
good to allow both definition. You could basically generate something like
this:

#ifndef RE2C_CURSOR
#define RE2C_CURSOR YYCURSOR
#endif

After few releases you could deprecate YYCURSOR and add warning during re2c
generation or even compilation (#warning).

Then after some time you could drop it completely in the next big version.

I think that this would add time for changing the definitions.

Thoughts?


We should change names once and for all, so now is the right time
> to come up with renaming ideas. re2c has three types of names:
>
>    1. user-defined names (YYCURSOR, YYSETSTATE, RE2C_BACKUP_CTX, etc.)
>    2. re2c-gererated names (yych, yy123, yyFillLabel, etc.)
>    3. names that appear only in inplace configurations (re2c:condprefix,
>    etc.)
>
> My proposal: make all names lowercase with underscores and substitute
> 'yy' with 're2c_'. This will unify names used in interface code like
> 'YYCURSOR'and 'yych' and also names used in inplace configurations
> like 'yyFillLabel':
>
> re2c_cursor
> re2c_set_state
> re2c_backup_ctx
> ...
> re2c_ch
> re2c_123
> re2c_fill_label
> ...
> condprefix
>
> ?
>
>
I'm not big fan of lowercase macro definition so I would be probably for
RE2C_CURSOR and so on...

Cheers

Jakub
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Re2c-general mailing list
Re2c-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/re2c-general

Reply via email to