Andrei Alexandrescu Wrote:

> 
> I am sorry for the inadvertent change, it wasn't meant to change semantics of existing code. I'm not sure whether one of my unrelated 64-bit changes messed things up. You may want to file a bug report.
> 
> There are a number of good reasons for which I was compelled to split std.regex from std.regexp. I'm sure you or others would have found them just as compelling if you saw things the same way.
> 
> Phobos 1 has experimented in std.string and std.regexp with juxtaposing APIs of various languages (PHP, Ruby, Python). The reasoning was that people familiar with either of those languages could feel right at home by using APIs with similar nomenclatures and semantics. The result was some strange bedfellows in std.string such as "column" or "capwords" and an outright mess in std.regexp. The interface of std.regexp is without a doubt the worst I've ever seen, by a long shot. I have never been able to use it without poring through the documentation _several times_ and without confirming to myself via a small test case that I'm doing the right thing.
> 
> The simplest problem is this: std.regexp uses the words "exec", "find", "match", "search", and "test" - all to mean regular expression matching. There is absolutely no logic to how meanings are ascribed to words, and there is absolutely no recourse than rote memorization of various arbitrary decisions.
> 
> The resulting FrankenAPI is likely familiar to anyone except those who've actually spent time learning it, in spite of it trying to be familiar to anyone.
> 
> So I spawned std.regex in an attempt to sanitize the API (I made minor, if any, changes to the engine; I am in fact having significant trouble maintaining it). The advantages of std.regex are:
> 
> * No more class definition. Nobody is supposed to inherit RegExp anyway so it's useless to brand the object as a class.
> 
> * Engine is separated from matches, which means that engines can be memoized for efficiency. Currently regex() only memoizes the last engine.
> 
> * The new engine works with any character size.
> 
> * Simpler API: create a regex, call match() against that regex and a string, look at the resulting RegexMatch object.
> 
> If this all annoys you more than the old API, I will need to disagree. If you have suggestions on how std.regex can be improved, I'm all ears.
> 
> 
> Andrei

Andrei,

Maybe it is time that the structure of the standard library became more generalized. At the moment we have std... and core...

Perhaps we need another branch in the hierarchy, like ranges... Then there could be a std.range module that was the gateway into ranges... The library could then expand in an orderly fashion, with a wider range of users becoming responsible for the maintenance of of different branches against changes in the language, not against changes in fashion.

Then you could have ranges.regex, that suits you, and the people who were happy with the status quo, could continue to use std.regexp, which should continue to behave like it did in DMD2.029 or whatever it was when I wrote my 'legacy' code.

The current system, where modules of the library can get arbitrarily deprecated and at some point removed because they are unfashionable, is very unfriendly.

I recognize that you are young, hyper-intelligent, and motivated toward fame. But there are other users, like me, who are older, but not senile, and have more conservative attitudes, including the desire to use code they wrote in the past at some point in the future.

Steve

On Tue, 16 Nov 2010 13:16:13 -0500, Steve Teale <steve.teale@britseyeview.com> wrote:
>
> Andrei,
>
> Maybe it is time that the structure of the standard library became more generalized. At the moment we have std... and core...
>
> Perhaps we need another branch in the hierarchy, like ranges... Then there could be a std.range module that was the gateway into ranges... The library could then expand in an orderly fashion, with a wider range of users becoming responsible for the maintenance of of different branches against changes in the language, not against changes in fashion.
>
> Then you could have ranges.regex, that suits you, and the people who were happy with the status quo, could continue to use std.regexp, which should continue to behave like it did in DMD2.029 or whatever it was when I wrote my 'legacy' code.
>
> The current system, where modules of the library can get arbitrarily deprecated and at some point removed because they are unfashionable, is very unfriendly.
>
> I recognize that you are young, hyper-intelligent, and motivated toward fame. But there are other users, like me, who are older, but not senile, and have more conservative attitudes, including the desire to use code they wrote in the past at some point in the future.

The standard library should not have something to please everyone.  If there is 5 different styles to do the same thing, it will be a failure.

Can you just copy std.regex from 2.029 and compile it in your project?  I.e. instead of phobos adding range branch for the new range style, you add branch Teale for your style and copy what you like in there.  Then you have what you want (may take a little effort on your part, but then you control the results).

Also, 2.029 is still available via download, you can still use it.

-Steve

Steven Schveighoffer Wrote:

