http://www.gwydiondylan.org/about-dylan.phtml
"Efficiency and flexibility. Dylan can be used as a dynamic prototyping language
(like Smalltalk) or an efficient compiled language. Functional Developer,
Functional Objects' Dylan compiler, generates code as good as that of most C
compilers. Still, it provides an interactive prototyping environment like those
found in Smalltalk or Common Lisp."

http://www.gwydiondylan.org/about-dylan.phtml
This design paper is a good read.  The lesson for D is to think more about the
fast prototyping side and not view flexibility as the enemy of efficiency.
Really they are part of the same team and cover different parts of the field.

Mark

>http://www.gwydiondylan.org/about-dylan.phtml
>This design paper is a good read.

For those who skip it, the salient phrases:
"The solution, we believe, is to cleanly separate development mode from delivery
mode....Since the delivery module is not designed for easy modification, there
is no excuse for it to be slower or larger than an executable produced by C or
Fortran....Our experience in developing the Python compiler for CMU Common Lisp
gives us confidence that we can develop a Dylan compiler that will offer good
performance in development mode and excellent performance in delivery mode."

I posted about Needle earlier, but here is more info:
http://www.randomhacks.net/stories/ll2.html
"Neel Krishnaswami gave a short talk on his soon-to-be-released Needle
language. Like Dylan, Needle is an object-oriented, infix language
with roots in LISP. Unlike Dylan, Needle is a statically-typed
programming language with parameterized types (a.k.a. templates).
"Neel may have figured out some clever ways to make a Dylan-like
language statically typed without littering it with type declarations.
If you're into languages which are extremely efficient, but which are
still well-suited to rapid prototyping, this may be work to watch.
We'll see how well his type inferencer holds up once the LL2 attendees
start banging on it."

GOO is yet another Dylan-inspired language.  The website offers a number of
papers on its design and motivation.
http://www.googoogaga.org

More on Dylan's history and design, http://www.functionalobjects.com/resources/white-paper.phtml

I want D to incorporate some of the high-productivity / clean design techniques of these languages, and not derive all inspiration from, or limit all thinking to, "improved" C++.  My hope is that by exploring these languages you will gain some insights that you won't get from raw C++ experience.

Mark

In article <b2p390$2al4$1@digitaldaemon.com>, Mark Evans says...
>
>GOO is yet another Dylan-inspired language.  The website offers a number of
>papers on its design and motivation.
>http://www.googoogaga.org
>
>More on Dylan's history and design, http://www.functionalobjects.com/resources/white-paper.phtml
>
>I want D to incorporate some of the high-productivity / clean design techniques of these languages, and not derive all inspiration from, or limit all thinking to, "improved" C++.  My hope is that by exploring these languages you will gain some insights that you won't get from raw C++ experience.
>
>Mark
>
>

Lisp is dead and is as universally used as Latin.  All that remains is to find a gravesite mark a gravestone and bury it.  The control structure should have evolved beyond parenthesis blocks into something better.  Evolution is an ongoing process where only the fittest languages survive.  Only constantly evolving languages (ie fortran or java or the Cs and Ds) will continue.  But Lisp and all its progeny are marked by the same limitations.  List processing is not enough to maintain viability.

Took a random piece of code from Dylan's CVS (from the compiler):

