Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!uunet!in1.uu.net!bcstec!jasper
From: jasper@bcstec.ca.boeing.com (Rob Jasper)
Subject: Re: Dylan in the News (fwd)
Message-ID: <DA2G8w.BM4@bcstec.ca.boeing.com>
Organization: The Boeing Company
References: <9506120411.AA11668@locutus.quadralay.com>
Date: Mon, 12 Jun 1995 15:26:55 GMT
Lines: 95

In article <9506120411.AA11668@locutus.quadralay.com>,
Ben Allums <allums@quadralay.com> wrote:
>Forwarded message:
>From allums Sun Jun 11 23:10:29 1995
>Subject: Re: Dylan in the News
>To: Bruce@hoult.actrix.gen.nz (Bruce Hoult)
>Date: Sun, 11 Jun 1995 23:10:29 -0500 (CDT)
>In-Reply-To: <2885582679@hoult.actrix.gen.nz> from "Bruce Hoult" at Jun 9, 95 10:44:39 pm
>X-Mailer: ELM [version 2.4 PL23]
>MIME-Version: 1.0
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: 7bit
>Content-Length: 3520      
>
>>> What ???. C or C++ ? Shouldn't that be Dylan based implementation ?
>>
>>Yes, that seems strange.  Wouldn't it be faster to develop the compiler in MCL
>>or an interpreted Scheme or Dylan, and then bootstrap your way to an
>>environment and compiler written in compiled Dylan?
>
>1) Dylan doesn't have the necessary tools to enable compiler development.
>
>While I've never written a compiler before in my life, I have had a great
>deal of experience writing scanners/parsers for languages life MIF (Maker
>Interchange Format).  Writing these scanners would be a nightmare if not
>for tools like lex, rex, etc.  And while I've seen a ton of these things
>written to generate C, I've yet to see one that generates code for Scheme
>or Lisp.

We are currently using a tool called software Refinery that builds
both lexers and parsers from Lisp. The lexer is based on bison and
the parser generator builds parsers from NQLALR(1) grammars.
>
>
>2) Maintainability requires that you use something other than the product
>   itself to develop it.
>
>How can you ignore a set of well tested compilers?  Dylan may be great stuff,
>but even the Dylan environment will need to be maintained.  Using an
>environment to develop itself can cause all kinds dependency problems, i.e.
>
>  "Is binary bad because we made a mistake in the code generation section or
>   is it bad because the current iteration of the compiler generated a bad
>   binary for the current code generation section?"
>
>
>3) Dylan isn't stable enough in its language definition and not familiar
>   enough to programmers to be used for compiler development.
>
>By using a language like C/C++, which most compilers are written in anyway,
>you gain the benefit of stable (though not ideal) environments, programmer
>familiarity with the language, and suite of well tested tools.
>
>Programmer familiarity with the tools and the development language are
>extremely important.  Can you imagine the developers arguing over what syntax
>and language constructs should be used to code the compiler?  It's taken C/C++
>programmers years to learn that despite that fact the language allows for
>certain constructs, you're really better off not using them.  Programmers
>haven't yet had time (I believe) to write large programs in Dylan and learn
>what's going to be the best way to do something in the long run.  We have a
>pretty good idea today, but theory and practice are two different things.
>
>-------
>
>I'm truly psyched about developing in Dylan, but I don't really
>see the shift in the project's implementation language to be that big of a
>deal.  The major problems are defining the language and learning what can
>and cannot be implemented.  I'm certain that the current MCL version has
>taught Apple quite a bit about what they should have done from the start.
>And knowing that is more important that anything else.  I've rewritten some
>of my programs 5-6 times because I didn't include some nettling detail in my
>original design.  It never took long to do the rewrite, but over six months
>of feedback, testing, and additional fixes has led me to an understanding
>of what I should have done long ago.  Look and Andresson and those guys from
>NCSA who went to Netscape.  It took them very little time to start from
>scratch and create some of the best WWW browsers on the market.
>
>-- 
>**********************************************************************
>*  Ben Allums             *  Tel:  512-346-9199  Fax:  512-346-8990  *
>*  Quadralay Corporation  *  FTP Address:  ftp.quadralay.com         *
>*  allums@quadralay.com   *  WWW Server:   www.quadralay.com         *
>**********************************************************************
>            "Information Tools to build your business on!"
>
>
>-- 
>**********************************************************************
>*  Ben Allums             *  Tel:  512-346-9199  Fax:  512-346-8990  *
>*  Quadralay Corporation  *  FTP Address:  ftp.quadralay.com         *
>*  allums@quadralay.com   *  WWW Server:   www.quadralay.com         *
>**********************************************************************
>            "Information Tools to build your business on!"


