From: Chet Murthy <chet@watson.ibm.com>
To: caml-list@inria.fr
Subject: Re: de Bruijn indices
Date: Tue, 10 Oct 2000 13:29:53 -0400 [thread overview]
Message-ID: <200010101729.NAA27342@nautilus-chet.watson.ibm.com> (raw)
In-Reply-To: Your message of Tue, 10 Oct 2000 16:04:54 +0200. <200010101406.e9AE6Fj22755@concorde.inria.fr>
>>>>> "GH" == Gerard Huet <Gerard.Huet@inria.fr> writes:
GH> 1. They lead to efficient implementations. My original
GH> implementation of the constructive engine in Coq's early
GH> versions used de Bruijn indices, and performed reasonably
GH> well. It leads to a completely applicative implementation of
GH> lambda-calculus, and the cost of lifting may be reduced by
GH> Okasaki-like data structures. I still remember the day when
GH> this super-hacker declared that he was going to replace all
GH> this inefficient stuff by slick hashtables - only to undo
GH> everything 2 months later because he was 30% slower.
It turns out that deBruijn indices are *significantly* more efficient
than explicit names. Moreover, the renaming operations that must be
introduced to use explicit names are essentially the same as the
"lifting", etc, operations used in deBruijn indices.
I once modified Coq to use explicit names, and after spending a month
or so, trying to make it as fast as Coq with deBruijn indices,
switched back.
That experiment, and finding that every _single_ avenue for improved
performance, with explicit names, was a dead end, pretty much
convinced me that deBruijn indices are much faster.
Also, regarding human-readability, I think it is a red herring to ask
whether the term Lambda("x",Ref 2) (which corresponds to something
like ("lambda x. y") is more readable than Lambda("x",Var "y").
In both cases, without the "environment" that binds free variables to
values, types, or "meanings" of some sort, the meaning of the term is
undefined. So we need to keep these environments around, and once we
have them, well, we can always just lookup the name, if want it.
Moreover, it is only during debugging that having the "explicit name"
actually buys us anything in readability. At runtime, if the program
ever prints out something, it does so with respect to this
"environment", so there's always a good name to use. If it is
manipulating terms, well, it couldn't very well use the name for
anything other than a lookup, since even in explicit names, the name
can be modified, e.g. by alpha-conversion.
Again, I started out as an "explicit name fanatic", and was converted
to the "creed of deBruijn indices", by hard experience. I would
recommend that before anyone write off deBruijn indices, they attempt
to build a _large_ system (ok, so Coq isn't large by commercial
standards, but by the standards of academic systems it ain't small)
both ways.
--chet--
next prev parent reply other threads:[~2000-10-10 19:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-05 10:33 WWW Page of Team PLClub (Re: ICFP programming contest: results) David McClain
2000-10-05 20:20 ` Stefan Monnier
2000-10-06 19:26 ` eijiro_sumii
2000-10-07 8:19 ` automatic translation in Team PLClub ICFP'2000 entry Julian Assange
2000-10-07 16:30 ` eijiro_sumii
2000-10-06 8:07 ` WWW Page of Team PLClub (Re: ICFP programming contest: results) Xavier Leroy
2000-10-07 8:35 ` Pierre Weis
2000-10-07 9:55 ` Markus Mottl
2000-10-07 10:24 ` Pierre Weis
2000-10-08 21:26 ` John Max Skaller
2000-10-10 10:23 ` Pierre Weis
2000-10-09 5:51 ` Benjamin Pierce
2000-10-09 7:19 ` de Bruijn indices (Re: WWW Page of Team PLClub) Eijiro Sumii
2000-10-10 10:36 ` Pierre Weis
2000-10-10 14:04 ` de Bruijn indices Gerard Huet
2000-10-10 17:29 ` Chet Murthy [this message]
2000-10-11 22:35 ` John Max Skaller
2000-10-05 23:29 Patrick M Doane
2000-10-06 8:15 ` Markus Mottl
2000-10-10 18:09 Greg Morrisett
2000-10-12 14:57 ` Chet Murthy
2000-10-12 18:08 ` Benjamin C. Pierce
2000-10-12 18:19 ` Trevor Jim
2000-10-10 18:30 John R Harrison
2000-10-11 11:26 Simon Peyton-Jones
2000-10-11 20:12 ` Markus Mottl
2000-10-12 17:33 Greg Morrisett
2000-10-12 19:09 John R Harrison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200010101729.NAA27342@nautilus-chet.watson.ibm.com \
--to=chet@watson.ibm.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox