www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Replacing built-in complex? What's this about?

reply bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:

- The imaginary literal notation and resulting concise notation for complex
numbers are nice ideas.  It would be sad to lose these.<

In some situations there's a third alternative: put into the language just the support for the literal syntax (and little else) and put the implementation into a module that you have to import when you actually want to use complex numbers. This strategy (when can be used) offers: - keeps the compiler less complex; - allows you to use different/better implementations of that thing; - keeps (most of) the handy syntaxes. -------------------------------- Andrei Alexandrescu:
You see, built-in associative arrays have exactly two advantages:

(b) The literal syntax is also very terse, e.g. [ "a" : 1, "b" : 2 ] vs. makeMap!("a", 1, "b", 2).< [later fixed as makeMap("a", 1, "b", 2), but just map("a", 1, "b", 2) seems better.] Also: (b2) literal syntax also has less syntax noise. (c) you don't need to put an import. (d) you don't need to remember what package.module you have to import. (e) literal syntax is open to improvements (see dict comp of Python 3).
having builtins wielding too much power is in fact a sign the language design
didn't go that well: If a built-in type has too many advantages over a
user-defined type, that only means user-defined types are robbed of that many
possibilities.<

You are missing: - Generally to create new things efficiently you need constraints too. - Too much freedom often leads to messy programs or programs too much different among different programmers. - The more freedom there is, the more time you need to understand and debug code written by other people. - If I use built-in associative arrays, I don't care if I am using Phobos or Tango. In general this means that more freedom leads to more dependences from outside things (but a true std lib may solve most of this problem). - So when you design a language you have to find a balance between flexibility and contraints. Contraints are designed by Walter, and are constant, so they are hopefully better designed than mine, and they are shared among all D programmers. CLisp is less used by Java also because it gives less limits/contraints than Java.
(b) Complex literals are rare, far between, and to be discouraged.<

Good complex literals are the same you use in mathematics, most people know them, and they don't waste space or memory or produce noise when you don't need them. So I can't see why they have to be discouraged. -------------------------- Bill Baxter:
I don't think the compiler is quite there yet, so till it is, there is an
advantage to having a built-in hash-table that can run at compile time.<

At the moment, what can the compiler do with the built-in AAs at compile time? (I think very little). Bye, bearophile
Dec 27 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
I don't think the compiler is quite there yet, so till it is, there is an
advantage to having a built-in hash-table that can run at compile time.<

At the moment, what can the compiler do with the built-in AAs at compile time? (I think very little).

I don't actually know. I was thinking the basics worked, but the point is Walter could make it work pretty easily by supplying a completely different compile-time implementation for the compile-time interpreter. Joe Librarywriter doesn't have that ability. One solution could be a version(CompileTime) to let Joe target compile time specificallly, or even a whole distinct interpreted sub-language for CT usage. But I think the best is just for the compile-time interpreter to grok all code that's grok-able. Just because that requires no extra explanation. --bb
Dec 27 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 At the moment, what can the compiler do with the built-in AAs at
 compile time? (I think very little).

I don't actually know. I was thinking the basics worked, but the point is Walter could make it work pretty easily by supplying a completely different compile-time implementation for the compile-time interpreter. Joe Librarywriter doesn't have that ability. One solution could be a version(CompileTime) to let Joe target compile time specificallly, or even a whole distinct interpreted sub-language for CT usage. But I think the best is just for the compile-time interpreter to grok all code that's grok-able. Just because that requires no extra explanation.

The interpreter does use a completely different algorithm than the runtime does for AA's.
Dec 27 2008