www.digitalmars.com         C & C++   DMDScript  

D - Dylan - fast as C, fun as Lisp

reply Mark Evans <Mark_member pathlink.com> writes:
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
Feb 16 2003
next sibling parent Mark Evans <Mark_member pathlink.com> writes:
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."
Feb 16 2003
prev sibling next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Feb 16 2003
next sibling parent reply anonymous <anonymous_member pathlink.com> writes:
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.
Feb 16 2003
parent Mark Evans <Mark_member pathlink.com> writes:
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
Feb 19 2003
prev sibling parent Garen Parham <garen_nospam_ wsu.edu> writes:
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.
Feb 18 2003
prev sibling parent reply "Jeroen van Bemmel" <anonymous somewhere.com> writes:
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...
Feb 17 2003
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Feb 17 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Feb 19 2003
next sibling parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
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

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
Feb 20 2003
parent Mark Evans <Mark_member pathlink.com> writes:
Sean L. Palmer says...

Syntax can make or break a language.


That may be true but misses completely my point.  Language design involves
decisions different from language usage.  You are saying in effect, "The D
project will not investigate interesting language designs if their syntax is
bad."  That's an arbitrary and unintelligent approach.  We should dig through
the dirt to find the gold and diamonds.  Then we can polish, grind, cut, and
assemble them into beautiful jewels.

Though I agree that syntax counts, it's out of scope for this thread.  We are
prospecting, not jewel-cutting.  We are speaking as language designers, building
a new language.  People who wear jewels typically do not spend their time down
in the mine shafts.  If we have to dig through some syntactical dirt, that's
only natural.

Mark
Feb 20 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.


From a computational point of view, you're right, syntax is irrelevant. From
a marketing point of view, however, syntax is everything <g>.
Feb 20 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
From a computational point of view, you're right, syntax is irrelevant. From
a marketing point of view, however, syntax is everything <g>.


Only if the syntax expresses useful language constructs.  QED.

Mark
Feb 21 2003
next sibling parent bill viasic.com writes:
In article <b36sln$6tu$1 digitaldaemon.com>, Mark Evans says...

From a computational point of view, you're right, syntax is irrelevant. From
a marketing point of view, however, syntax is everything <g>.


Only if the syntax expresses useful language constructs.  QED.


The QED is just too baiting...

I must have seen 100 near-dead languages referenced on this newsgroup.  Walter's
right.  Marketing is everything.  Make it look like C.  Make it imperitive like
C.  Then, slip in a few killer features, and make your money selling "D for
Dummies".

Bill
Feb 21 2003
prev sibling parent "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
Give a language great constructs and ugly inconsistent syntax and you'll get
a cult language following, not a mainstream language.  Very few people will
see past the syntax to the beautiful constructs beneath.

QED?  OMG.  You have a point, but you have to realize we have one too.  All
aspects of a language are important.

BTW I see you throwing around a lot of URL's here.  Some are quite
interesting .  But I will warn you before you waste too much time:  Walter
is not easily persuaded to add features to D.  You and I may or may not
agree with everything, but in the end it's Walter's language and we will
just have to live with that.   If you want some of the features you propose,
perhaps you should use one of those languages instead of trying to make D
into something it's not.  D is currently positioned as a small, cleaner
variant of C with some more advanced features borrowed from Java, C++, and
Pascal, and maybe a little Eiffel.  It's extremely imperative in design and
as such will not easily be morphed to have the functional characteristics
you desire.  I personally have lobbied for functions without side effects,
tuples, etc to no avail.  Walter has declared intent to keep D as easy to
implement compilers for as possible, and intent to keep it as compatible
with C as is tolerable, while making the language more useful and less
painful.

Stirring the pot isn't bad, just don't get your hopes up.  ;)

D may not be my dream language, but it certainly seems like it'll be a
useful one, and more pleasant to use than many which exist today.

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:b36sln$6tu$1 digitaldaemon.com...

From a computational point of view, you're right, syntax is irrelevant.




From

a marketing point of view, however, syntax is everything <g>.


 Only if the syntax expresses useful language constructs.  QED.

 Mark
Feb 22 2003