• bearophile (37/51) Nov 15 2009 I've seen this list of answers from Walter:
• bearophile (4/5) Nov 15 2009 I meat class references.
• Nick Sabalausky (3/8) Nov 15 2009 Please do, I'm curious.
• bearophile (7/8) Nov 15 2009 It's a handy syntax to define a pattern (like a regular expression, with...

bearophile <bearophileHUGS lycos.com> writes:

I've seen this list of answers from Walter:
http://lambda-the-ultimate.org/node/3680
Bullets * are from the original list. Comments in >...< are by Walter:


* has an "interpreter" (compiles and runs code on the fly)<

Adding a D interpreter with a Python-like shell to the D distributions is
possible. It will be handy if well implemented.


* can be used as a systems programming language (ie: you can write device
drivers with this stuff)

Yes, as long as you eschew stuff that uses the GC<

I'd like a compiler argument that turns all hidden usages of GC into compile
time errors (so you don't join strings by mistake, you don't use AAs, etc), and
replaces the GC with calls to aligned_malloc and aligned_free (from the C heap
but aligned to 16 bytes). If the whole program is compiled like this, the
larger GC is not present inside the binary, producing small(er) binaries.


* passing an imperative function to a higher order pure function renders the
pure code impure.

check<

I have never tested this in D!


* Soft-realtime GC

Not sure what that means, but D does have GC<

Hard-realime GC means that it can be used in programs that need microsecond
precision, so the time used by the GC is deterministic and divided in very
small bits of time. Hard-realtime is not easy to do with a GC.
Soft-realtime relaxes this requirements some, allowing for less time precision.
In most situations soft-realtime is enough, for example for video games.
The current D GC is not soft-realtime.


* NO null pointers

D has null pointers<

But the community has discussed non-null pointers by default for weeks...


* Continuations

probably not<

Surely not, unless you don't implement them :-) But those are useful only in a
certain type of programming. I can live without them. But I'd like to have
computed gotos, to create fast state machines to process biological information
(LLVM supports computed gotos already, so it's mostly a matter of adding the
syntax support to LDC).


* name spaces

Yes<


present in D (I don't miss them, so far).


* neither lazy nor eager evaluation by default, but three distinct function
calling operators. CALLER PICKS {lazy, eager, usecallersemantics}

D does have lazy and eager function parameters, but the callee picks.<

This can be a part that D will want to fix in future.
To avoid the current troubles D may require "lazy" at the calling point for
lazy arguments:
foo(lazy printf("hello"));


* easily parse binary data (see Erlang's bit syntax)

Don't see why that should be a problem with D.<

Erlang bit syntax is very handy, I have shown it time ago, if you want I can
show it again. D has nothing similar, so it's a limit of D. In D you may
implement it with a string mixin...


* compiled regular expression syntax

Regex is supported via a library.<

As in Python. But people coming from Ruby like to have a syntax for REs. I
think a syntax may be a little handy, but we can live without it.


* scalable: not declaring a module header imports a standard bunch of stuff
that makes it easy to write programs that easily do what Python, Perl, Ruby do.

Need to specifically import what you use.<

And this is good and safer.


* Module split into "public" (on top and default) and "private" section. --no
mucking about retyping all the "exported" functions

Yes.<

In the D code I've seen this isn't usually done, but it's doable.


* Haskell-style indenting

Whitespace is not significant.<

You have forgotten the Delight language :-)


* pattern matching

Not directly, but you can do similar things with the templates<

UHh... well... at best it's not nearly as handy.


Final general comment: Go language (and few other languages that people don't
use) shows that sometimes the style of a language can be seen from the features
it misses, not from the ones it has ;-)

Bye,
bearophile

bearophile <bearophileHUGS lycos.com> writes:

bearophile:

 But the community has discussed non-null pointers by default for weeks...

I meat class references.

Bye,
bearophile

"Nick Sabalausky" <a a.a> writes:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hdos8g$4i5$1 digitalmars.com...
 * easily parse binary data (see Erlang's bit syntax)

Don't see why that should be a problem with D.<

 Erlang bit syntax is very handy, I have shown it time ago, if you want I 
 can show it again. D has nothing similar, so it's a limit of D. In D you 
 may implement it with a string mixin...

Please do, I'm curious. 

bearophile <bearophileHUGS lycos.com> writes:

Nick Sabalausky:

Please do, I'm curious.<

It's a handy syntax to define a pattern (like a regular expression, with bit
sizes and more) and to define, mix, merge, pack and unpack bytes and bits from
binary data or from local variables, strings, etc. In the end it's nothing
esoteric, that's why I have said it may be possible to implement part of that
syntax with a D string mixin.

See:
http://www.erlang.org/documentation/doc-5.4.12/doc/programming_examples/bit_syntax.html

Such Erlang syntax is well known, I presume Erlang programs need to perform
often those operations.

Bye,
bearophile