> On Tue, 16 Nov 2010 13:16:13 -0500, Steve Teale <steve.teale@britseyeview.com> wrote:
> >
> > Andrei,
> >
> > Maybe it is time that the structure of the standard library became more generalized. At the moment we have std... and core...
> >
> > Perhaps we need another branch in the hierarchy, like ranges... Then there could be a std.range module that was the gateway into ranges... The library could then expand in an orderly fashion, with a wider range of users becoming responsible for the maintenance of of different branches against changes in the language, not against changes in fashion.
> >
> > Then you could have ranges.regex, that suits you, and the people who were happy with the status quo, could continue to use std.regexp, which should continue to behave like it did in DMD2.029 or whatever it was when I wrote my 'legacy' code.
> >
> > The current system, where modules of the library can get arbitrarily deprecated and at some point removed because they are unfashionable, is very unfriendly.
> >
> > I recognize that you are young, hyper-intelligent, and motivated toward fame. But there are other users, like me, who are older, but not senile, and have more conservative attitudes, including the desire to use code they wrote in the past at some point in the future.
> 
> The standard library should not have something to please everyone.  If there is 5 different styles to do the same thing, it will be a failure.
> 
> Can you just copy std.regex from 2.029 and compile it in your project? I.e. instead of phobos adding range branch for the new range style, you add branch Teale for your style and copy what you like in there.  Then you have what you want (may take a little effort on your part, but then you control the results).
> 
> Also, 2.029 is still available via download, you can still use it.
> 
> -Steve

Yes Steve, of course I can, but other much more popular languages like for instance PHP seem to do OK with the suit-everyone style.

I am just upset that code I put a lot of effort into gets broken because somebody else does not like the style of the library.

Which should be preserved - style, or substance?

Steve

On 11/16/2010 01:30 PM, Steven Schveighoffer wrote:
> On Tue, 16 Nov 2010 13:16:13 -0500, Steve Teale
> <steve.teale@britseyeview.com> wrote:
>>
>> Andrei,
>>
>> Maybe it is time that the structure of the standard library became
>> more generalized. At the moment we have std... and core...
>>
>> Perhaps we need another branch in the hierarchy, like ranges... Then
>> there could be a std.range module that was the gateway into ranges...
>> The library could then expand in an orderly fashion, with a wider
>> range of users becoming responsible for the maintenance of of
>> different branches against changes in the language, not against
>> changes in fashion.
>>
>> Then you could have ranges.regex, that suits you, and the people who
>> were happy with the status quo, could continue to use std.regexp,
>> which should continue to behave like it did in DMD2.029 or whatever it
>> was when I wrote my 'legacy' code.
>>
>> The current system, where modules of the library can get arbitrarily
>> deprecated and at some point removed because they are unfashionable,
>> is very unfriendly.
>>
>> I recognize that you are young, hyper-intelligent, and motivated
>> toward fame. But there are other users, like me, who are older, but
>> not senile, and have more conservative attitudes, including the desire
>> to use code they wrote in the past at some point in the future.
>
> The standard library should not have something to please everyone. If
> there is 5 different styles to do the same thing, it will be a failure.
>
> Can you just copy std.regex from 2.029 and compile it in your project?
> I.e. instead of phobos adding range branch for the new range style, you
> add branch Teale for your style and copy what you like in there. Then
> you have what you want (may take a little effort on your part, but then
> you control the results).
>
> Also, 2.029 is still available via download, you can still use it.
>
> -Steve

This actually sounds interesting.  If I'm understanding things right, std.range.* would provide a range interface to specific libraries, such as regex.  So, in theory, there could be different interfaces to the same functionality.  E.g. std.range.regex, std.oo.regex, and std.proc.regex for a range interface, a OO interface, or a procedural interface.  Underneath, you could have the same core functionality, but people can access it in the way they feel most comfortable or that better fits the design of the program being written.  As new paradigms are invented, they can be added as well and be based on the existing interfaces.

Is this something we want to do?  Don't know.  I don't even know how feasible it is.  However, I do like the concept and if the goal is to make the language as friendly as possible, perhaps it should be looked into.  There's the chance that it will cause some confusion, but how much will actually occur?

The biggest issue I see is having certain libraries that don't fit well into all of the different paradigms.  E.g. a date library can have a nice OO interface and a nice procedural interface, but it doesn't make much sense to have a range interface.

Anyway, food for thought.

Casey

On Tue, 16 Nov 2010 13:46:48 -0500, Steve Teale <steve.teale@britseyeview.com> wrote:

> Steven Schveighoffer Wrote:
>
>> On Tue, 16 Nov 2010 13:16:13 -0500, Steve Teale
>> <steve.teale@britseyeview.com> wrote:
>> >
>> > Andrei,
>> >
>> > Maybe it is time that the structure of the standard library became  
>> more
>> > generalized. At the moment we have std... and core...
>> >
>> > Perhaps we need another branch in the hierarchy, like ranges... Then
>> > there could be a std.range module that was the gateway into ranges...
>> > The library could then expand in an orderly fashion, with a wider  
>> range
>> > of users becoming responsible for the maintenance of of different
>> > branches against changes in the language, not against changes in  
>> fashion.
>> >
>> > Then you could have ranges.regex, that suits you, and the people who
>> > were happy with the status quo, could continue to use std.regexp,  
>> which
>> > should continue to behave like it did in DMD2.029 or whatever it was
>> > when I wrote my 'legacy' code.
>> >
>> > The current system, where modules of the library can get arbitrarily
>> > deprecated and at some point removed because they are unfashionable,  
>> is
>> > very unfriendly.
>> >
>> > I recognize that you are young, hyper-intelligent, and motivated  
>> toward
>> > fame. But there are other users, like me, who are older, but not  
>> senile,
>> > and have more conservative attitudes, including the desire to use code
>> > they wrote in the past at some point in the future.
>>
>> The standard library should not have something to please everyone.  If
>> there is 5 different styles to do the same thing, it will be a failure.
>>
>> Can you just copy std.regex from 2.029 and compile it in your project?
>> I.e. instead of phobos adding range branch for the new range style, you
>> add branch Teale for your style and copy what you like in there.  Then you
>> have what you want (may take a little effort on your part, but then you
>> control the results).
>>
>> Also, 2.029 is still available via download, you can still use it.
>>
>> -Steve
>
> Yes Steve, of course I can, but other much more popular languages like for instance PHP seem to do OK with the suit-everyone style.

I don't object to having multiple styles to do things, I even maintain a library (dcollections) that is not even close to the style of std.container.  I just object to everything being included in the standard library.  The standard library should do things one way, and if you want something different, use an add-on library.

I'm guessing you are referring to php's pcre vs posix regex?  I think posix is marked as deprecated...

> I am just upset that code I put a lot of effort into gets broken because somebody else does not like the style of the library.

Well, the library isn't finished.  As much as I understand your pain, I also don't think phobos should be write-only.  We should not be stuck with mistakes or designs of the past until we have stated the library is released, and then we can deal with backwards compatibility in a reasonable way.  Until then, you shouldn't expect everything to be set in stone.  Sorry if this is confusing or annoying.

That being said, if std.regexp is broken, I don't think it was intentional.  In fact, in the bug report, someone mentions a one-line fix, does that solve your problem?  AFAIK, regexp is not even deprecated yet, which means it should be supported.  I think Andrei said as much.

> Which should be preserved - style, or substance?

substance.  AFAIK, substance is preserved, or am I misunderstanding you?

-Steve

