February 18, 2009
Andrei Alexandrescu wrote:
> dsimcha wrote:
>> == Quote from dsimcha (dsimcha@yahoo.com)'s article
>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
>>> article
>>>> I'm quite unhappy with the API of std.regexp. It's a chaotic design
>>>> that
>>>> provides a hodgepodge of functionality and tries to use as many
>>>> synonyms
>>>> of "to find" in the dictionary (e.g. search, match). I could swear
>>>> Walter never really cared for using regexps, and that is felt
>>>> throughout
>>>> the design: it fills the bullet point but it's asinine to use.
>>>> Besides std.regexp only works with (narrow) strings and we want it to
>>>> work on streams of all widths and structures. One pet complaint I have
>>>> is that std.regexp puts a class around it all as if everybody's
>>>> favorite
>>>> pastime would be to inherit Regexp and override some random function
>>>> in it.
>>>> In the upcoming releases of D 2.0 there will be rather dramatic
>>>> breaking
>>>> changes of phobos. I just wanted to ask whether y'all could stomach yet
>>>> another rewritten API or you'd rather use std.regexp as it is for the
>>>> time being.
>>>> Andrei
>>> As I've said before, anyone who can't stomach breaking changes w/o
>>> complaining has
>>> no business using D2 at this point. I'd rather deal with the
>>> aggravation of stuff
>>> breaking in the sort run to have a nice language and libraries to go
>>> with it in
>>> the long run.
>>> This whole concept of ranges as you've created them seems to have
>>> achieved the the
>>> holy grail of both making simple things simple and complex things
>>> possible, where
>>> "complex things" includes needing code to be efficient, so I can see
>>> your reason
>>> for wanting to redo all kinds of stuff in them. This compares
>>> favorably to C++
>>> STL iterators, which are very flexible and efficient but a huge PITA
>>> to use for
>>> simple things because the syntax is so low-level and ugly, and to the
>>> D1/early D2
>>> way, which gives beautiful, simple notation for the more common cases
>>> (basic
>>> dynamic arrays), at the expense of flexiblity when doing more
>>> complicated things
>>> like streams, chaining, strides, etc.
>>
>> BTW, can you elaborate on how arrays, both builtin and any library
>> versions, will
>> work when everything is finalized?
>
> Well finalizations hinges not only on me but on Walter (bugfixes and a
> couple of new features) and on all of you with the continuous stream of
> great suggestions and ideas. Again, without being able to experiment
> much I don't have a clear idea on how arrays/containers should at best
> look like. The interesting challenge is accommodating good, precise
> semantics with the freedom given by garbage collection. Here are some
> highlights:
>
> * Today's T[] will be firmly an incarnation of the random-access range
> concept, to the extent that all code expecting a random-access range can
> always be passed a T[] without any impedance adaptation.
>
> * $ will be generalized to mean "end of range" even for infinite ranges.
>
> * We don't have a solution to address the perils of extending a slice by
> using ~=. We're considering adding the type T[new], but I'm not sure we
> should take the hit of a new built-in type constructor, particularly
> when it's implementable as a library.
>
> * Fixed-size arrays will in all likelihood be value types. We couldn't
> find any other semantics that works.
>
> * Containers will have value semantics.
>
> * "Resources come and go; memory is forever" is the likely default in D
> resource management. This means that destroying e.g. an array of File
> objects will close the underlying files, but will not deallocate the
> memory allocated for them. In essence, destroying values means calling
> the destructor but not delete-ing them (unless of course they're on the
> stack). This approach has a number of disadvantages, but plenty of
> advantages that compensate them in most applications.
>
> * std.matrix will define memory layouts for a variety of popular
> libraries and also the common means to iterate said layouts.
>
> * For those who want containers with reference semantics, they can use
> the type Class!(T) for any value type T. That includes built-in value
> types (int, float...) and whichever value containers we define. It's
> unclear to me whether this is enough to satisfy those in need for
> complex container hierarchies.
>
>
> Andrei

I've got a few questions about the proposed container value semantics:

a) I'd like to be able to do for instance:
List lst = new LinkedList();
i.e use interfaces everywhere and especially in functions so that I can switch implementations easily when the need arises. In the above I can choose to use singly or doubly linked list without making changes throughout the code by using the List interface. Will this be possible and how? is D going to get proper struct interfaces?

b) it is sometimes useful to have a container!(Base) store references to instances of derived classes, a caconical example of this is a container of Widget class in a UI framework, where you can, for instance iterate over the container and paint all the different kinds of widgets on the screen by calling the virtual paint method of the base class. How can this be implemented with your proposed Class template?

-- Yigal



February 18, 2009
Andrei Alexandrescu wrote:
> dsimcha wrote:
>> == Quote from dsimcha (dsimcha@yahoo.com)'s article
>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
>>> article
>>>> I'm quite unhappy with the API of std.regexp. It's a chaotic design
>>>> that
>>>> provides a hodgepodge of functionality and tries to use as many
>>>> synonyms
>>>> of "to find" in the dictionary (e.g. search, match). I could swear
>>>> Walter never really cared for using regexps, and that is felt
>>>> throughout
>>>> the design: it fills the bullet point but it's asinine to use.
>>>> Besides std.regexp only works with (narrow) strings and we want it to
>>>> work on streams of all widths and structures. One pet complaint I have
>>>> is that std.regexp puts a class around it all as if everybody's
>>>> favorite
>>>> pastime would be to inherit Regexp and override some random function
>>>> in it.
>>>> In the upcoming releases of D 2.0 there will be rather dramatic
>>>> breaking
>>>> changes of phobos. I just wanted to ask whether y'all could stomach yet
>>>> another rewritten API or you'd rather use std.regexp as it is for the
>>>> time being.
>>>> Andrei
>>> As I've said before, anyone who can't stomach breaking changes w/o
>>> complaining has
>>> no business using D2 at this point. I'd rather deal with the
>>> aggravation of stuff
>>> breaking in the sort run to have a nice language and libraries to go
>>> with it in
>>> the long run.
>>> This whole concept of ranges as you've created them seems to have
>>> achieved the the
>>> holy grail of both making simple things simple and complex things
>>> possible, where
>>> "complex things" includes needing code to be efficient, so I can see
>>> your reason
>>> for wanting to redo all kinds of stuff in them. This compares
>>> favorably to C++
>>> STL iterators, which are very flexible and efficient but a huge PITA
>>> to use for
>>> simple things because the syntax is so low-level and ugly, and to the
>>> D1/early D2
>>> way, which gives beautiful, simple notation for the more common cases
>>> (basic
>>> dynamic arrays), at the expense of flexiblity when doing more
>>> complicated things
>>> like streams, chaining, strides, etc.
>>
>> BTW, can you elaborate on how arrays, both builtin and any library
>> versions, will
>> work when everything is finalized?
>
> Well finalizations hinges not only on me but on Walter (bugfixes and a
> couple of new features) and on all of you with the continuous stream of
> great suggestions and ideas. Again, without being able to experiment
> much I don't have a clear idea on how arrays/containers should at best
> look like. The interesting challenge is accommodating good, precise
> semantics with the freedom given by garbage collection. Here are some
> highlights:
>
> * Today's T[] will be firmly an incarnation of the random-access range
> concept, to the extent that all code expecting a random-access range can
> always be passed a T[] without any impedance adaptation.
>
> * $ will be generalized to mean "end of range" even for infinite ranges.
>
> * We don't have a solution to address the perils of extending a slice by
> using ~=. We're considering adding the type T[new], but I'm not sure we
> should take the hit of a new built-in type constructor, particularly
> when it's implementable as a library.
>
> * Fixed-size arrays will in all likelihood be value types. We couldn't
> find any other semantics that works.
>
> * Containers will have value semantics.
>
> * "Resources come and go; memory is forever" is the likely default in D
> resource management. This means that destroying e.g. an array of File
> objects will close the underlying files, but will not deallocate the
> memory allocated for them. In essence, destroying values means calling
> the destructor but not delete-ing them (unless of course they're on the
> stack). This approach has a number of disadvantages, but plenty of
> advantages that compensate them in most applications.
>
> * std.matrix will define memory layouts for a variety of popular
> libraries and also the common means to iterate said layouts.
>
> * For those who want containers with reference semantics, they can use
> the type Class!(T) for any value type T. That includes built-in value
> types (int, float...) and whichever value containers we define. It's
> unclear to me whether this is enough to satisfy those in need for
> complex container hierarchies.
>
>
> Andrei

