Re: [re2c-general] renaming re2c primitives
Well, you almost convinced me. I didn't realize that re2c users are so strongly against trivial code changes. As for imaginary conflicts, I saw a real one when at some point I tried to add name YYEOF. Let's wait a bit till somebody else drops into discussion. :) -- 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
Re: [re2c-general] renaming re2c primitives
On Wed, Feb 11, 2015 at 3:27 AM, Ulya Fokanova skvad...@gmail.com wrote: Well, you almost convinced me. I didn't realize that re2c users are so strongly against trivial code changes. There are a lot of code bases that are in production use and wary about changes of this sort, especially when it's something like lexer/parser logic which can be a bit of a handful to understand in the first place. If it *doesn't* just work for whatever reason fixing it may be a bit daunting, especially if the guy who wrote the original lexer/parser code retired five years ago and no one on the current team knows anything about it. As for imaginary conflicts, I saw a real one when at some point I tried to add name YYEOF. This may or may not make any sense, but what about the following as a possibility? Have a --names_prefix option that, rather than hard coding old (yy/YY) or new (re2c/RE2C) options, allows a user specified choice? Default to yy/YY still, since that's the prevalent style in other tools and codebases, but allow any particular user to override (--names_prefix re2c, for example, would replace yy with re2c and YY with RE2C) if they have a situation where the deciding factor is avoiding conflicts rather than external compatibility. Would that be a practical option? Cheers, CY -- 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
Re: [re2c-general] renaming re2c primitives
On 10 Feb 2015, at 18:44, Ulya Fokanova skvad...@gmail.com wrote: • user-defined names (YYCURSOR, YYSETSTATE, RE2C_BACKUP_CTX, etc.) I suggest keeping the user-exposed names, such as YYCURSOR, YYLIMIT etc for backward compatibility. If #define YYCURSOR x need to be change, there is a lot of code that has to be rewritten, and we know whom to blame. Breaking naming convention also means that everyone using re2c will have to add extra code in their configure scripts to handle re2c versions. Besides, what is wrong with YYCURSOR, YYLIMIT? They follow the same YYNAME convention as you suggest. -- 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
Re: [re2c-general] renaming re2c primitives
YY prefix comes from yacc-family parser generators. re2c is often used in pair with these parser generators, so there's a possibility of name collisions. New input API http://skvadrik.github.io/aleph_null/posts/re2c/2015-01-13-input_model.htmlwill introduce some new user-exposed names. At first I suggested these names: YYPEEK YYSKIP YYBACKUP YYBACKUPCTX YYRESTORE YYRESTORECTX YYHAS but after some discussion on the mailing list https://www.mail-archive.com/re2c-general@lists.sourceforge.net/msg00243.html(read the whole thread) we decided to change names: RE2C_PEEK RE2C_SKIP RE2C_BACKUP RE2C_BACKUP_CTX RE2C_RESTORE RE2C_RESTORE_CTX RE2C_HAS It's clear that RE2C_ has always been a proper prefix. Breaking backward compatibility is bad, but we'll have to do it at some point. In a rapidly developing project I would first add a switch --new-names and after some two releases (when everybody migrates successfully) substitute is with --old-names, but re2c users show up too rarely and the usual migrating scheme makes no sense. Note that re2c users will have to either use switch --old-names (and modify build scripts) or make a trivial fix of source code, but not both. -- 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
Re: [re2c-general] renaming re2c primitives
On 10 Feb 2015, at 23:16, Ulya Fokanova skvad...@gmail.com wrote: YY prefix comes from yacc-family parser generators. re2c is often used in pair with these parser generators, so there's a possibility of name collisions. Not only yacc, but also scanners like f/lex follows that same tradition and name variables YYVAR. I have never seen a name-space” conflict with bison/yacc/byacc and re2c. I understand why you want to have a separate “name-space” for re2c variables, but it is not broken now. However, changing the naming scheme _will_ break code and require rewrites or configure changes. The argument that there's a possibility of name collisions” is rather thin for breaking an “API” interface IMHO. Any old project using re2c will break on systems with the new re2c. So if you absolutely must do this change it is better to make a --new-names” switch instead so the default is backward compatibility. -- 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
