The D Programming Language
in [C++]
|
From: Bo Persson on 25 Nov 2006 17:34 Jeffrey Yasskin wrote: > On Nov 21, 2:16 pm, Walter Bright <wal...(a)digitalmars-nospamm.com> > wrote: >> 1) Extend std::string to support UTF-8. > > This would be as misguided as extending Java strings to support > Unicode. ;) What do you propose std::string::length() would return, > the number of bytes or the number of characters? > > But both this and your argument about complex vs imaginary numbers > support putting as much as possible into the library instead of the > language. If std::string were baked into the language, we would > have a very hard time replacing it with a utf-8 string class. Since > it's part of the library, all you have to do is write functions > using a different class. Similarly, if std::complex were part of > the language, as _Complex is part of C, we'd be trapped with the > language designers' mistakes. As it is, you're free to write an > "imaginary" class that works correctly. The language even allows > you to make it interoperate with the "flawed" implementation of > std::complex and the math libraries. > > The point of moving things from the language to the library is that > language designers aren't all-knowing gods. They make mistakes, but > putting those mistakes in the library instead of the compiler allows > us, the language's users, to fix them. > Walter doesn't have that problem, as he has his own language, as well as his own compilers. :-) I, on the other hand, feel much more powerful when I have a library string (for example) where I, if absolutely necessary, can tune some operations for an empty string, or appending a one character string. Putting in an enhancement request to the compiler provider, isn't at all that convenient. Some compilers have a release cycle of several years, with a much smaller window open for requests. Also, if the system is "forced" to allow efficient library types, that can be very useful for me defining types that the compiler writer haven't found equally interesting. Someone else pointed out that returning complex values if FP registers is a good optimization, while having the compiler return all types with 1-3 floating point values in FP registers is potentially MUCH more useful. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Peter Dimov on 25 Nov 2006 17:34 Walter Bright wrote: > David Abrahams wrote: > > Walter Bright <walter(a)digitalmars-nospamm.com> writes: > > So your only reason for having these things in the D core language is > > the literal syntax? > > No. I've given a list before. Here it is again: > > 1) literals > 2) comprehensible error messages > 3) faster compilation > 4) custom syntax for it (not just literals) > 5) better code generation (like for complex, we can (and do) return them > in the FPU registers rather than like a struct) If you optimize the general case of struct { X x; Y y; }, where X and Y fit in a register, you get much better ROI. [...] -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 25 Nov 2006 18:09 Jeffrey Yasskin wrote: > On Nov 21, 2:16 pm, Walter Bright <wal...(a)digitalmars-nospamm.com> > wrote: >> 1) Extend std::string to support UTF-8. > > This would be as misguided as extending Java strings to support > Unicode. ;) What do you propose std::string::length() would return, the > number of bytes or the number of characters? Exactly. It doesn't work. std::string isn't user extensible - if a user tried it, it would break other code that used std::string. It wouldn't be standard conforming, either. > But both this and your argument about complex vs imaginary numbers > support putting as much as possible into the library instead of the > language. If std::string were baked into the language, we would have a > very hard time replacing it with a utf-8 string class. Since it's part > of the library, all you have to do is write functions using a different > class. The operative phrase here is you have to use a "different class". I.e. putting strings into the library failed to make them flexible and extensible. > Similarly, if std::complex were part of the language, as > _Complex is part of C, we'd be trapped with the language designers' > mistakes. No, you can still create a different class. Nothing at all about building complex in as a core language would *prevent* you from building a custom complex class. You would not be any worse off than you would be with C++ trying to replace the standard complex class. > As it is, you're free to write an "imaginary" class that > works correctly. The language even allows you to make it interoperate > with the "flawed" implementation of std::complex and the math > libraries. You can do the same in D by creating your own class. > The point of moving things from the language to the library is that > language designers aren't all-knowing gods. They make mistakes, but > putting those mistakes in the library instead of the compiler allows > us, the language's users, to fix them. Nothing is taken away from that by putting basic types into the core language. After all, C++ supports C core strings. Did this prevent C++ from creating std::string? Did C++'s support for core real numbers throw a monkey wrench into std::complex? Did C++'s support for C core arrays put the kibosh on std::vector? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 25 Nov 2006 18:08 Walter Bright wrote: > English is a terrible language from an academic point of view. It is, > however, a wonderful language from a practical point of view. English > has, for example, over a million words, far more than any other > language. That makes it the most expressive language. English has no > problem with freely incorporating words from other languages, apparently > to the distress of others <g>. > > It seems that anything that is easy to use for humans involves special > cases. The easier to use it is, the more special cases. That's why > nobody has come close to figuring out how to build a gui based on > simple, orthogonal rules. > > Computer languages are the same way. Nice argument, too bad it's fallacious in so many ways :o). There are too many differences for the comparison, as luring as it is, to fly. Computer languages serve different very different purposes from natural language and as such are subject to different kinds of constraints. Unless one builds a convincing argument that a parallel between computer languages and natural language has validity (the argument "computer languages are the same way" does not hold), IMHO we'll be better off if we left the analogy out of the conversation. > The ones that are based on simple, > orthogonal rules (Lisp - everything is a list, Smalltalk - everything is > an object) get mowed down by languages that special case things like > integers, much to the baffled frustration of their enthusiasts. But languages that did have special cases got mowed down too. The statement above brings no convincing evidence that special case = good and generality = bad. > Don't get me wrong. I'm not saying just load up a language with special > cases and it'll be better. It has to be the *right* special cases, very > carefully designed. If it's done right, ironically the user won't notice > the special cases at all and it'll feel perfectly natural to him. Oh, one more difference from natural language: in the PL case the special cases are decided by the language designer, while natural language is streamlined by quite a different process. > It's possible that C++ may fall into a similar trap that Lisp and > Smalltalk fell into, by adopting a principle that features should be > pushed into libraries even if that is to the detriment of usability. C++ > is willing to accept usability compromises for strings, arrays, complex > numbers, and associative arrays in order to be able to implement them as > libraries. But then C++ watches in frustration as users migrate to other > languages that don't make those compromises. Maybe that isn't the whole > reason they migrate, but I'm pretty sure it's part of it. Ionno. For example, some have migrated to Java or C#. Both languages have remarkably fewer special cases than C++. Watch out... that argument is about to fall flat on its face :o). > D isn't willing to cede usability on basic features like strings, > arrays, etc. And like English, D is very willing to adopt and adapt > features from other languages that have proven to add a lot of value to > those languages. Unlike English, D is under the control of one single person. I really think it would be great to drop that analogy. If a new language is to become successful, it better comes up not with what's good in other languages, but with some good of its own. Otherwise it will always be one step behind. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Al on 25 Nov 2006 18:06
Jeffrey Yasskin wrote: > On Nov 21, 2:16 pm, Walter Bright <wal...(a)digitalmars-nospamm.com> > wrote: >> 1) Extend std::string to support UTF-8. > > This would be as misguided as extending Java strings to support > Unicode. ;) What do you propose std::string::length() would return, the > number of bytes or the number of characters? size() should probably return num bytes. length() should probably return num chars. > But both this and your argument about complex vs imaginary numbers > support putting as much as possible into the library instead of the > language. If std::string were baked into the language, we would have a > very hard time replacing it with a utf-8 string class. Since it's part > of the library, all you have to do is write functions using a different > class. Similarly, if std::complex were part of the language, as > _Complex is part of C, we'd be trapped with the language designers' > mistakes. As it is, you're free to write an "imaginary" class that > works correctly. The language even allows you to make it interoperate > with the "flawed" implementation of std::complex and the math > libraries. While std::string is not baked in, const char * literals are, doing things like "aaaa" + "bbbb" impossible no matter how you cut it. Perhaps if the standard allowed overloading operators between two pointer types, but that would probably wreak all sorts of havoc. > > The point of moving things from the language to the library is that > language designers aren't all-knowing gods. They make mistakes, but > putting those mistakes in the library instead of the compiler allows > us, the language's users, to fix them. However, as pointed above, there is only so much the library designers can do to fix the mistakes that the all-knowing C gods made centuries ago. So now, by default, _all_ C++ users must suffer from these deficiencies. In particular, beginners who expect those things to work out of the box, and that have a hard time understanding why using the result of the aforementioned operation likely leads to a segfault. Cheers, -Al. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |