Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!viewlog.viewlogic.com!josh
From: josh@viewlogic.com (Josh Marantz)
Subject: Re: What should an alternative look like? was Re: Why you should not use Tcl
Message-ID: <Cwuu7w.4vv@viewlogic.com>
Sender: news@viewlogic.com
Nntp-Posting-Host: concept
Organization: Viewlogic Systems, Inc.
Date: Wed, 28 Sep 1994 19:31:06 GMT
Lines: 76

> 	Since one of the three newsgroups this thread is in is
> comp.lang.scheme, comments by RMS, common references to Scheme/Tk, etc... I
> would assume that many would like to see a Scheme derived extention language
> as something competing with Tcl.
> 
> 	So that leads to the following question:  how Scheme-like should
> such a mythical extention language be?

I feel qualified to answer this since I led the project that developed
Viewscript, an non-mythical scheme based extension language.  (Please
see my reply to the "Scheme at work ?" thread.)

> 	Would it be appropriate in such a context to restirct call/cc to non
> local exits only?  (Yes, it would no longer be Scheme, just Scheme-like)

That's what we did.  I think it's not only appropriate, it's difficult
to conceive of a cross-language system that didn't make that
restriction, especially if you want to remain portable.

> 	Would a byte code interpreter be fast enough, or would a more
> platform specific compiler be necessary, giving machine-code output?

This obviously depends on what you are using it for.  For the most
part, I agree with the TCL philosophy that intensive data structure
should be done in the implementation language.  In practice, however,
people always push the language a little further than it was intended,
driving the need to continually improve performance.

> 	How small could such an interpreter/compiler be made and still run
> fast enough?

Well, SIOD is 25K or whatever, and is reasonably fast for most usages.

Viewscript has grown into something much larger.  This is due to a
multi-syntax parser (C-syntax and standard Scheme), fairly
sophisticated (maybe overblown) C-language interace, a large set of
built in library routines, debugging capabilities, operator
overloading, and all that other stuff that tends to creep in when you
build a product that you want to sell to people.

On the other hand, SCM is probably fast enough for what most people
want, has lots of environmental features, and it's still pretty small
(180K on the Sparc for the executable image).  If it weren't
GNU-protected, we'd probably be using it.  (not my decision...the
lawyers...)

>	Could it run within a factor of 100 of C?  Factor of 10?

I think that SCM is roughly that fast.  In the "pi" benchmark that
comes with it in both Scheme and C, the C version runs rougly 14x
faster than the Scheme version in SCM, with parameters (700, 4).

I think byte-code systems like VSCM improve this further, and then
native-code systems would be better still.

ELK is another good scheme implementation, which is designed for use
as an extension language in another system.

>	What sort of module system could be added?

Viewscript adds a Clu-like package system (revealing my origins...).
I think this is pretty useful for keeping a big system sane, and also
turned out to be a nice basis for classes.  On the other hand, this is
more baggage that increases the size and overhead of our system.

> Macro system?

This should probably follow whatever comes out of the Scheme
community.

-- 
Joshua Marantz              If I only could deceive you, forgetting the game
Viewlogic Systems,    Every time I try to leave you, you laugh just the same
josh@viewlogic.com                     'Cause my wheels never touch the road
                                              And the jumble of lies we told
                                Just returns to my back to weigh me down...