Another question regarding the container design - have you considered mutable containers vs. functional style imutable containers? does it make sense to provide both options?
February 19, 2009
Andrei Alexandrescu, el 17 de febrero a las 13:56 me escribiste:
> >Btw, I've got no problems with you breaking the API of 2.0 either.
> >Though you might consider moving the current implementation to
> >std.deprecated.regex and leaving it there for a year with a
> >pragma(msg, "This module is deprecated").
> >That way making a quick fix to broken code is just a matter of
> >inserting ".deprecated" into your import statements.
> 
> 
> I was thinking of moving older stuff to etc, is that ok?

What's the rationale for "etc"? Why not "deprecated", o something shorter like "old", or "d1" (this last one could be good for future deprecated libraries, like when D3 is available there probably be a "d2" too).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hey you, don't tell me there's no hope at all
Together we stand, divided we fall.
February 19, 2009
Leandro Lucarella wrote:
> Andrei Alexandrescu, el 17 de febrero a las 13:56 me escribiste:
>>> Btw, I've got no problems with you breaking the API of 2.0 either.
>>> Though you might consider moving the current implementation to
>>> std.deprecated.regex and leaving it there for a year with a
>>> pragma(msg, "This module is deprecated").
>>> That way making a quick fix to broken code is just a matter of
>>> inserting ".deprecated" into your import statements.
>>
>> I was thinking of moving older stuff to etc, is that ok?
> 
> What's the rationale for "etc"? Why not "deprecated", o something shorter
> like "old", or "d1" (this last one could be good for future deprecated
> libraries, like when D3 is available there probably be a "d2" too).
> 

In the words of George Costanza: "Because it's there!"

Andrei
February 19, 2009
Andrei Alexandrescu wrote:
> Leandro Lucarella wrote:
>> Andrei Alexandrescu, el 17 de febrero a las 13:56 me escribiste:
>>>> Btw, I've got no problems with you breaking the API of 2.0 either.
>>>> Though you might consider moving the current implementation to
>>>> std.deprecated.regex and leaving it there for a year with a
>>>> pragma(msg, "This module is deprecated").
>>>> That way making a quick fix to broken code is just a matter of
>>>> inserting ".deprecated" into your import statements.
>>>
>>> I was thinking of moving older stuff to etc, is that ok?
>>
>> What's the rationale for "etc"? Why not "deprecated", o something shorter
>> like "old", or "d1" (this last one could be good for future deprecated
>> libraries, like when D3 is available there probably be a "d2" too).
>>
> 
> In the words of George Costanza: "Because it's there!"
> 
> Andrei

