Re: What will be the next MAJOR programming language for commercial use?


"Jon Harrop" <usenet@xxxxxxxxxxxxxx> wrote in message
news:42ec1aea$0$14694$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Walter wrote:
> >> >> Safety
> > Yes.
> Does D support pointer arithmetic?

Yes.

> If so, what happens when an invalid pointer is dereferenced?

You get a hardware generated exception. You can argue that this makes D
inherently "unsafe". I would argue that "safety" is a continuum between more
safe and less safe, and there is no obvious dividing line between the two. I
will also argue that D has many characteristics that make the need for
pointers much less than in, say, C, so one rarely has to deal with pointers.
Also, D has Contract Programming which can help a great deal.

> >> >> Closures
> > Yes. (dynamic closures)
> I'm not sure what a "dynamic" closure is. Your web page states "The stack
> variables, however, are not valid once the function declaring them has
> exited, in the same manner that pointers to stack variables are not valid
> upon exit from a function".

That's exactly what a dynamic closure is. A static closure would "capture"
the local variables so they survive the function exit.

> This is a very low-level notion of a closure
> that I've never come across.

It's very useful, and much more efficient than a static closure, although
less functional.

> In D, can you partially apply a function? For example, the following OCaml
> defines an "add" function and then an "incr" function in terms of "add"
and
> finally increments 3 to get 4

I don't get it.

> >> >> Higher-order functions
> > Don't know what that means.
> A higher-order function is a function that accepts a function as an
> argument. The "map" function is the pedagogical example. It accepts a
> function "f" and a list "[a; b; c; ...]" and returns the list "[f(a);
f(b);
> f(c); ...]". I think D will do this ok but you probably have to write
> function-pointer-style type declarations?

Since D supports function literals, you can do this directly.


> >> >> Type inference
> > Not sure what you mean.
> With type inference, types are inferred by the compiler and do not have to
> be written explicitly by the programmer. For example, the following OCaml
> function increments the given integer but the type "int" is not written
> explicitly in the function:
>
> # let succ n = 1 + n;;
> val succ : int -> int = <fun>
>
> This is the main reason for OCaml's brevity.

You can do this in D (a bit clumsilly) using the typeof construct. Making
this work more naturally is an often asked for feature, and will get added.


> > > >> Variants
> >
> > Can be done using a user defined class.
>
> That's a no. :-)
>
> Variants can be considered as such a common OO pattern that it is worth
> having syntactic sugar to support them.

I've made just this argument in support of D's builtin arrays, associative
arrays, complex numbers, etc. I'm not sold, though, on doing it for
variants.

> >> >> Functors
> >
> > Yes.
>
> There may be another discrepancy here. In ML, functors are module-level
> functions that map modules onto modules.

In C++ and D, a functor is essentially a function pointer that also contains
persistent state. It is implemented by overloading the () operator for a
class.

> >> >> Native lists
> > Can be done simply with a user defined class.
> Again, the result will require much more code. Consider this function
which
> dices a list into a list of 3-element lists:

You'd probably do this with dynamic arrays in D.

> That was the page I was reading. It is great for someone coming from a C++
> background (which is most readers, after all) but it lists very few
> features found in other state-of-the-art programming languages. I think
> that would be very interesting, although it wouldn't show D in such a
> positive light.

D isn't a functional programming language, and it would be hard to create
such a table and have it have any real meaning. Comparison tables only work
when languages are reasonably similar. One problem, for example, is that
terms like "functor" have very different meanings in very different
languages.

> I don't know anything about contract programming, although I have heard of
> it. Must contracts be verified at run-time?

Yes.

> I'll have a go and see if I can port my ray tracer.
>
> Great work on D, BTW. :-)

Thanks!

-Walter
www.digitalmars.com/d/ the D Programming Language


.

Relevant Pages

  • Re: [announcement] SYSAPI and SYSSVC for Windows
    ... That's not a bad design to create a pointer to a instance of an object. ... It's a perfectly normal C++ way of programming. ... The compiler would simply take those parameters as a string literal, ... which string literals are not. ...
    (comp.lang.ada)
  • Pointers and Teaching C++ [was Re: A little disappointed]
    ... like Java where *many* facilities such as raw pointer access / manipulation ... are removed in order to create a 'safer' language and stop programmers ... then it is probably wiser to teach programming using ... pointer access / manipulation is not a 'high level language'. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: thread specific information
    ... Some of these bugs are directly related to the aforementioned "programming techniques", so such things should always be viewed with caution. ... Heap is at best "casually" thread-specific. ... If it keeps that pointer to itself there's no reason for another thread to access it, ... Again, this effectively allocates GLOBALLY visible memory to which only one thread is granted a pointer; but there's nothing to prevent that thread from making a pointer visible to other threads, or to keep other threads from accidentally "scribbling" over the data via a random uninitialized pointer. ...
    (comp.programming.threads)
  • Re: Briatore hits out on cheating by certain teams
    ... char* s = calloc); ... spent five years lecturing on introductory programming in C++ to CS ... the compiler might even optimise away the ... promotable to any other pointer) doesn't require casting...except in C++ ...
    (rec.autos.sport.f1)
  • Re: segfault w/ block, but not file scope
    ... >>> the value of a pointer to emulate pass by reference. ... >> mean it's suddenly a different programming technique. ... > specifically as a syntactic feature of a language. ...
    (comp.lang.c)