• bearophile (28/33) Dec 27 2008 In some situations there's a third alternative: put into the language ju...
• Bill Baxter (10/12) Dec 27 2008 I don't actually know. I was thinking the basics worked, but the
• Walter Bright (3/15) Dec 27 2008 The interpreter does use a completely different algorithm than the

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:

(a) The type name is very terse, e.g. uint[string] vs. Map!(string, uint).
(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

"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

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.