Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!newsserver.jvnc.net!TMEklund.tesc.edu!news.missouri.edu!newshub.more.net!nntp.newsfirst.com!nntp.crosslink.net!news.magicnet.net!feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.idt.net!cdc2.cdc.net!news.texas.net!uunet!in1.uu.net!192.35.48.11!hearst.acc.Virginia.EDU!murdoch!not-for-mail
From: nr@viper.cs.Virginia.EDU (Norman Ramsey)
Subject: Re: Special- vs General-purpose languages for IF
X-Nntp-Posting-Host: viper-fo.cs.virginia.edu
Message-ID: <5b68ef$6jo@viper.cs.Virginia.EDU>
Sender: usenet@murdoch.acc.Virginia.EDU
Organization: University of Virginia
References: <32b72f97@beachyhd.demon.co.uk> <59vlb3$8fj@life.ai.mit.edu> <5a1rue$g63@mamba.cs.Virginia.EDU> <5b3h9d$85a@life.ai.mit.edu>
Date: Fri, 10 Jan 1997 20:22:39 GMT
Lines: 67

In article <5b3h9d$85a@life.ai.mit.edu>, David Baggett <dmb@ai.mit.edu> wrote:
>>I've never really bought the simplicity argument.  Successful languages
>>tend to be big, and often messy.
>
>What about C?  I wouldn't say it's complicated, but it's certainly
>successsful. 

Touch'e.  With a slightly saner syntax (e.g., Sethi's postfix
pointer-dereference proposal), C might have been known for simplicity.

>>I think the special-purpose parser-definition language is worthwhile
>>for the same reasons yacc is worthwhile---building parsers by hand is
>>a pain in the butt when the vocabulary to be recognized changes
>>constantly.
>
>But you still have given no good reason why it should be part of the
>language, rather than in a library.  What's so weird about this interface?
>
>  compiled-grammar = compile(context-free-grammar-specification)
>  parse-input-with(compiled-grammar)

Your proposed interface is fine.  I want to retain the specialized
sublanguage for writing `context-free-grammar-specification'.

>With lisp macros you
>could give the grammar definition nice syntactic sugar without throwing in
>a dozen new operators or syntactic idioms.

Some of us prefer context-free syntax to lisp macros.  For me it's a
religious preference :-)

>The advantage of this interface is that one can write a new, better parser
>that retains the old interface, to parse Russian, for example.

I don't follow you?

>>If I find a flaw in the parser sublanguage, it's that it's not
>>comprehensive enough; one sometimes has to write routines that go grubbing
>>around in individual words.  One way to correct that flaw might be to
>>support more than one parser in a game [...]
>
>This is the very philosophy I object to.  Put in an insufficiently powerful
>language feature, then keep throwing on band-aids to fix this or that
>problem.  What you get is everything but the kitchen sink.

I'm not sure I agree.  I view supporting an arbitrary number of
parsers as `removing a gratuitous restriction,' not as `throwing on a
band-aid'.  I'm afraid I see it as a simplification.

>>There might be gains to moving to a general-purpose language, but if
>>the easy exploitation of the library is lost, I don't think they would
>>be worth it.  
>
>Why would moving to a general-purpose language necessarily change anything
>about the library's ease of use?  I've given example after example of how a
>language like Scheme would make library code *more* usabale and re-usable.

Careful engineering is difficult and time-consuming.  The Inform
library is already carefully engineered to mesh well with the Inform
language.  Doing an equally good job in another language means careful
thought and work.  Without this work, a `better' language might lead
to a worse system.

N
-- 
Norman Ramsey
http://www.cs.virginia.edu/~nr