On 11/16/10 10:16 AM, Steve Teale wrote:
> Andrei Alexandrescu Wrote:
>
>>
>> I am sorry for the inadvertent change, it wasn't meant to change
>> semantics of existing code. I'm not sure whether one of my unrelated
>> 64-bit changes messed things up. You may want to file a bug report.
>>
>> There are a number of good reasons for which I was compelled to split
>> std.regex from std.regexp. I'm sure you or others would have found them
>> just as compelling if you saw things the same way.
>>
>> Phobos 1 has experimented in std.string and std.regexp with juxtaposing
>> APIs of various languages (PHP, Ruby, Python). The reasoning was that
>> people familiar with either of those languages could feel right at home
>> by using APIs with similar nomenclatures and semantics. The result was
>> some strange bedfellows in std.string such as "column" or "capwords" and
>> an outright mess in std.regexp. The interface of std.regexp is without a
>> doubt the worst I've ever seen, by a long shot. I have never been able
>> to use it without poring through the documentation _several times_ and
>> without confirming to myself via a small test case that I'm doing the
>> right thing.
>>
>> The simplest problem is this: std.regexp uses the words "exec", "find",
>> "match", "search", and "test" - all to mean regular expression matching.
>> There is absolutely no logic to how meanings are ascribed to words, and
>> there is absolutely no recourse than rote memorization of various
>> arbitrary decisions.
>>
>> The resulting FrankenAPI is likely familiar to anyone except those
>> who've actually spent time learning it, in spite of it trying to be
>> familiar to anyone.
>>
>> So I spawned std.regex in an attempt to sanitize the API (I made minor,
>> if any, changes to the engine; I am in fact having significant trouble
>> maintaining it). The advantages of std.regex are:
>>
>> * No more class definition. Nobody is supposed to inherit RegExp anyway
>> so it's useless to brand the object as a class.
>>
>> * Engine is separated from matches, which means that engines can be
>> memoized for efficiency. Currently regex() only memoizes the last engine.
>>
>> * The new engine works with any character size.
>>
>> * Simpler API: create a regex, call match() against that regex and a
>> string, look at the resulting RegexMatch object.
>>
>> If this all annoys you more than the old API, I will need to disagree.
>> If you have suggestions on how std.regex can be improved, I'm all ears.
>>
>>
>> Andrei
>
> Andrei,
>
> Maybe it is time that the structure of the standard library became
> more generalized. At the moment we have std... and core...
>
> Perhaps we need another branch in the hierarchy, like ranges... Then
> there could be a std.range module that was the gateway into ranges...
> The library could then expand in an orderly fashion, with a wider
> range of users becoming responsible for the maintenance of of
> different branches against changes in the language, not against
> changes in fashion.
>
> Then you could have ranges.regex, that suits you, and the people who
> were happy with the status quo, could continue to use std.regexp,
> which should continue to behave like it did in DMD2.029 or whatever
> it was when I wrote my 'legacy' code.

I think that's not a good design. Ranges are a cross-cutting abstraction. One wouldn't put all code using exception under std.exceptions or code using floating point under std.floating_point. Better, ranges, exceptions, or floating point should be used wherever it makes sense to use them.

> The current system, where modules of the library can get arbitrarily
> deprecated and at some point removed because they are unfashionable,
> is very unfriendly.

I agree we need to have a rather long deprecation schedule. Fashionable has, however, little to do with the rationale for deprecation. You may want to tune to the Phobos developers' mailing list for more details.

> I recognize that you are young, hyper-intelligent, and motivated
> toward fame.

I have enumerated a list of technical reasons for which std.regexp is inadequate, followed by a list of improvements brought about by std.regex. Ranges are nowhere on that list, nor is being fashionable. It's all good old design stuff that I'm sure you have down better than me: make an API small and simple, separate concerns (engine/matches), use the right tool for the job (struct not class), generalize within reason (character width).

Would have been great to have a discussion along those lines. Instead, I see you chose to ignore all technical arguments and go with a presupposition, no matter how assuming and stereotypical.

> But there are other users, like me, who are older, but not senile,
> and have more conservative attitudes, including the desire to use
> code they wrote in the past at some point in the future.

Backward compatibility is indeed important, and again we need to have a long deprecation schedule. At the same time, I think there are much more many users in D's future than in its past, and I cannot inflict std.regexp on them.


Andrei

Steven Schveighoffer Wrote:

>> 
> I'm guessing you are referring to php's pcre vs posix regex?  I think posix is marked as deprecated...
> 
Steve,

No. I just meant that the library that comes with PHP seems happy to provide different ways of doing the same thing, as in for example, CURL, DOMDocument, and standard file operation wrappers.

I've been following D on and off for about seven or eight years now, so I don't subscribe too much to the 'when it's finished' argument. By now, it needs to work for real projects.

But I've had my gripe - I'll shut up for now.

Steve

On Tuesday, November 16, 2010 10:30:03 Steven Schveighoffer wrote:
> The standard library should not have something to please everyone.  If there is 5 different styles to do the same thing, it will be a failure.

Agreed. Ideally, the standard library would be very uniform in approach. That makes it easier to learn and use. If it's schizophrenic about it's approach - especially if it has multiple ways of doing everything - then it's going to be much harder to learn and use. Everyone would be asking why you'd choose one way over another and what the differences between them are. It would just cause confusion.

Ranges are a key element of how Phobos does things in D2. The truth of the matter is that if you want to effectively use Phobos, you're going to have to use ranges. If ranges aren't appropriate for a particular module or problem, then they shouldn't be used, but Phobos is generally being built around using them, and the more of Phobos which functions in essentially the same way, the easier it will be to understand, learn, and use.