Shouldn't that be George Mallory?
February 19, 2009
Ellery Newcomer wrote:
> Andrei Alexandrescu wrote:
>> Leandro Lucarella wrote:
>>> Andrei Alexandrescu, el 17 de febrero a las 13:56 me escribiste:
>>>>> Btw, I've got no problems with you breaking the API of 2.0 either.
>>>>> Though you might consider moving the current implementation to
>>>>> std.deprecated.regex and leaving it there for a year with a
>>>>> pragma(msg, "This module is deprecated").
>>>>> That way making a quick fix to broken code is just a matter of
>>>>> inserting ".deprecated" into your import statements.
>>>>
>>>> I was thinking of moving older stuff to etc, is that ok?
>>>
>>> What's the rationale for "etc"? Why not "deprecated", o something shorter
>>> like "old", or "d1" (this last one could be good for future deprecated
>>> libraries, like when D3 is available there probably be a "d2" too).
>>>
>>
>> In the words of George Costanza: "Because it's there!"
>>
>> Andrei
> 
> Shouldn't that be George Mallory?

No, he said "because it is there". George said "because it's there":

http://www.classictvquotes.com/quotes/characters/george-costanza/page_14.html

George: So, she fell, and then she started screaming, "My back! My back!" So, I picked her up and took her to the hospital.
Elaine: How is she?
George: She's in traction.
Elaine: Okay, I'm sorry.
George: It's not funny, Elaine.
Elaine: I know. I'm sorry. I'm serious.
George: Her back went out. She's gotta be there for a couple of days. All she said on the way over in the car was, "Why, George, why?!" I said, "Because it's there!"


Andrei
February 20, 2009
Bill Baxter wrote:
> Maybe "design" is too strong a word.  Most Phobos modules seem to have
> been put together rather hastily in order to fill a pressing need.
> Often *something* is better than nothing at all, even if the something
> is not so great.

std.regexp evolved out of the ECMAscript regex functions - they have the same names and functionality. Layered on top of that was ruby-like names and functionality. It's a good (bad?) example of an api evolving without sacrificing backwards compatibility.
February 20, 2009
Walter Bright wrote:
> Bill Baxter wrote:
>> Maybe "design" is too strong a word.  Most Phobos modules seem to have
>> been put together rather hastily in order to fill a pressing need.
>> Often *something* is better than nothing at all, even if the something
>> is not so great.
> 
> std.regexp evolved out of the ECMAscript regex functions - they have the same names and functionality. Layered on top of that was ruby-like names and functionality. It's a good (bad?) example of an api evolving without sacrificing backwards compatibility.

s/good \(bad\?\)/REALLY BAD/


Andrei
February 20, 2009
On Fri, 20 Feb 2009 16:35:54 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Walter Bright wrote:
>> Bill Baxter wrote:
>>> Maybe "design" is too strong a word.  Most Phobos modules seem to have
>>> been put together rather hastily in order to fill a pressing need.
>>> Often *something* is better than nothing at all, even if the something
>>> is not so great.
>>  std.regexp evolved out of the ECMAscript regex functions - they have the same names and functionality. Layered on top of that was ruby-like names and functionality. It's a good (bad?) example of an api evolving without sacrificing backwards compatibility.
>
> s/good \(bad\?\)/REALLY BAD/
>
>
> Andrei

Backward compatibility is almost always a bad thing.
Look what's happened to C++ and OpenGL.
February 20, 2009
Denis Koroskin wrote:
> On Fri, 20 Feb 2009 16:35:54 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Walter Bright wrote:
>>> Bill Baxter wrote:
>>>> Maybe "design" is too strong a word.  Most Phobos modules seem to have
>>>> been put together rather hastily in order to fill a pressing need.
>>>> Often *something* is better than nothing at all, even if the something
>>>> is not so great.
>>>  std.regexp evolved out of the ECMAscript regex functions - they have the same names and functionality. Layered on top of that was ruby-like names and functionality. It's a good (bad?) example of an api evolving without sacrificing backwards compatibility.
>>
>> s/good \(bad\?\)/REALLY BAD/
>>
>>
>> Andrei
> 
> Backward compatibility is almost always a bad thing.
> Look what's happened to C++ and OpenGL.

In this case it's even worse, as I don't think anyone expects to paste their Ruby code and compile it with dmd.

Andrei