define method identify-tail-calls-in
    (component :: <component>, home :: <fer-function-region>,
     results :: false-or(<dependency>), region :: <simple-region>)
    => ();
  block (return)
    for (assign = region.last-assign then assign.prev-op,
	 while: assign)
      for (result = results then result.dependent-next,
	   defn = assign.defines then defn.definer-next,
	   while: result | defn)
	if (~result | ~defn | defn.needs-type-check?
	      | ~definition-for?(defn, result.source-exp))
	  return();
	end;
      end;
      let expr = assign.depends-on.source-exp;
      if (instance?(expr, <known-call>))
	let func = expr.depends-on.source-exp;
	if (instance?(func, <function-literal>) & func.main-entry == home)
	  assert(home.literal == func);
	  // It's a self tail call.
	  convert-self-tail-call(component, home, expr);
	elseif (home.literal == func) // this can be removed after a while FIXME
	  // ... or better, make this the primary check.
	  error("home.literal == func, but instance?(func, <function-literal>) &
func.main-entry == home failed?");
	elseif (instance?(func, <definition-constant-leaf>))
	  let const-defn :: <abstract-method-definition> = func.const-defn;
	  let ctv = const-defn.ct-value;
	  // now, the ctv is a <ct-function>, but that does not reference the
<function-literal>
	  // so we have to go the other way.
	  let lit = home.literal;
	  let lit-ctv = lit.ct-function;
	  if (ctv == lit-ctv & ctv)
	    // It's a self tail call.
	    convert-self-tail-call(component, home, expr);
	  end if;
	elseif (instance?(func, <literal-constant>))
	  let ctv = func.value;
	  let lit = home.literal;
	  if (lit)
	    let lit-ctv = lit.ct-function;
	    if (ctv == lit-ctv & ctv)
	      // It's a self tail call.
	      compiler-warning("DID IT"); // does not seem to occur... FIXME
	      convert-self-tail-call(component, home, expr);
	    end if;
	  end if;
	end;
	return();
      end;

Need I say more? "Several features of the language could be more elegant" they say. Yeah, like it's entire syntax for starters...

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b2r71o$1819$1@digitaldaemon.com...
> Need I say more? "Several features of the language could be more elegant" they say. Yeah, like it's entire syntax for starters...

The Dylan syntax clearly is a high barrier for C/C++ programmers. I've done some more conversions of my own projects from C to D, and found it goes very quickly.

Mark Evans wrote:

> I want D to incorporate some of the high-productivity / clean design techniques of these languages, and not derive all inspiration from, or limit all thinking to, "improved" C++.  My hope is that by exploring these languages you will gain some insights that you won't get from raw C++ experience.

Got any specific examples?

One thing that I've been curious about is why interactive environments haven't caught on more than they have. It would be great to get the productivity improvements from an interactive/intepreted edit-run cycle environment and still be able to compile it to fast native code.

>Lisp is dead and is as universally used as Latin.  All that remains is to Evolution is an ongoing process where only the fittest languages survive.

Evolution has no driving intelligence, whereas computer language selection and design requires it.  So let's apply some.

The post was about Dylan, not Lisp.  The main point about Lisp is the rapid prototyping aspect.  Dead or not, Lisp has that.  The main point about Dylan was its merging of rapid prototyping with production/delivery power.  Dead or not, Dylan has that.  And that's something I'd like to see in D.  At present D is just a few rungs up from C++ on the evolutionary ladder, if you want to phrase it that way.  I'd like to kick it up several notches.

Just as schoolchildren learn virtue from dead heroes of the past, D can learn virtue from dead language heroes of the past. <g>  Or inherit their good genetic material, or something like that. <g>

Lisp is one of the single most remarkable languges on the planet.  Invented decades ago, it has shown strong, indeed very strong, survivability. I doubt any language can claim the same level of fitness.  Lisp is used regularly by tens of thousands of people even today.

If you seek direct descendants of Lisp, try Paul Graham's Arc project.  Lisp is
still spawning its young:
http://www.paulgraham.com/arc.html

Mark

Walter says...
>
>The Dylan syntax clearly is a high barrier for C/C++ programmers.

Syntax is irrelevant.  D wants to have C-ish syntax, I know, but that is beside the point.  One could invent ten different syntaxes for C yet semantically they would all be the same language, C.

What counts are the underlying paradigms and computing models; those are what interest me.  Wrap any syntax you like around them.

Mark

Syntax can make or break a language.  If it's ugly enough, people will not like it.  And it's the people that ultimately count.

Aesthetics may not be important to everyone.  But it sure is nice when you have it.

The thing about C syntax is that millions of people are used to it.  I don't care about *exact* syntax, but the general flavor of syntax makes it look more familiar.  I used to program Pascal for years;  now I can't stand to read Pascal or Modula source because it looks so alien.  Ditto for most functional languages.

Any programmer worth a damn can learn new syntax, with time.  The thing D is trying to go for is to make all the C/C++/C#/Java programmers out there feel right at home from day one.

To me I'd rather feel at home in a nicer building, minus all the spiderwebs and stains and leaky faucets that C has.  With a nice pool in the back and air conditioning and a new fridge, but still homey.  ;)  Sticking too close to C for no reason other than to be compatible would ultimately leave D as a minor improvement over C, just a dialect.  D already has enough new features to set it apart (new pool, air conditioning, new fridge), but it seems it kept a few of the cobwebs and stains and I'm not sure why.  D also does not appear to want to introduce any drastically new paradigms or computing models;  at its core it's still an imperative language and as such has all the problems that every imperative language ever made has had.  The main problem is that they don't scale well.  I don't know the solution.

Sean

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b311o9$pfh$1@digitaldaemon.com...
> Walter says...
> >
> >The Dylan syntax clearly is a high barrier for C/C++ programmers.
>
> Syntax is irrelevant.  D wants to have C-ish syntax, I know, but that is
beside
> the point.  One could invent ten different syntaxes for C yet semantically
they
> would all be the same language, C.
>
> What counts are the underlying paradigms and computing models; those are
what
> interest me.  Wrap any syntax you like around them.
>
> Mark