The old code is indeed available for modules which are going to be deprecated/removed, and the license is usually Boost, so you're pretty free to do what you want with it if you prefer it. And there's nothing wrong with creating your own libraries if you'd prefer. Plenty of folks have done that in the past.

The standard library needs to be fairly uniform in approach, however, and some of the current modules are older and don't follow that approach or have licensing or design issues which were not addressed in the past. Once all of those modules have been updated, replaced, or removed, Phobos will be more uniform and its parts will interact better. And over time, it's unlikely that modules will continue to be deprecated like that. It's happening now because D2 Phobos is still fairly early in its evolution.

- Jonathan M Davis

On 11/16/10 10:46 AM, Steve Teale wrote:
> Steven Schveighoffer Wrote:
>
>> On Tue, 16 Nov 2010 13:16:13 -0500, Steve Teale
>> <steve.teale@britseyeview.com>  wrote:
>>>
>>> Andrei,
>>>
>>> Maybe it is time that the structure of the standard library became more
>>> generalized. At the moment we have std... and core...
>>>
>>> Perhaps we need another branch in the hierarchy, like ranges... Then
>>> there could be a std.range module that was the gateway into ranges...
>>> The library could then expand in an orderly fashion, with a wider range
>>> of users becoming responsible for the maintenance of of different
>>> branches against changes in the language, not against changes in fashion.
>>>
>>> Then you could have ranges.regex, that suits you, and the people who
>>> were happy with the status quo, could continue to use std.regexp, which
>>> should continue to behave like it did in DMD2.029 or whatever it was
>>> when I wrote my 'legacy' code.
>>>
>>> The current system, where modules of the library can get arbitrarily
>>> deprecated and at some point removed because they are unfashionable, is
>>> very unfriendly.
>>>
>>> I recognize that you are young, hyper-intelligent, and motivated toward
>>> fame. But there are other users, like me, who are older, but not senile,
>>> and have more conservative attitudes, including the desire to use code
>>> they wrote in the past at some point in the future.
>>
>> The standard library should not have something to please everyone.  If
>> there is 5 different styles to do the same thing, it will be a failure.
>>
>> Can you just copy std.regex from 2.029 and compile it in your project?
>> I.e. instead of phobos adding range branch for the new range style, you
>> add branch Teale for your style and copy what you like in there.  Then you
>> have what you want (may take a little effort on your part, but then you
>> control the results).
>>
>> Also, 2.029 is still available via download, you can still use it.
>>
>> -Steve
>
> Yes Steve, of course I can, but other much more popular languages like for instance PHP seem to do OK with the suit-everyone style.
>
> I am just upset that code I put a lot of effort into gets broken because somebody else does not like the style of the library.
>
> Which should be preserved - style, or substance?
>
> Steve

It's probably common courtesy that should be preserved. I just committed the fix prompted by Lutger (thanks).

Andrei

On Tue, 16 Nov 2010 11:24:02 -0800
Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Tuesday, November 16, 2010 10:30:03 Steven Schveighoffer wrote:
> > The standard library should not have something to please everyone.  If there is 5 different styles to do the same thing, it will be a failure.
> 
> Agreed. Ideally, the standard library would be very uniform in approach. That makes it easier to learn and use. If it's schizophrenic about it's approach - especially if it has multiple ways of doing everything - then it's going to be much harder to learn and use. Everyone would be asking why you'd choose one way over another and what the differences between them are. It would just cause confusion.
> 
> Ranges are a key element of how Phobos does things in D2. The truth of the matter is that if you want to effectively use Phobos, you're going to have to use ranges. If ranges aren't appropriate for a particular module or problem, then they shouldn't be used, but Phobos is generally being built around using them, and the more of Phobos which functions in essentially the same way, the easier it will be to understand, learn, and use.
> 
> The old code is indeed available for modules which are going to be deprecated/removed, and the license is usually Boost, so you're pretty free to do what you want with it if you prefer it. And there's nothing wrong with creating your own libraries if you'd prefer. Plenty of folks have done that in the past.
> 
> The standard library needs to be fairly uniform in approach, however, and some of the current modules are older and don't follow that approach or have licensing or design issues which were not addressed in the past. Once all of those modules have been updated, replaced, or removed, Phobos will be more uniform and its parts will interact better. And over time, it's unlikely that modules will continue to be deprecated like that. It's happening now because D2 Phobos is still fairly early in its evolution.
> 
> - Jonathan M Davis

+++


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com