multiple values

329 views
Skip to first unread message

Olin Shivers

unread,
Jul 25, 1996, 3:00:00 AM7/25/96
to

Hey, no fair, Greg. The ML hackers got type systems; the Scheme hackers don't.

ML's one-arg/one-ret-value scheme is indeed elegant and useful. I like
it better than Scheme's system. But you can't, as you suggested, just
go add types to Scheme. Then it wouldn't be Scheme. It would be ML
with a better syntax, or Infer. This is good. Probably better than Scheme.
But not Scheme.

I think you could add a lot of missing, important things to Scheme and keep
it Scheme: modules, records, exceptions. But not Hindley-Milner, required
types.

But who cares? James Clerk Maxwell was once lecturing on theories of light.
There are two general models for light, he said: particle and wave. People
used to think of light as a stream of tiny particles. But they are all dead.

If you see where I'm headed...
-Olin

Ray S. Dillinger

unread,
Jul 25, 1996, 3:00:00 AM7/25/96
to

B. Robert Helm wrote:

> OK, I'll bite. Why would you want something to remain Scheme if
> something better were available? Isn't there enough experience to say
> that static typing, like static scoping, is the Right Thing?
>

Nope. Dynamic typing gives programs better modularity ease of authoring,
cuts down on multiple inclusions of a copy of a particular routine for each
type it applies to (which still happens in c++, even with templates), and
has numerous other benefits. Static typing has ease of compilation and a
very tiny edge in speed. So whether it's The Right Thing just depends
on what you're trying to do. In general, in environments where functions
are passed as data, dynamic typing is agreed to be superior. The smarter
compilers get (and the more complex programs get) the more I expect to see
dynamic typing in production languages.

Bear

Clifford Beshers

unread,
Jul 25, 1996, 3:00:00 AM7/25/96
to

In article <4t8ag1$r...@ix.cs.uoregon.edu> bh...@ix.cs.uoregon.edu (B. Robert Helm) writes:

In article <qijn30o...@lambda.ai.mit.edu>,
Olin Shivers <shi...@ai.mit.edu> wrote:

> But you can't, as you suggested, just
>go add types to Scheme. Then it wouldn't be Scheme. It would be ML
>with a better syntax, or Infer. This is good. Probably better than Scheme.
>But not Scheme.

...

Why didn't you do scsh in ML, instead of Scheme?

Because the name ``mlsh'' is really ugly, probably.

Cliff

--
Clifford Beshers Computer Graphics and User Interfaces Lab
bes...@cs.columbia.edu Department of Computer Science
http://www.cs.columbia.edu/~beshers Columbia University

B. Robert Helm

unread,
Jul 25, 1996, 3:00:00 AM7/25/96
to

In article <qijn30o...@lambda.ai.mit.edu>,
Olin Shivers <shi...@ai.mit.edu> wrote:

> But you can't, as you suggested, just
>go add types to Scheme. Then it wouldn't be Scheme. It would be ML
>with a better syntax, or Infer. This is good. Probably better than Scheme.
>But not Scheme.

OK, I'll bite. Why would you want something to remain Scheme if


something better were available? Isn't there enough experience to say
that static typing, like static scoping, is the Right Thing?

I'm not trying to start a flamewar (honest). I'd just like to hear
the technical and software engineering arguments in favor of Scheme as
a development language, vs. ML or an ML-like successor to Scheme. I'm
a Scheme user with an interest in AI. For some time, I've been
wondering whether I should switch to ML, for things that don't require
Common Lisp.

Why didn't you do scsh in ML, instead of Scheme?

>I think you could add a lot of missing, important things to Scheme and


> keep it Scheme: modules, records, exceptions.

However, portable Scheme language extensions for these features seem
even more remote than the global optimizations for containers you
mentioned earlier. Even the feature that started this thread,
multiple return values, isn't "really" portable Scheme yet, because
the R5RS report never appeared.

Scheme language development seems to have stalled. Why is Scheme
worth developing in, despite the absence of the features you list? Or
do you expect that Scheme will eventually include such features?

> But who cares? James Clerk Maxwell was once lecturing on theories of light.
> There are two general models for light, he said: particle and wave. People
> used to think of light as a stream of tiny particles. But they are all dead.

> If you see where I'm headed...

Sorry, I don't. Are you suggesting Scheme v. ML == particle v. wave
theory? My impression is that both models are still used intuitively
under specific circumstances, even by physicists who know better.
Under what circumstances, in your view, should one prefer Scheme over
ML or an ML-like successor?

Rob Helm

Thant Tessman

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <31F841...@sonic.net>, "Ray S. Dillinger" <be...@sonic.net> wrote:

> B. Robert Helm wrote:
>
> > OK, I'll bite. Why would you want something to remain Scheme if
> > something better were available? Isn't there enough experience to say
> > that static typing, like static scoping, is the Right Thing?
> >
>

> Nope. Dynamic typing gives programs better modularity ease of authoring,

This MIGHT be true if you compare dynamic typing to a statically typed
language with a really BAD type system. SML's type system is good and it
promotes modularity and manages complexity better than Scheme.


> cuts down on multiple inclusions of a copy of a particular routine for each
> type it applies to (which still happens in c++, even with templates),

SML does not produce a different implementation of a polymorphic routine
on a per-type basis.


> Static typing has ease of compilation and a
> very tiny edge in speed.

With the note that the performance of a good Scheme implementation is
much better than most 'main-stream' programmers would guess, the
difference between a statically-typed language and a latently-typed
language is not "tiny". Even with straight Scheme a lot of energy has
gone into improving performance via type inferrence.

But SML is faster. For a raw iterative loop, C/C++ will always beat SML
(and Scheme). However, it has been my experience that if any dynamic
memory management is involved, SML will significantly OUTPERFORM C/C++.


> In general, in environments where functions
> are passed as data, dynamic typing is agreed to be superior.

You can't statically type "eval", but other than that, I don't believe
this statement at all.


> The smarter
> compilers get (and the more complex programs get) the more I expect to see
> dynamic typing in production languages.

You're probably right, but the real reason dynamically-typed languages
have an advantage over statically-typed languages is because there is no
one right type system. Safety and speed are very good things, but the
most important thing about a type system is the semantic framework it
provides for managing complexity. The biggest advantage Scheme has over
SML is that it is possible to build new type systems, or type systems more
appropriate for a given problem.

> So whether it's The Right Thing just depends
> on what you're trying to do.

Yup, yup.

Also, Scheme is more fun to program in because Scheme tends to let you
'feel' your way to a working program, whereas SML forces you to think your
way there. But we have to remember that they're both so far beyond C++
that it's silly to argue about them.


> Bear

-thant

Guillermo (Bill) J. Rozas

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <qijn30o...@lambda.ai.mit.edu> shi...@ai.mit.edu (Olin Shivers) writes:

Path: hplntx!news.dtc.hp.com!col.hp.com!sdd.hp.com!swrinde!howland.reston.ans.net!newsfeed.internetmci.com!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!usenet
From: shi...@ai.mit.edu (Olin Shivers)
Newsgroups: comp.lang.scheme
Date: 25 Jul 1996 09:15:17 -0400
Organization: Artificial Intelligence Lab, MIT
Lines: 18
Sender: shi...@lambda.ai.mit.edu
Reply-To: shi...@ai.mit.edu
NNTP-Posting-Host: lambda.ai.mit.edu
X-Newsreader: Gnus v5.1

Hey, no fair, Greg. The ML hackers got type systems; the Scheme hackers don't.

ML's one-arg/one-ret-value scheme is indeed elegant and useful. I like

it better than Scheme's system. But you can't, as you suggested, just


go add types to Scheme. Then it wouldn't be Scheme. It would be ML
with a better syntax, or Infer. This is good. Probably better than Scheme.
But not Scheme.

I think you could add a lot of missing, important things to Scheme and keep


it Scheme: modules, records, exceptions. But not Hindley-Milner, required
types.

But who cares? James Clerk Maxwell was once lecturing on theories of light.


There are two general models for light, he said: particle and wave. People
used to think of light as a stream of tiny particles. But they are all dead.

If you see where I'm headed...

-Olin

Guillermo (Bill) J. Rozas

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <qijn30o...@lambda.ai.mit.edu> shi...@ai.mit.edu (Olin Shivers) writes:

| From: shi...@ai.mit.edu (Olin Shivers)
| Date: 25 Jul 1996 09:15:17 -0400
|

| Hey, no fair, Greg. The ML hackers got type systems; the Scheme hackers don't.
|
| ML's one-arg/one-ret-value scheme is indeed elegant and useful. I like
| it better than Scheme's system. But you can't, as you suggested, just
| go add types to Scheme. Then it wouldn't be Scheme. It would be ML
| with a better syntax, or Infer. This is good. Probably better than Scheme.
| But not Scheme.

You don't need types to do this in Scheme or Lisp. You just need
multiple entry points for a higher-performance implementation. In
another post I mention a rough outline of how to do this.

The only thing you have to give up is EQ?-ness of the
multiple-value/argument aggregates. Of course, since ML doesn't
provide it either, you are no worse off.

In many cases, a fair amount of the efficiency to be gained from static
type systems can be regained by compiling procedures in two modes:
- assumptions satisfied
- general (default) mode

For first-order code, the assumptions can be checked by the linker,
which can generate interface stubs on demand to avoid exponentiation
of code, and there is no overhead for the calls when the assumptions
match.

Higher-order calls do incur some overhead, but the overhead is not
significantly greater than what is already in place (arity checking).
The alternate code can be generated on demand and cached for reuse.

| I think you could add a lot of missing, important things to Scheme and keep
| it Scheme: modules, records, exceptions. But not Hindley-Milner, required
| types.
|
| But who cares? James Clerk Maxwell was once lecturing on theories of light.
| There are two general models for light, he said: particle and wave. People
| used to think of light as a stream of tiny particles. But they are
| all dead.

I think this applies equally well to both languages. There may just
be a slight phase difference.

After all, things like VB, C, C++, and Java are where the action
really is, unfortunately.

Bryan O'Sullivan

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <4tb0mt$d...@voyager.itii.com> stic...@voyager.itii.com
(Patrick Stickler) writes:

p> Be on the lookout for a growing flurry of Scheme activity in the
p> SGML (Standard Generalized Markup Language - ISO 8879) community in
p> connection with DSSSL (Document Style Semantics and Specification
p> Language - ISO 10179), a standard composition specification
p> formalism which is based on R4RS Scheme (with a few tweaks).

This "growing flurry of activity" has already been happening for over
a year. Unfortunately (or something), DSSSL isn't going to take the
world over and, as a result, it's not going to be a great big deal for
Scheme programmers looking for work. In addition, the annoyance of
dealing with SGML can reasonably be expected to put off a lot of
otherwise-enthusiastic Schemers.

Apart from gratuitous overuse of special forms and special read syntax
and a small number of other nits that annoy the Scheme purist within
me, I think DSSSL is pretty decent as ISO standards go.

<b

--
Let us pray:
What a Great System. b...@eng.sun.com
Please Do Not Crash. b...@serpentine.com
^G^IP@P6 http://www.serpentine.com/~bos

Steven L Jenkins

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <qijwwzrt2...@lambda.ai.mit.edu>,
Olin Shivers <shi...@ai.mit.edu> wrote:
...

>I think the Scheme community may yet recover momentum. The folks down at
>Rice are doing really interesting work with Scheme, Danvy has a draft R5RS,
>and Indiana, as always, holds the torch high.
> -Olin

Don't forget the folks at Texas..


Paul Wilson

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <qijybk7...@lambda.ai.mit.edu>,
Olin Shivers <shi...@ai.mit.edu> wrote:
>It has occurred to me on multiple occasions that we would be better served
>by acronyms and names for things that had a certain "truth in advertising"
[...]

As I recall, Alan Kay said that the reason Smalltalk was so named
was precisely to keep people's expectations low.

What could you expect from a little language for kids named Smalltalk?

(If it's not true, I don't want to know.)

--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wil...@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)

Patrick Stickler

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <87d91id...@organon.serpentine.com>,

Bryan O'Sullivan <b...@serpentine.com> wrote:
>In article <4tb0mt$d...@voyager.itii.com> stic...@voyager.itii.com
>(Patrick Stickler) writes:
>
>p> Be on the lookout for a growing flurry of Scheme activity in the
>p> SGML (Standard Generalized Markup Language - ISO 8879) community in
>p> connection with DSSSL (Document Style Semantics and Specification
>p> Language - ISO 10179), a standard composition specification
>p> formalism which is based on R4RS Scheme (with a few tweaks).
>
>This "growing flurry of activity" has already been happening for over
>a year. Unfortunately (or something), DSSSL isn't going to take the
>world over and, as a result, it's not going to be a great big deal
>for Scheme programmers looking for work. In addition, the annoyance
>of dealing with SGML can reasonably be expected to put off a lot of
>otherwise-enthusiastic Schemers.
>
>Apart from gratuitous overuse of special forms and special read syntax
>and a small number of other nits that annoy the Scheme purist within
>me, I think DSSSL is pretty decent as ISO standards go.

Actually, the "flurry of activity" has been "happening" for much longer
than a year -- but now that the ISO standard is (finally) out, you
will see this flurry increase.

I never made the claim that DSSSL was going to employ the large
majority of the Scheme programming masses -- only that those Scheme
programmers who were looking for some *very* interesting work, might
find some to their liking in the SGML/DSSSL community.

Having tracked the DSSSL standard from its inception, and having
worked in the SGML field for going on 8 years, I'm here to tell you
that DSSSL will certainly take the commercial publishing world over
(eventually), and probably the Web as well. As for the "annoyance"
of dealing with SGML, I'm willing to wager that either (a) you've
not done much work with SGML or (b) you were applying it to a problem
for which it was either ill suited or overkill. I personally find
SGML to make my life *much* easier and to remove orders of magnitude
more annoyances than it adds.

I'll be the first to admit, however, that SGML is neither simple, nor
perfect.

I agree, though, that DSSSL is a good example of an ISO standard "done
right".

========================================================================
Patrick Stickler KC4YYY
Information Technologies International Inc. stic...@itii.com
9018 Notchwood Court http://www.itii.com
Orlando, Florida 32825 USA (+1 407) 380-9841
------------------------------------------------------------------------
SGML Consulting & Engineering, Legacy Data Conversion, WWW/HTML
------------------------------------------------------------------------
An affiliate of the Martin Hensel Corporation http://www.hensel.com
========================================================================


Olin Shivers

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

Why didn't you do scsh in ML, instead of Scheme?

Because the name ``mlsh'' is really ugly, probably.

Ah, but if I can count it as an OS, I could call it "mlshos" with somewhat
unsettling, but probably all-too-accurate implications for users.

It has occurred to me on multiple occasions that we would be better served
by acronyms and names for things that had a certain "truth in advertising"

quality. I have considered, for example, naming an OS "Molasses," so that
should anyone give me any grief about its speed, I could just laugh at them
and say, "What did you expect?" Or perhaps naming a commercial tool, "Vapor,"
or one of those systems architecture description languages "Vague."
-Olin

Olin Shivers

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

OK, I'll bite. Why would you want something to remain Scheme if
something better were available? Isn't there enough experience to say
that static typing, like static scoping, is the Right Thing?

I'm not trying to start a flamewar (honest). I'd just like to hear


the technical and software engineering arguments in favor of Scheme as
a development language, vs. ML or an ML-like successor to Scheme. I'm
a Scheme user with an interest in AI. For some time, I've been
wondering whether I should switch to ML, for things that don't require
Common Lisp.

Why didn't you do scsh in ML, instead of Scheme?

Well, the general issues have been hashed out many, many times. People get
pretty religious about it. My current religion is that I am not interested
in listening to anyone flame on these issues who hasn't written > 1,000 lines
of code in both Scheme and ML. I believe most of the angst about "fascist
static type systems" would evaporate if he who holds the opinions would just
write a program instead of flaming.

However, to address your specific question. I chose Scheme mostly because it
had macros. The name of the game when I did scsh was syntax
extension. Scheme's macros allow me to embed specialised notations inside
my general purpose programming language. Lisp & Scheme are the only languages
I know of that let you do this so well.

Scheme language development seems to have stalled. Why is Scheme
worth developing in, despite the absence of the features you list? Or
do you expect that Scheme will eventually include such features?

I think the Scheme community may yet recover momentum. The folks down at

Paul Wilson

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <cc001636-260...@ip95.van-nuys.ca.interramp.com>,

Thant Tessman <cc001636> wrote:
>
>In article <31F841...@sonic.net>, "Ray S. Dillinger" <be...@sonic.net> wrote:
>
>> B. Robert Helm wrote:
>>
>> > OK, I'll bite. Why would you want something to remain Scheme if
>> > something better were available? Isn't there enough experience to say
>> > that static typing, like static scoping, is the Right Thing?
>> >
>>
>> Nope. Dynamic typing gives programs better modularity ease of authoring,
>
>This MIGHT be true if you compare dynamic typing to a statically typed
>language with a really BAD type system. SML's type system is good and it
>promotes modularity and manages complexity better than Scheme.

Yes and no. (I don't think we really disagree... see below.)

Scheme lets you invent your own modularity mechanism, and your own
abstraction-layering techniques. I don't know how to write a metaobject
protocol for ML in ML, but I know how to write one for Scheme, in Scheme.

Until ML has a nice object system and a really, really nice recursive
module system, I'm not buying it. (I know, people are working on those
thigns, and have been for years, and they're making progress. In the
meantime, we can easily add macros, metaobjects, and funky templates
to Scheme without batting an eye. I think ML's type system would be
a pain in the ass for what we want to do.)

I'm one of those people who believes he benefits hugely from Scheme's
libertarianism. Admittedly, it's not for everybody. If I had a bunch
of programmers grinding out Just Code, I might saddle them with a static
type system. Then again, I might not.

Which raises some interesting philosophical questions about bondage
and discipline.

In the old days, it used to be easy to make fun of static type systems,
because there were things it was reasonable to do All The Time that
couldn't be reasonably expressed within the constraints of the static
type systems that people had then.

With parameterized types, things got a lot better---90% of the things
you do with dynamic typing all the sudden were possible with type safety.

With implementation inheritance and subtyping (separated, please) things
get better still. 95% of the things you I want to do can be done easily
the type system.

The only problem is that the other 5% is where all the fun is. When I
solve a hard modularity problem, I usually do something that that requires
a few lines of code, maybe a few pages, but requires a few pages of
explanation, or maybe a technical paper, to explain why it's the Right Thing.

It seems to me that there's an unfortunate split between the strong typing
camp and the dynamic typing camp. Anybody who knows The Truth knows that
strong typing can be great 95% of the time, but is a major obstacle
5% of the time. (Pick your own probabilities---it might be 80/20 or
99/1, but the point stands.)

The problem with Type Safety fanatics is that they keep saying "Type Safety
is the only way to go. Wait a few years until we can type what you're
doing, and then we'll support it in our language." Well, I'm not going
to wait, because it's a never-ending process. Type theorists are always
behind the curve, and for fundamental reasons always will be.

Real, useful languages with strong type systems provide escapes, of course.
Modula-3 has an "any" type, where all bets are (statically) off. C has
unsafe casts, God help us, so that if we aren't happy with a Pascalish
brain-dead type system, we can skip all the way down to an assembler-
or FORTH-like completely untyped paradigm.

While I hate C casts, an "any" type is damned useful. If I want to write
Scheme-like macro and take responsibility for what it emits, I should
be able to do so. I should not have to write everything as higher-order
functions and hope that the compiler is smart enough to flatten it out
into something reasonable. I should especially not have to write a
separate preprocessor that manipulates strings, and replicate half
my compiler front end, because I don't have a decent macro system.

Too many type system designers just don't like to admit that their wonderful
type systems are only a 95% solution, and that 5% of the time you're
simply hamstrung.

>> cuts down on multiple inclusions of a copy of a particular routine for each
>> type it applies to (which still happens in c++, even with templates),
>
>SML does not produce a different implementation of a polymorphic routine
>on a per-type basis.

If it doesn't, at least sometimes, it's not getting the performance benefits
it should from static typing.

>> Static typing has ease of compilation and a
>> very tiny edge in speed.
>
>With the note that the performance of a good Scheme implementation is
>much better than most 'main-stream' programmers would guess, the
>difference between a statically-typed language and a latently-typed
>language is not "tiny". Even with straight Scheme a lot of energy has
>gone into improving performance via type inferrence.

Agreed. But doesn't this suggest that you ought to have optional
strong typing, like Dylan? (Not that I'm a big fan of the details
of Dylan's type system---not enough separation of interfaces from
implementation for my taste---but the general idea of having a strong
type system that you can turn on or off seems the only sane thing to
me.)

>But SML is faster. For a raw iterative loop, C/C++ will always beat SML
>(and Scheme). However, it has been my experience that if any dynamic
>memory management is involved, SML will significantly OUTPERFORM C/C++.

Well, that's partly because existing implementations of malloc are
mostly brain-dead, but a big part of it is lack of GC. So ML gets
it right to have GC and available strong typing. What it gets wrong
is having mandatory strong typing. I'm smarter than a Hindley-Milner
type system, when I try, even if I'm not as smart as Hindley or Milner.

When I don't want to try to be that smart, having strong types would be
nice.

>> In general, in environments where functions
>> are passed as data, dynamic typing is agreed to be superior.
>
>You can't statically type "eval", but other than that, I don't believe
>this statement at all.

If you can't use eval, or *macros* you're toast.

(Note: I think eval is often abused. Usually macros and lambda are
plenty powerful, and even they should be used very judiciously. But
without macros, a language just isn't worth using.)

>> The smarter
>> compilers get (and the more complex programs get) the more I expect to see
>> dynamic typing in production languages.
>
>You're probably right, but the real reason dynamically-typed languages
>have an advantage over statically-typed languages is because there is no
>one right type system.

Precisely. You should be able to build your own type system for your
own domain-specific programming environment, which is what all Serious
Programs evolve into.

>Safety and speed are very good things, but the
>most important thing about a type system is the semantic framework it
>provides for managing complexity. The biggest advantage Scheme has over
>SML is that it is possible to build new type systems, or type systems more
>appropriate for a given problem.

Right. The problem with Scheme for Real Work is that it doesn't have
the right framework for building your own type system. (It's a lot of
work to erect a flexible, extensible type system framework, and *then*
erect your own domain-specific type system.) The problem
with ML for Real Work is that it doesn't have the right type system,
and won't let you build your own.

>> So whether it's The Right Thing just depends
>> on what you're trying to do.
>
>Yup, yup.

Yup, but nope. There's a language missing somewhere. Scheme and ML
have a whole lot of Right Things in common, but they're at opposite
ends of a spectrum that needs to be synthesized, not compromised.

Reflection is the key thing. The ML camp is too much into the "we'll
dictate the semantic framework" mindset, and the Scheme camp is too
much into the "We won't dictate anything at all---heck we won't even
provide anything--you're on your own" mindset.

(Yes, I know this is unfair---there are Schemers working on just
this sort of thing. They just aren't going to make it into Scheme
anytime soon, and for lots of good reasons---they're too cutting-edge
and controversial. Until then, Scheme will be too low-level because
it doesn't provide a semantic framework, and ML will be too high-level
because it dictates one that's limited.)

The real work is in between---how do you design a language that has
the right defaults for most purposes, but the right escapes to let
you do what needs to be done?

I think this requires some serious thought about levels of abstraction
and how software really gets built. The CLOS MOP is a good start,
but it addresses mostly implementation, not interfaces, and interfaces
are the key to providing easily composable abstractions.

C++ templates are also worth a look, oddly enough. They're really macros,
you know... they're dynamically-typed at compile time, but what they
spit out has to pass the C++ type checker. An interesting tradeoff.
(You can do surprisingly hip things with C++ templates. Unfortunately,
C++ has enough warts that most of them turn out to be inconvenient
for uninteresting reasons.)

>Also, Scheme is more fun to program in because Scheme tends to let you
>'feel' your way to a working program, whereas SML forces you to think your
>way there. But we have to remember that they're both so far beyond C++
>that it's silly to argue about them.

Agreed.

>
>> Bear
>
>-thant

Patrick Stickler

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <qijwwzrt2...@lambda.ai.mit.edu>,

Olin Shivers <shi...@ai.mit.edu> wrote:
> Scheme language development seems to have stalled. Why is Scheme
> worth developing in, despite the absence of the features you list? Or
> do you expect that Scheme will eventually include such features?
>
>I think the Scheme community may yet recover momentum. The folks down at
>Rice are doing really interesting work with Scheme, Danvy has a draft R5RS,
>and Indiana, as always, holds the torch high.
> -Olin

Be on the lookout for a growing flurry of Scheme activity in the SGML


(Standard Generalized Markup Language - ISO 8879) community in

connection with DSSSL (Document Style Semantics and Specification

Language - ISO 10179), a standard composition specification formalism


which is based on R4RS Scheme (with a few tweaks).

Any Scheme programmers with any clue about publishing technology (or
the willingness to learn) who are looking for a new job would do well
to look at DSSSL for opportunities...

For the truly interested:

http://www.sil.org/sgml/
http://www.jclark.com/dsssl/

mathew

unread,
Jul 27, 1996, 3:00:00 AM7/27/96
to

In article <qijybk7...@lambda.ai.mit.edu>,

Olin Shivers <shi...@ai.mit.edu> wrote:
>It has occurred to me on multiple occasions that we would be better served
>by acronyms and names for things that had a certain "truth in advertising"
>quality.

Yeah. Walking into a computer bookshop recently made me think that the
authors of Java should have named the language "Bandwagon".


mathew
--
me...@pobox.com home page with *content* at http://www.pobox.com/~meta/

Help prevent economic censorship on the net - support the Open Text Boycott
See http://www.pobox.com/~meta/rs/ot/

Ray S. Dillinger

unread,
Jul 27, 1996, 3:00:00 AM7/27/96
to

Thant Tessman wrote:
>
> In article <31F841...@sonic.net>, "Ray S. Dillinger" <be...@sonic.net> wrote:
> > Nope. Dynamic typing gives programs better modularity ease of authoring,
>
> This MIGHT be true if you compare dynamic typing to a statically typed
> language with a really BAD type system. SML's type system is good and it
> promotes modularity and manages complexity better than Scheme.
>

Excuse me? I have reams and reams of scheme source code for untyped
routines, and when I develop a completely new type, I define a few
primitives like comparison operators, and then all my higher-level
functions work just fine. My impression of statically typed languages
is that you have to actually touch each and every routine you want to
work with a new type -- The better the system, the lighter the touch,
but you have to touch them *all*. I call scheme's power better modularity,
ease of authoring, and complexity management than anything I've ever met
in *any* other language.

> > cuts down on multiple inclusions of a copy of a particular routine
> > for each type it applies to (which still happens in c++, even
> > with templates),
>
> SML does not produce a different implementation of a polymorphic routine
> on a per-type basis.

Well then what's the point of you having to specify types in the first
place? And how does it get any speed edge if its polymorphic routines
are in fact untyped?

> > Static typing has ease of compilation and a
> > very tiny edge in speed.
>
> With the note that the performance of a good Scheme implementation is
> much better than most 'main-stream' programmers would guess, the
> difference between a statically-typed language and a latently-typed
> language is not "tiny". Even with straight Scheme a lot of energy has
> gone into improving performance via type inferrence.

If I stick to things that I can *do* in c++ without implementing my own
number system, nonlocal exits, continuations, etc, from scratch, the
compiled c++ code (using the g++ compiler) runs about %5-10 faster than
compiled scheme code (using MIT scheme with a few 'tweaks.') You may
not consider this 'tiny.' I do.


> > In general, in environments where functions
> > are passed as data, dynamic typing is agreed to be superior.
>
> You can't statically type "eval", but other than that, I don't believe
> this statement at all.

I have a function called "compose." it takes a list of functions as
arguments and returns a function which is their composition. I use it
to string together any arbitrary sequence of functions I care to, as
long as each one takes an argument which is the return type of the last.
The functions I get back can be defined as taking *any* argument type,
and producing *any* type result. How are you going to do that in a
statically typed system?

Most of my library takes items of unknown types, plus functions that
provide primitive services (like equality tests) on that type. Some of
them return functions defined to work on that type without the primitive-
service functions provided in the calling frame (which makes functions of
a form better suited to "compose" for example). D'you want to write
*those* in a statically typed system?


> <snip> the real reason dynamically-typed languages


> have an advantage over statically-typed languages is because there is no
> one right type system.

Agreed.

> Safety and speed are very good things, but the
> most important thing about a type system is the semantic framework it
> provides for managing complexity. The biggest advantage Scheme has over
> SML is that it is possible to build new type systems, or type systems more
> appropriate for a given problem.

Also agreed. My programming style capitalizes heavily on that strength,
and on the ability to have nonlocal exits and closures. I suspect yours
capitalizes heavily on strengths of ML. So, both of us think we have
the "best" language. And I guess both of us do, for our particular styles.

> Also, Scheme is more fun to program in because Scheme tends to let you
> 'feel' your way to a working program, whereas SML forces you to think your
> way there.

Hm. I've always considered scheme's real strength to be the ability to
define new primitives and have them just "work" with whatever types you
throw at them. It gives me *fantastic* code reusability. Often I just
size up a problem, then write a routine to solve it which calls a couple
dozen things from my library, and it's done. I haven't been able to do
that with any other language.
Bear

Bryan O'Sullivan

unread,
Jul 27, 1996, 3:00:00 AM7/27/96
to

In article <31FA4C...@sonic.net> "Ray S. Dillinger"
<be...@sonic.net> writes:

r> My impression of statically typed languages is that you have to
r> actually touch each and every routine you want to work with a new
r> type -- The better the system, the lighter the touch, but you have
r> to touch them *all*.

Yours is an incorrect impression. For example, in Haskell, I can
define type classes that may be extended by declaring certain types as
instances of those classes. I can extend the Num class (which
contains numerical types such as arbitrary-precision Integers,
fixed-precision Ints, and Floats by default) thus:

type PointG = (Int, Int)

instance Eq PointG where
p1 == p2 = theta p1 (0,0) == theta p2 (0,0)

instance Num PointG where
(x1, y1) - (x2, y2) = (x1 - x2, y1 - y2)
... and so on ...

This code gives me a basis for implementing Graham's scanning
algorithm for finding the convex hull, and I can manipulate PointG
objects using the standard numeric operators +, - and so on.

>> SML does not produce a different implementation of a polymorphic
>> routine on a per-type basis.

r> Well then what's the point of you having to specify types in the
r> first place?

This is orthogonal to the issue of specialising for speed. I specify
types in Haskell, even though I usually don't need to because the
correct types are inferred for me, to help me reason about internal
and external consistency in my code. If I had some kind of bolt-on
type inference program that checked Scheme code in a similar manner
(as far as was possible), that would make me very happy.

r> And how does it get any speed edge if its polymorphic routines are
r> in fact untyped?

I find it hard to believe that no individual SML implementation might
specialise polymorphic functions for some types. Performance-oriented
Haskell compilers certainly do.

--

unread,
Jul 27, 1996, 3:00:00 AM7/27/96
to

In article <4t8ag1$r...@ix.cs.uoregon.edu> bh...@ix.cs.uoregon.edu (B. Robert Helm) writes:

OK, I'll bite. Why would you want something to remain Scheme if
something better were available? Isn't there enough experience to say
that static typing, like static scoping, is the Right Thing?

There are some things that you can't typecheck statically. There are
some things that can be typechecked statically but that people haven't
figured out yet how to. Defining, implementing, and explaining a
modern static type system is a lot harder than defining, implementing,
and explaining a more powerful dynamic type system. And getting
separate compilation, runtime upgrades, and incremental development to
work with a static type checker is hard. On the other hand, static
type checking clearly is very useful during code maintenance and on
projects involving many programmers. So, it really isn't an either/or
situation: both kinds of type systems have their uses. Where language
complexity is less of an issue, modern general purpose languages seem
to move towards offering both.

Thomas.


Shriram Krishnamurthi

unread,
Jul 28, 1996, 3:00:00 AM7/28/96
to

In article <cc001636-260...@ip95.van-nuys.ca.interramp.com>,
Thant Tessman <cc001636> wrote:

> SML does not produce a different implementation of a polymorphic routine
> on a per-type basis.

It's worth looking at the TIL compiler being produced at CMU. The
polymorphism-by-boxing technology built into SML/NJ has been in the
process of revision for some years now, and these revisions are now
being seen in new compilers. TIL's use of intensional polymorphism
helps them do several clever things. The details are on-line:

http://foxnet.cs.cmu.edu/rwh/papers.html

'shriram

Alex Williams

unread,
Jul 28, 1996, 3:00:00 AM7/28/96
to

Perhaps its me, but I've always thought that the `best of both
worlds,' you might say, would be a dynamically-typed language that
allowed adding type declarations on the fly, after the fact, or write
them in from the beginning.

This solution, at least, doesn't beg a `sufficently smart compiler,'
and rather falls in with Scheme's iterative programming techniques.

--
Alexander Williams {zan...@photobooks.com ||"Quiet, Mal! Can't you
tha...@alf.dec.com} || see I'm Creating!?"
============================================// -- Dr Blight


Juliusz Chroboczek

unread,
Jul 28, 1996, 3:00:00 AM7/28/96
to Ray S. Dillinger

Hello.

Disclaimer: I am a Scheme and Lisp lover. I simply believe that ML is
a good language (although I don't like the environments I know), and
that bashing ML from a Scheme perspective is as unproductive as
bashing Scheme or Lisp from an ML (or C++) perspective.

In article <31FA4C...@sonic.net>,
Ray S. Dillinger <be...@sonic.net> argued against ML:

RSD> My impression of statically typed languages
RSD> is that you have to actually touch each and every routine you want to
RSD> work with a new type -- The better the system, the lighter the touch,
RSD> but you have to touch them *all*.

Nope. That's the work of the compiler. You have to *recompile* them
all, but not actually change the source code. Or, in simple cases,
you can use polymorphism, and not even recompile any code.

An example of polymorphism: you have some type T, an ordering
predicate lessp:T*T->bool and a function
sort:'a list*('a*'a->bool)->'a list (where 'a is the ML notation for a
type variable). Then, if some code does:

sort l lessp

then this code will not need to be changed if you change the
representation of T. You only need to make sure that lessp is
consistent with T (and the compiler will often barf when it is not the
case).

You don't always want to be polymorphic. Suppose that you have a
complicated function munge:T->T which never accesses directly a value
of type T except through a well defined (albeit large) set of
low-level functions (such as lessp). Then, if you change the
representation of T, you will only need to change the low level
functions. Of course, unlike in Scheme, all of the code will need to
be recompiled (that's one of the reasons why I program in Lisp).

The module system (both in SML and recent versions of Caml) will help
you make sure that this encapsulation is respected (as far as I know,
there is no way to guarantee in Scheme that there are no hidden
dependencies on a particular representation). It will also allow you
to write the code in such a manner that you will not need to recompile
it, but only relink it (to reapply the functors, in ML parlance).
Would a module system for Scheme give you the same guarantees? (I
think it could be done, but not without introducing types; I seem to
remember that there was a proposal for such a beast once (Blume?)).

>> SML does not produce a different implementation of a polymorphic routine
>> on a per-type basis.

RSD> Well then what's the point of you having to specify types in the first
RSD> place? And how does it get any speed edge if its polymorphic routines
RSD> are in fact untyped?

See the example above. munge is not polymorphic, but it could easily
be recompiled when the types changed. On the other hand, sort is
polymorphic, but the type system guaranteed that applying the
functinal argument to a couple of members of the list is safe, so that
no runtime checks were needed (it is not clear to me whether the
compiler needs to tag the types anyway).

(RSD than goes on to refute the myth that Dynamic typing must be slow;
I absolutely agree with him)

>> You can't statically type "eval", but other than that, I don't believe

>> [that dynamic typing is any more powerful than static typing].

Dynamic typing allows you to write many programs that can't be written
in a static type system. However, usually there is another way to
express the same behaviour.

RSD> I have a function called "compose." it takes a list of functions as
RSD> arguments and returns a function which is their composition [the
RSD> functions are of arbitrary types].

This seems impossible to do directly in the SML type algebra.
However, if the types of the arguments/results are in a small finite
set, than you can take a union of the types used (by the way, that's a
simple example of monadic style; it would be clumsy to write in SML,
but quite natural in Haskell). (By the way, have you had a look at
Objective Caml yet? It's somewhere on www.inria.fr.)

>> <snip> the real reason dynamically-typed languages
>> have an advantage over statically-typed languages is because there is no
>> one right type system.

That's true from a practical point of view, but wrong from a
theoretical one. The One Right Type System for functional systems
without first class control operators is second order intuitionistic
predicate calculus.

My opinion is that dynamic type systems provide a worse developing
environment. It is more difficult to debug your code (what's the type
of that print statement you introduced for debugging?), you can't
change a function on the fly without recompiling all the functions
that use it, it is next to impossible to have a `format' function
(although the original Caml had `printf', hacked in by raping the type
system in an unsafe way), and I've never seen a good debugger for ML
(sorry, Jerome, if you're reading this). But systems such as
ML/Haskell are in their infancy. Lisp, on the other hand, has a
mature implementation technology.

This message does not represent the opinions of anyone, not even mine.

J. Chroboczek

Jeffrey Mark Siskind

unread,
Jul 28, 1996, 3:00:00 AM7/28/96
to

In article <qijn30o...@lambda.ai.mit.edu> shi...@ai.mit.edu (Olin Shivers) writes:

Hey, no fair, Greg. The ML hackers got type systems; the Scheme hackers
don't.

Who says? There are at least three implemented type systems for Scheme:
Wright & Cartwright's Soft Scheme, Flanagan & Felleisen's SBA, and Siskind's
Stalin. All of them type full Scheme with no restrictions.

But you can't, as you suggested, just go add types to Scheme.
Then it wouldn't be Scheme.

Why not? Pray tell why Stalin is not Scheme?
--

Jeff (home page http://tochna.technion.ac.il/~qobi)

Erik Naggum

unread,
Jul 29, 1996, 3:00:00 AM7/29/96
to

[Patrick Stickler]

| Having tracked the DSSSL standard from its inception, and having worked
| in the SGML field for going on 8 years, I'm here to tell you that DSSSL
| will certainly take the commercial publishing world over (eventually),
| and probably the Web as well. As for the "annoyance" of dealing with
| SGML, I'm willing to wager that either (a) you've not done much work
| with SGML or (b) you were applying it to a problem for which it was
| either ill suited or overkill. I personally find SGML to make my life
| *much* easier and to remove orders of magnitude more annoyances than it
| adds.

you seem to need creds: I have been working with SGML since 1989, I
maintained the SGML Repository at the University of Oslo for nearly 6
years, I was a member of the ISO working group for nearly 5 years, and I
have contributed some 1500 articles to comp.text.sgml over the same years.

my main goal in working with SGML was to find ways to represent information
for arbitrary reuse (_one_ of which is printing) -- some means to let us
humans encode information such that programs could deal with some of the
complexity of the intuitive structures in our communication. my goal was
most emphatically _not_ to put ink on paper or pixels on screens, and that
is the only place where SGML has been widely used. over these years, my
annoyances with SGML grew, and when I had gotten three chapters into a book
on SGML (working title: "A Conceptual Introduction to SGML"), I realized
that I had been willing to accept such a staggeringly large number of
annoyances and flaws in this language that I could neither write further on
my book nor tell people in any other way that SGML is the Right Thing,
because it isn't.

SGML does have some good ideas, but they are neither exploited nor explored
by the user community, and they drown in useless garbage that make the
reuse of information coded in SGML harder than any other language that
could be used. SGML's only actual forte is that it is a standard. the
standard itself is horrendously complex and amazingly lacking in precision,
making it an ordeal to study it and understand it _completely_, which about
a dozen people did last time I checked (at the beginning of this year).

after having invested nearly 5 years of my life in SGML, I decided that it
had no future outside of print shops and government contracts, and I could
either waste my time and money not getting any of the necessary changes
through the ISO "review" process, help people encode a structure in their
information where they had even less clue and incentive to understand their
own information than they do with databases, or do something fun and
exciting and rewarding. I chose the latter.

I have an unfinished article in http://www.naggum.no/~erik/sgml/. it is
not particularly pedagogical, nor has it been polished at all. three
posters I presented at SGML '94 are under ftp://ftp.naggum.no/pub/SGML94.

| I agree, though, that DSSSL is a good example of an ISO standard "done
| right".

DSSSL is perhaps the single best standard I have seen come out of
ISO/JTC 1/SC 18 or SC 22, and I have seen a lot of them. it is unfortunate
that it was wasted on SGML. however, one may hope that DSSSL spawns some
serious redesign in SGML over the next decade. until then, read DSSSL to
find out about a very elegant solution to very complicated problems, and
design your own "input language". I have my own ideas, of course, and will
write them down during this fall.

#\Erik

Rolf Marvin B|e Lindgren

unread,
Jul 29, 1996, 3:00:00 AM7/29/96
to

[Patrick Stickler]

| Are you saying that it is harder to encode information, even for the
| single purpose of reuse alone, in SGML as opposed to e.g. TeX,
| t/nroff, Scribe, Postscript, etc?

I don't know if I understand what Erik means, but it sure is much easier
to write a LaTeX document class than to write an SGML DTD.

--

Rolf Lindgren | "The opinions expressed above are
Sofienberggt. 13b | not necessarily those of anyone"
N-0551 OSLO | rolf.l...@psykologi.uio.no

Thant Tessman

unread,
Jul 29, 1996, 3:00:00 AM7/29/96
to

Others have already addressed many of the points I wanted to. I just want
to pick a nit or two and then make more subjective remarks.

In article <31FA4C...@sonic.net>, "Ray S. Dillinger" <be...@sonic.net> wrote:

> [...] My programming style capitalizes heavily on [dynamic types],

> and on the ability to have nonlocal exits and closures.

SML supports closures. And although it isn't part of the standard proper,
SML/NJ supports a call/cc mechanism (and a very fancy threading
mechanism), and it is rumored that even MLWorks supports non-local exits
(one-shot continuations).

> Hm. I've always considered scheme's real strength to be the ability to
> define new primitives and have them just "work" with whatever types you
> throw at them.

As others have pointed out, SML's generic polymorphism and functors
provide you with this capability (and in a type-safe manner).


> I suspect yours
> capitalizes heavily on strengths of ML. So, both of us think we have
> the "best" language. And I guess both of us do, for our particular styles.

You've got me wrong. I think Scheme is great. I've done a lot of work
with Scheme and it is still my all-around favorite language. However, SML
does have some strengths over Scheme that may make it more apporopriate
for some of the projects I'm going to be working on and so I've been
looking into it. When working with SML, yeah I really miss macros, and
yeah, I really miss subtyping and all that that implies. My 'beef' is
with what are (IMHO) unfair criticisms of SML like those above.

As Paul Wilson alluded to, the interesting discussion lies in the
middle-ground between the dynamic (latent) type camp and the strong type
camp. Strong type systems will always be behind dynamic type systems in
their ability to elegantly express new conceptual structure. The converse
of this is that if this conceptual structure isn't incorporated into the
compiler, it cannot be used for optimization, and in fact is usually a
performance burden.

Yes, one can play all sorts of code transformation tricks in macro-land to
avoid as much of this burden as possible, and you personally may be able
to make your Scheme code approach within 5%-10% the performance of g++
code with much tweaking, (and yes I would call this difference tiny,) but
the fundamental problem doesn't go away. An application is not well-typed
merely because it runs.

When I talk about building a type system in Scheme, I'm talking about
imposing a structure on the system in order to manage the complexity of an
ever-changing application. I've got to build a system that multiple
programmers can extend safely and efficiently. SML has a real module
system and Scheme doesn't. Therefore, I stand by my claim that SML


promotes modularity and manages complexity better than Scheme.

***

But remember where I (and most other developers are coming from). I've
recently come up with ways to use C++ templates to implement tagged types
(before RTTI) and even a goofy form of closure and curry. I liberally use
envelope classes. I've even got an extendible system of data structures
with built-in mark-and-sweep GC. My ego swells at my own cleverness until
I think: What the fuck am I doing? These are supposed to be non-issues!

And now the world has embraced Java, mainly because it bears a cosmetic
resemblance to C++.

I want to build real, high-performance systems and I want to use a modern,
commercially-supported programming language. As far as I can tell, my
options are: C++ (ha ha), Scheme (Chez is excellent), Common Lisp (worth
serious consideration except that Scheme has spoiled me and every time I
try to read a book on CL I feel like puking), DylanWorks (eventually),
MLWorks (eventually, but sooner than DylanWorks), Erlang (?), ...

Any others?

Scheme and SML float to the top. Given my performance requirements, SML
may have an edge.

-thant

Patrick Stickler

unread,
Jul 29, 1996, 3:00:00 AM7/29/96
to

In article <30476290...@arcana.naggum.no>,

Erik Naggum <er...@naggum.no> wrote:
>[Patrick Stickler]
>
>| Having tracked the DSSSL standard from its inception, and having
>| worked in the SGML field for going on 8 years, I'm here to tell
>| you that DSSSL will certainly take the commercial publishing
>| world over (eventually), and probably the Web as well. As for the
>| "annoyance" of dealing with SGML, I'm willing to wager that either
>| (a) you've not done much work with SGML or (b) you were applying
>| it to a problem for which it was either ill suited or overkill. I
>| personally find SGML to make my life *much* easier and to remove
>| orders of magnitude more annoyances than it adds.
>
>you seem to need creds: I have been working with SGML since 1989, I
>maintained the SGML Repository at the University of Oslo for nearly 6
>years, I was a member of the ISO working group for nearly 5 years, and
>I have contributed some 1500 articles to comp.text.sgml over the same
>years.

I find that, although no guarantee of the validity or "correctness" of
a person's views, it helps if folks know that one's comments stem from
years of experience rather than days or hours of playing around with a
particular technology. I am, of course, quite familiar with your work
Erik, as would anyone having an even limited exposure to the SGML field,
and it is because of your credentials that I take extra time to respond
to your comments.

>my main goal in working with SGML was to find ways to represent
>information for arbitrary reuse (_one_ of which is printing) -- some
>means to let us humans encode information such that programs could
>deal with some of the complexity of the intuitive structures in our
>communication. my goal was most emphatically _not_ to put ink on paper
>or pixels on screens, and that is the only place where SGML has been
>widely used. over these years, my annoyances with SGML grew, and when
>I had gotten three chapters into a book on SGML (working title: "A
>Conceptual Introduction to SGML"), I realized that I had been willing
>to accept such a staggeringly large number of annoyances and flaws in
>this language that I could neither write further on my book nor tell
>people in any other way that SGML is the Right Thing, because it isn't.

I will certainly concede that SGML may not be the "ideal" technology
for describing and encoding *all* forms of human communication -- and
that it very well may not have met your ultimate needs as a technology,
but perhaps the fact that it *is* widely used in the publishing world
is a clear indication that it is a very good technology for that
subset form of human communication. Whether SGML is "the Right Thing"
depends on what one want's to do with it.

>SGML does have some good ideas, but they are neither exploited nor
>explored by the user community, and they drown in useless garbage that
>make the reuse of information coded in SGML harder than any other
>language that could be used.

I find this comment very difficult to swallow. Are you saying that it


is harder to encode information, even for the single purpose of reuse
alone, in SGML as opposed to e.g. TeX, t/nroff, Scribe, Postscript,

etc? Or that information in SGML is more difficult to use than any
other encoding scheme? Again, this depends on your needs and goals.
I am concerned that your criticisms may be appropriate from the perspective
of your higher goals, but may not be particularly appropriate within
the scope of publishing technology -- and, despite it's shortcomings,
SGML is the "best" thing going at the moment for lessening the cost
and complexity of publishing and providing a significant increase in
reuse and flexibility in the use of information in published titles.

>SGML's only actual forte is that it is a standard. the standard itself
>is horrendously complex and amazingly lacking in precision, making it
>an ordeal to study it and understand it _completely_, which about a
>dozen people did last time I checked (at the beginning of this year).

True. SGML *is* very complex, and I wish it were much less complex. There
are certainly many parts of SGML for which I lack complete understanding;
however, the parts that I do understand provide significant returns in
investment when applied to the problems I have on hand to solve. Just
because a technology is not perfect does not mean it is not useful, nor
in fact "the Right Thing" for solving *particular* problems in the
here and now.

>after having invested nearly 5 years of my life in SGML, I decided
>that it had no future outside of print shops and government contracts,

*Precisely*, by your own admission, SGML *has* a future in the printing
world -- and in fact *is* the future of the printing world. And it is
this future that DSSSL will fuel.

>and I could either waste my time and money not getting any of the
>necessary changes through the ISO "review" process, help people
>encode a structure in their information where they had even less clue
>and incentive to understand their own information than they do with
>databases, or do something fun and exciting and rewarding. I chose the
>latter.
>
>I have an unfinished article in http://www.naggum.no/~erik/sgml/.
>it is not particularly pedagogical, nor has it been polished
>at all. three posters I presented at SGML '94 are under
>ftp://ftp.naggum.no/pub/SGML94.

I hope to read these articles in the near future to get a better
understanding of where you are trying to go.

>| I agree, though, that DSSSL is a good example of an ISO standard
>| "done right".
>
>DSSSL is perhaps the single best standard I have seen come out of
>ISO/JTC 1/SC 18 or SC 22, and I have seen a lot of them. it is
>unfortunate that it was wasted on SGML. however, one may hope that
>DSSSL spawns some serious redesign in SGML over the next decade. until
>then, read DSSSL to find out about a very elegant solution to very
>complicated problems, and design your own "input language". I have my
>own ideas, of course, and will write them down during this fall.

I'm sure I'm not the only one waiting to see what the new dawn of
information technology will give birth to, but the majority of us
must use what is here now, and despite its shortcomings, SGML (and
DSSSL) is *it*.

I eagerly await to see your vision for the successor to SGML. I'm
sure it will be an improvement over the present technologies we must
slog onwards with.

My motivation for answering your post at length is that, given your
credentials, you have the potential to direct and influence individuals
coming into contact with SGML and DSSSL, and I would hope that before
filling their ears with your higher vision of information modelling
(however needed and valid) that you would ask yourself whether or
not that would do those individuals an injustice by steering them
away from a technology that would best address their *immediate*
needs.

One can only move towards perfection on a foundation of imperfection,
otherwise, we'd already be there. SGML and DSSSL are valid and useful
steps in that direction, and offer needed solutions now until we get
further down the path.

Regards,

Patrick Stickler

David Fox

unread,
Jul 30, 1996, 3:00:00 AM7/30/96
to

In article <4t8ag1$r...@ix.cs.uoregon.edu> bh...@ix.cs.uoregon.edu (B. Robert Helm) writes:

] > But who cares? James Clerk Maxwell was once lecturing on theories of light.


] > There are two general models for light, he said: particle and wave. People
] > used to think of light as a stream of tiny particles. But they are all dead.

] > If you see where I'm headed...
]
] Sorry, I don't. Are you suggesting Scheme v. ML == particle v. wave


] theory? My impression is that both models are still used intuitively
] under specific circumstances, even by physicists who know better.
] Under what circumstances, in your view, should one prefer Scheme over
] ML or an ML-like successor?

I think he means you don't try to change Scheme into ML in
comp.lang.scheme, you just stop reading comp.lang.scheme and start
reading comp.lang.ml. In a year or two you check the volume in
comp.lang.scheme, and if it is zero you did the right thing.
--
David Fox http://found.cs.nyu.edu/fox xoF divaD
NYU Media Research Lab f...@cs.nyu.edu baL hcraeseR aideM UYN

Robert Harper

unread,
Jul 30, 1996, 3:00:00 AM7/30/96
to

Thant Tessman wrote:
>
> SML does not produce a different implementation of a polymorphic routine
> on a per-type basis.
>

First, it makes no sense to state that a language does or does not
implement something in a certain way. Second, the TIL/ML compiler (PLDI
'96) does generate type-specific code using a technique called
intensional type analysis (POPL '95).

>
> You're probably right, but the real reason dynamically-typed languages


> have an advantage over statically-typed languages is because there is no

> one right type system. Safety and speed are very good things, but the


> most important thing about a type system is the semantic framework it
> provides for managing complexity. The biggest advantage Scheme has over
> SML is that it is possible to build new type systems, or type systems more
> appropriate for a given problem.
>

This discussion is confused. Statically typed languages completely
dominate dynamically typed languages in every respect. Why? Because
dynamically typed languages are statically typed languages that insist
on using precisely one (static) type (eg, the recursive type of Scheme
values), ignoring the richness of the rest of the type system. Put
another way, Scheme is but one tiny little corner of ML; if you want,
you can stay in that corner (face in), but most people prefer to take
advantage of the additional expressiveness available to them in ML.
(But you can choose to ignore it.)

> Also, Scheme is more fun to program in because Scheme tends to let you
> 'feel' your way to a working program, whereas SML forces you to think your

> way there. But we have to remember that they're both so far beyond C++
> that it's silly to argue about them.
>

There's truth to both statements. As to the former, the Scheme parser /
front end is biased towards embedding what is typed into the tiny Scheme
corner of the world, so it makes it simpler to use (there's only one
type, so no possiblity of type errors) but terrible to modify or
maintain (there's only one type, so no information about what's going on
is recorded in the code). As to the latter, no kidding!

Bob Harper

Sin-Yaw Wang

unread,
Jul 30, 1996, 3:00:00 AM7/30/96
to

Patrick Stickler wrote:

> In article <qijwwzrt2...@lambda.ai.mit.edu>,


> Olin Shivers <shi...@ai.mit.edu> wrote:
> > Scheme language development seems to have stalled. Why is Scheme
> > worth developing in, despite the absence of the features you list? Or
> > do you expect that Scheme will eventually include such features?
> >
> >I think the Scheme community may yet recover momentum. The folks down at
> >Rice are doing really interesting work with Scheme, Danvy has a draft R5RS,
> >and Indiana, as always, holds the torch high.
> > -Olin


I missed the 1st part of this discussion and would have to jump in like this. My apologies.

Scheme is a fine language for programming in the small, for concept communication, and for
embedded development. I personally think it is stupid for people to create VRML, HTML,
PostScript, Forth, TCL, or the likes. (Now, how many people left that I have not insulted
yet? :-) Every one of them should simply switch to Scheme, or some extension of it.

That said, Scheme is not a good language for large commercial applications. There is still
no standard libraries for Scheme that cover GUI, graphics, networking, database, etc. The
performance is next to impossbile to tune, or predict. Most importantly, too many
programmers (some very talented ones included) loath the Lisp-like syntax ("those parethesis
make me dizzy").

But this is fine. I like Scheme to stay in the academia and be pure. It is the place I
frequently come back to, after months of kludges and hacks. I think there are enough like me
to keep Scheme alive, well, and kicking.

--
Sin-Yaw Wang, sin...@cris.com

Matthias Blume

unread,
Jul 31, 1996, 3:00:00 AM7/31/96
to

In article <4t8ag1$r...@ix.cs.uoregon.edu> bh...@ix.cs.uoregon.edu (B. Robert Helm) writes:

] > But who cares? James Clerk Maxwell was once lecturing on theories of light.
] > There are two general models for light, he said: particle and wave. People
] > used to think of light as a stream of tiny particles. But they are all dead.
] > If you see where I'm headed...
]
] Sorry, I don't. Are you suggesting Scheme v. ML == particle v. wave
] theory? My impression is that both models are still used intuitively
] under specific circumstances, even by physicists who know better.
] Under what circumstances, in your view, should one prefer Scheme over
] ML or an ML-like successor?

I think he means you don't try to change Scheme into ML in
comp.lang.scheme, you just stop reading comp.lang.scheme and start
reading comp.lang.ml. In a year or two you check the volume in
comp.lang.scheme, and if it is zero you did the right thing.

You can also do what I do now: keep reading c.l.s. for its entertainment
value...

:-)

--
-Matthias

mathew

unread,
Jul 31, 1996, 3:00:00 AM7/31/96
to

Rolf Marvin B|e Lindgren <ro...@tag.uio.no> wrote:
> [Patrick Stickler]

> | Are you saying that it is harder to encode information, even for the
> | single purpose of reuse alone, in SGML as opposed to e.g. TeX,
> | t/nroff, Scribe, Postscript, etc?
>
> I don't know if I understand what Erik means, but it sure is much easier
> to write a LaTeX document class than to write an SGML DTD.

I'd guess that 90%+ of LaTeX users don't write new document styles; they
just write documents using the pre-defined styles available to them.

It ought to be the same for SGML, surely? Why would the average person
want to write a DTD?


mathew
--
http://www.pobox.com/~meta/

Matthias Blume

unread,
Aug 1, 1996, 3:00:00 AM8/1/96
to

In article <4tbes4$g...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:

Scheme lets you invent your own modularity mechanism, and your own
abstraction-layering techniques. I don't know how to write a metaobject
protocol for ML in ML, but I know how to write one for Scheme, in Scheme.

Really? I was under the impression that Scheme is not OO. Any MOP
you can write for Scheme you can also write for ML.

Until ML has a nice object system and a really, really nice recursive
module system, I'm not buying it.

None of those are available in Scheme either.

(I know, people are working on those
thigns, and have been for years, and they're making progress. In the
meantime, we can easily add macros, metaobjects, and funky templates
to Scheme without batting an eye. I think ML's type system would be
a pain in the ass for what we want to do.)

Well, I don't know what you want to do, but I found that whenever I
thought the ML type system to be a pain in any one of my body parts I
was doing something stupid, something that shouldn't be done in the
first place. (Of course, this might just be a lack of imagination on
my part that I can't think of smart things to do which don't work with
ML.)

It seems to me that there's an unfortunate split between the strong typing
camp and the dynamic typing camp. Anybody who knows The Truth knows that
strong typing can be great 95% of the time, but is a major obstacle
5% of the time. (Pick your own probabilities---it might be 80/20 or
99/1, but the point stands.)

It seems to be quite close to 100/0 for me.

Type theorists are always behind the curve, and for fundamental
reasons always will be.

This depends on which direction one thinks progress is being made.
Type theorists might very well be ahead of the curve. I don't know
any fundamental reasons why *that* should always be, though.

Too many type system designers just don't like to admit that their wonderful
type systems are only a 95% solution, and that 5% of the time you're
simply hamstrung.

Maybe this is because it is simply not true for them. Why admit
something that is wrong according to your own experience?

>SML does not produce a different implementation of a polymorphic routine
>on a per-type basis.

If you can't use eval, or *macros* you're toast.

Ooops. So you say: when you use Scheme, you are toast. Neither eval
nor macros are part of Scheme (yet). In the case of eval I wish it
would stay that way. Macros (the hygienic variety) is kinda
interesting, though.

>You're probably right, but the real reason dynamically-typed languages
>have an advantage over statically-typed languages is because there is no
>one right type system.

Precisely. You should be able to build your own type system for your


own domain-specific programming environment, which is what all Serious
Programs evolve into.

Whatever type system you think you can build in Scheme -- the same can
easily be done in ML. As Bob Harper pointed out in a different reply
-- Scheme is a *sub*set of ML, after all -- it is ML restricted to a
pre-defined recursive datatype!

Right. The problem with Scheme for Real Work is that it doesn't have
the right framework for building your own type system. (It's a lot of
work to erect a flexible, extensible type system framework, and *then*
erect your own domain-specific type system.) The problem
with ML for Real Work is that it doesn't have the right type system,
and won't let you build your own.

Why such cheap shots? ML has the right type system, at least for some
people, and they even get work done. And anything that can be done in
Scheme can obviously also be done in ML.

--
-Matthias

Tom I Helbekkmo

unread,
Aug 1, 1996, 3:00:00 AM8/1/96
to

[mathew]

> Why would the average person want to write a DTD?

He or she wouldn't normally. However, when there is a need to express
an information complex or idea structure for which there is no common
standard DTD, it should be possible -- even natural -- to communicate
the structure as well as the content of the message clearly.

-tih
--
Tom Ivar Helbekkmo
t...@Hamartun.Priv.NO

Shriram Krishnamurthi

unread,
Aug 3, 1996, 3:00:00 AM8/3/96
to

bl...@zayin.cs.princeton.edu (Matthias Blume) wrote:

> Why such cheap shots? ML has the right type system, at least for some
> people, and they even get work done. And anything that can be done in
> Scheme can obviously also be done in ML.

Why such cheap shots? Scheme has the right type system, at least for


some people, and they even get work done. And anything that can be

done in ML can obviously also be done in Scheme.

(No? I'll await your expressiveness argument in my mailbox. TeX,
LaTeX and PS are all welcome.)

Before you accuse me of quoting you out of context, here's what Paul
Wilson said that you responded to:

> Right. The problem with Scheme for Real Work is that it doesn't have
> the right framework for building your own type system. (It's a lot of
> work to erect a flexible, extensible type system framework, and *then*
> erect your own domain-specific type system.) The problem
> with ML for Real Work is that it doesn't have the right type system,
> and won't let you build your own.

Sounds a lot like, "Scheme doesn't have enough of a framework for a
type system, and ML doesn't have the right one for me". My own
experiences with using H-M variants and other "type" systems has been
similar; I like the information in "types", but don't like that of
H-M, so I use SBA variants. Cheap shot?

Contrary to what your newsreader probably says, this _is_
comp.lang.scheme. I'd be as happy as anyone here to hear out any
_new_ arguments you've got. What are they?

'shriram

Matthias Blume

unread,
Aug 3, 1996, 3:00:00 AM8/3/96
to

In article <j7vbugs...@europa.cs.rice.edu> shr...@europa.rice.edu (Shriram Krishnamurthi) writes:

bl...@zayin.cs.princeton.edu (Matthias Blume) wrote:

> Why such cheap shots? ML has the right type system, at least for some
> people, and they even get work done. And anything that can be done in
> Scheme can obviously also be done in ML.

Why such cheap shots? Scheme has the right type system, at least for
some people, and they even get work done. And anything that can be
done in ML can obviously also be done in Scheme.

I didn't say anything to the contrary. And I wasn't making a cheap
shot either.

Contrary to what your newsreader probably says, this _is_
comp.lang.scheme. I'd be as happy as anyone here to hear out any
_new_ arguments you've got. What are they?

I didn't claim to have any _new_ arguments. The old one I've got are
sufficient for me. I can certainly say I know both languages fairly
well, and I've come a long way of liking one more than the other. And
it is precisely because of its type system. If this isn't convincing
to you -- so be it.

And `Cheap shot?' you ask? Maybe I should have said: `Unfounded
assertion' as in `The problem with ML for Real Work is that it doesn't
have the right type system, ... ', which is certainly not true,
because Real Work does get done in ML.

--
-Matthias

R. Kent Dybvig

unread,
Aug 4, 1996, 3:00:00 AM8/4/96
to

Robert Harper <r...@cs.cmu.edu> writes:

>This discussion is confused. Statically typed languages completely
>dominate dynamically typed languages in every respect. Why? Because
>dynamically typed languages are statically typed languages that insist
>on using precisely one (static) type (eg, the recursive type of Scheme
>values), ignoring the richness of the rest of the type system. Put
>another way, Scheme is but one tiny little corner of ML; if you want,
>you can stay in that corner (face in), but most people prefer to take
>advantage of the additional expressiveness available to them in ML.
>(But you can choose to ignore it.)

This argument is true only in a very strange sense. If it were true in
a straightforward sense, all Scheme programs would transliterate
trivially into (natural) ML programs, but they don't. Transliterating
Scheme programs into ML programs with one type involves making type
tags explicit in the source program, which is not pretty and definitely
not useful.

A wide misconception among (or misstatement by) static typing
proponents is that Scheme is not strongly typed. In fact, it is, but
the types are checked at run time, allowing fewer programs to be
rejected, which makes Scheme more rather than less general, and makes
ML "but one tiny little corner" of Scheme, if we want to resort to such
pejorative statements. Static typing is a useful tool for structuring
code and facilitating early detection of some program errors. It does
make a language richer in the sense that it allows expresion of more
static types (of course), but not in the more obvious sense that it
allows more algorithms to be expressed easily.

Kent

B. Robert Helm

unread,
Aug 4, 1996, 3:00:00 AM8/4/96
to

In article <4u38ip$b...@garbo.cs.indiana.edu>,

R. Kent Dybvig <d...@cs.indiana.edu> wrote:
>
>A wide misconception among (or misstatement by) static typing
>proponents is that Scheme is not strongly typed. In fact, it is, but
>the types are checked at run time, allowing fewer programs to be
>rejected, which makes Scheme more rather than less general, and makes
>ML "but one tiny little corner" of Scheme, if we want to resort to such
>pejorative statements.

Well, Scheme is strongly typed in the sense that it detects all
violations of its _own_ type system. However, there is no convenient,
standard way to keep it from violating _my_ type system. To do that
in R4RS/IEEE Scheme, I have to write code to store and check type
tags, just as I would in the hypothetical "one-type" ML translation of
my Scheme program.


Brian Harvey

unread,
Aug 5, 1996, 3:00:00 AM8/5/96
to

d...@cs.indiana.edu (R. Kent Dybvig) writes:
>A wide misconception among (or misstatement by) static typing
>proponents is that Scheme is not strongly typed. In fact, it is, but
>the types are checked at run time [...]

Is there some language in which that isn't true? I mean, if you say
(+ 3 'foo) in any language, surely an error must result, right?

[This is an ingenuous request for information, not a disguised argument
on either side of the Scheme/ML debate.]

Oliver Laumann

unread,
Aug 5, 1996, 3:00:00 AM8/5/96
to

> I mean, if you say (+ 3 'foo) in any language, surely an error must
> result, right?

% perl
print 3 + 'foo';
3

Yeah, right... :-)

Robert Harper

unread,
Aug 5, 1996, 3:00:00 AM8/5/96
to

R. Kent Dybvig wrote:
>
> ...

>
> This argument is true only in a very strange sense. If it were true in
> a straightforward sense, all Scheme programs would transliterate
> trivially into (natural) ML programs, but they don't. Transliterating
> Scheme programs into ML programs with one type involves making type
> tags explicit in the source program, which is not pretty and definitely
> not useful.
>

All Scheme programs *do* transliterate directly into ML. It is a very
simple matter to write a parser that translates Scheme code into ML
code. Every Scheme program will have type sv, where sv is a recursive
datatype of the form

datatype sv = Nil | Cons of sv * sv | Func of sv list -> sv | ...

The translation will make all tag checking and tag creation explicit,
precisely as in a Scheme compiler. For example,

fun car (Cons (a, _)) = a
| car _ = raise RuntimeTypeError

and so forth. It is entirely faithful to the Scheme semantics, and can
be optimized precisely the same way as a Scheme compiler might.

As long as you stick with writing Scheme code, you'll never know the
difference. As soon as you try to step outside the strictures of Scheme
(as you certainly will), you will notice the overhead of all the tag
manipulations, and move instead to programming with many types, rather
than one type. In truth few people actually believe in the doctrine of
one true type. As soon as you question this article of faith, you
quickly realize that you prefer to have a much more refined type system
as exemplified by ML. And you realize that all this tag hacking is
utterly pointless.

> A wide misconception among (or misstatement by) static typing
> proponents is that Scheme is not strongly typed. In fact, it is, but

> the types are checked at run time, allowing fewer programs to be
> rejected, which makes Scheme more rather than less general, and makes
> ML "but one tiny little corner" of Scheme, if we want to resort to such

> pejorative statements. Static typing is a useful tool for structuring
> code and facilitating early detection of some program errors. It does
> make a language richer in the sense that it allows expresion of more
> static types (of course), but not in the more obvious sense that it
> allows more algorithms to be expressed easily.
>

I have always maintained that Scheme is a typed language. In fact,
Scheme is a statically typed language. But since it has only one type,
the static checking is trivialized.

Tag checking is not type checking. (Sorry to quibble about terminology,
but we have to make distinctions if we are to get anywhere.) Tags
cannot possibly supplant static types. For example, you cannot achieve
proper data abstraction in Scheme precisely because data abstraction is
a matter of static typing, and no amount of tag hacking can replace it.

Besides the fact that there are only a fixed set of tags in Scheme,
there is a further weakness of tag-based pseudo-replacements for a type
system: enforcement *must* be computable. This is a very serious
limitation not shared by static typing disciplines. Even if we stay
within decidable conditions, the run-time overheads of repeated tag
checks on values (not to mention the very association of tags with
values) are preposterous.

In anticipation of the obvious remark, let me say also that languages
with the ability to generate "new" tags at run-time are ALSO static type
disciplines, and perfectly transliteratable into ML along precisely the
same lines.

Summary: ML is strictly more expressive than Scheme because Scheme can
be faithfully transliterated into ML, whereas the reverse is impossible.

> Kent

Bob

Steven L Jenkins

unread,
Aug 5, 1996, 3:00:00 AM8/5/96
to

In article <4u4v2c$8...@agate.berkeley.edu>,

Brian Harvey <b...@anarres.CS.Berkeley.EDU> wrote:
>d...@cs.indiana.edu (R. Kent Dybvig) writes:
>>A wide misconception among (or misstatement by) static typing
>>proponents is that Scheme is not strongly typed. In fact, it is, but
>>the types are checked at run time [...]
>
>Is there some language in which that isn't true? I mean, if you say

>(+ 3 'foo) in any language, surely an error must result, right?

The successor to the 'B' language allows this: for example,

vincent% cat foo.c

#include <math.h>
#include <stdio.h>
main() {printf("%d\n", sin("foo"));}
vincent% cc foo.c -lm
vincent% ./a.out
2147465140

And some people even use this language (or so I hear).


Mitchell Wand

unread,
Aug 5, 1996, 3:00:00 AM8/5/96
to

>>>>> On 5 Aug 1996 14:05:00 GMT, b...@anarres.CS.Berkeley.EDU (Brian Harvey) said:

BH> d...@cs.indiana.edu (R. Kent Dybvig) writes:
>> A wide misconception among (or misstatement by) static typing
>> proponents is that Scheme is not strongly typed. In fact, it is, but
>> the types are checked at run time [...]

BH> Is there some language in which that isn't true? I mean, if you say
BH> (+ 3 'foo) in any language, surely an error must result, right?

BH> [This is an ingenuous request for information, not a disguised argument
BH> on either side of the Scheme/ML debate.]

OK, I'll try to respond to the request for information, and not to start
another argument.

Let's consider C, Scheme, and ML . Of these languages, only Scheme has
symbols; to make the comparison fairer, let's consider (+ 3 "foo") instead.

Actually, the more interesting question is what happens when you try to
execute

(begin (print "starting!") (+ 3 "foo"))

or its equivalent in these languages.

C is an untyped language with some static type checking. If the variable x
somehow contained the string "foo", then 3+x would be rejected (I think). In
particular, it would not print "starting!".

But if you changed the expression to

3 + (int)x

{casting the variable x to be an integer}, then the program is legal. It
would print "starting!", and _something_ would happen. It might be an error,
or it might be some bizarre value that would cause an error later on if this
were a larger program. So C is a language in which Brian's hypothesis is
false (at least if you permit casting).

Scheme is a latently typed language; executing the program above would print
"starting" and then would report an error.

ML is a statically typed language. The program above, when translated into
ML, would be rejected (just like the C program). In particular, it would not
print "starting!".

Does this help?

--Mitch

Eric Jeschke

unread,
Aug 5, 1996, 3:00:00 AM8/5/96
to

Sin-Yaw Wang <sin...@cris.com> writes:

| That said, Scheme is not a good language for large commercial applications. There is still
| no standard libraries for Scheme that cover GUI, graphics, networking, database, etc. The
| performance is next to impossbile to tune, or predict. Most importantly, too many
| programmers (some very talented ones included) loath the Lisp-like syntax ("those parethesis
| make me dizzy").


I do understand how the syntax could be a turn-off for some, but
I've never understood why there aren't different kinds of parsers
for the same Scheme run-time system.

--
Dr. Eric Jeschke | Visiting Research Associate
jes...@cs.indiana.edu | Indiana University
| Computer Science Department
http://www.cs.indiana.edu/hyplan/jeschke

Eric Jeschke

unread,
Aug 5, 1996, 3:00:00 AM8/5/96
to

"Ray S. Dillinger" <be...@sonic.net> writes:
[stuff deleted]
"| "are passed as data, dynamic typing is agreed to be superior. The smarter
"| "compilers get (and the more complex programs get) the more I expect to see
"| "dynamic typing in production languages.

Witness the Run-Time Type Information stuff being added to C++ ...

Erik Naggum

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

[Patrick Stickler]

| I will certainly concede that SGML may not be the "ideal" technology
| for describing and encoding *all* forms of human communication -- and
| that it very well may not have met your ultimate needs as a technology,
| but perhaps the fact that it *is* widely used in the publishing world
| is a clear indication that it is a very good technology for that subset
| form of human communication. Whether SGML is "the Right Thing" depends
| on what one want's to do with it.

I get an uneasy feeling from reading your article that whatever anybody
might say against choosing SGML will be dismissed. I also get the
impression that you have missed my points completely. on the off chance
that I can show you that information is more constrained with than it was
without SGML, let me try, anyway.

first, there are all sorts of reasons why something becomes widely used.
time and again we see the argument that because many people use something
it must be good, but this is a non sequitur: each individual does in fact
not choose something because it is _good_, they buy it because it is the
least expensive of the options that satisfy a need. often, this is the
direct opposite of high quality, so how come it suddenly turns into "good"
when enough people do it? also, the technologies that preceded SGML in the
publishing world were also "very good technologies" at the time, and we all
know how hard it was to convince them that SGML should be used. SGML has
been a political vehicle for a very long time, not a technical one.

second, the graphics and publishing industries are well known for huge
costs and requiring arbitrarily much work on the body of text in their
production cycles, and this naturally leads to a different attitude towards
information than if information were regarded as valuable in its own right,
to be preserved. these industries view information as a means to an end --
their making tons of money off of dead flat trees, to put it bluntly, and
suggestions to allow other kinds of access to the information are hostile
to them, unless they can themselves control the flow of money.

SGML once was about wrestling the control over the information out of the
hands of the software vendors. I'm not sure whether that happened, but if
it does, we are very likely to end up with the control passed to people who
are even _less_ likely to want information to be reused and accessible.

ironically, information that used to exist in draft form, manually
corrected after proof runs, etc, were "reusable" in a cheap and straight
forward way: just keyboard it again. (even today, re-keyboarding is often
much cheaper than using experts at "legacy data conversion".) after some
information has been turned into SGML, people think that it should be cheap
and easy to convert into other formats (not the least because of the all
the intensive marketing efforts by SGML's many proponents), and guess what
-- it isn't. we can convert between simple formatting languages with great
ease, but as soon as we attempt to convert between higher-level languages,
we lose. unless it's done right, and that is precisely what today's SGML
aficionados don't -- they optimize their document type definitions for the
needs to which they put the information, not the needs of the information.

| Are you saying that it is harder to encode information, even for the
| single purpose of reuse alone, in SGML as opposed to e.g. TeX, t/nroff,
| Scribe, Postscript, etc?

ah, but this is the crux of the matter. compare SGML to other markup
languages, and you have already lost sight of the bigger picture, while
pretending to win the battle. SGML is not a markup language, despite its
misleading name. SGML is an information structuring language, and a lousy
one at that. SGML wins in comparison with markup languages because the
other markup languages argue "nolo contendere" in areas where SGML has a
forte or two.

| Or that information in SGML is more difficult to use than any other
| encoding scheme? Again, this depends on your needs and goals.

well, I'm sure there is a need and a goal where it is less difficult. the
question is whether that need and goal are relevant. fact: it is extremely
difficult to get information into SGML if the author did not explicitly
specify the roles of the various elements of the information or used a
consistent format for various kinds of information. fact: once the
information is in SGML, it is extremely difficult to improve on the
document type (and associated software) without invalidating legacy
information. both of these are _more_ difficult operations than in any
other reasonable storage format.

there are a few reasons for this. first, the storage formats that are even
more widely used than SGML (understatement) have so many users behind them
that demand interoperability within a short time frame that documents move
easily between major packages in the same generation. there is also a
marketing philosophy at work here: if you make your competitors' formats
easy to read into your own system, you can grab their customers by the
balls (files). that is not going to happen with SGML, not being a format
that any particular company will have a competitive advantage using.
second, converting between document types is extremely hard, and might well
_require_ the power that DSSSL embodies. third, each document type is its
own software world, as well. the tendency among the new generation of
programmers to be clueless idiots who care only for immediate gratification
at the cost of breaking every standard and convention in sight, means that
the clean separation between document type definition as specification and
the software implementing it, is no longer a valid approach. users of the
document type will also tend to use "features" in the software that were
never meant to be. SGML is too lax to handle modern users and programmers.

this is getting too long. I don't have time to answer the rest now, and
not at all time to make this shorter. I'll have to write more on this in
my more formal articles and put them up at my web site. I'll post a short
notice here as work progresses.

#\Erik

Marshall Abrams

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

In article <32061C...@cs.cmu.edu>, Robert Harper <r...@cs.cmu.edu> wrote:
>All Scheme programs *do* transliterate directly into ML. It is a very
>simple matter to write a parser that translates Scheme code into ML
>code. Every Scheme program will have type sv, where sv is a recursive
>datatype of the form
>
> datatype sv = Nil | Cons of sv * sv | Func of sv list -> sv | ...

Yes--I did understand earlier in the thread; this is what I
thought was being claimed. So anything I can do easily in Scheme,
I do easily in ML....as long as I first write the Scheme
datatype and all the Scheme functions. (Not to mention the fact that
the ML version will be a lot uglier....Oh, yeah, unless I write a
parser.)

There's a sense of "expressiveness" according to which you're of
course correct. Seems like there's a looser, more colloquial
sense in which you're not.

I personally have a deep respect and affection for both Scheme
and ML. My ambivalence about their conflicting strengths and
weaknesses is what makes this thread as interesting as it is to
me. But I do think that the two languages each have
strengths and weakenesses in their fundamental paradigms.

(My apologies to people like Jeff who may have heard all this
before too many times. Couldn't help myself.)


--
Marshall Abrams work: mab...@smgusa.com
ab...@midway.uchicago.edu (312) 255-4107
The World Wide Web means never having to buy another diskette;
AOL, GNN, and Compuserve are my suppliers.

Paul Wilson

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

In article <32061C...@cs.cmu.edu>, Robert Harper <r...@cs.cmu.edu> wrote:
>R. Kent Dybvig wrote:
>>
>> ...
>>
>> This argument is true only in a very strange sense. If it were true in
>> a straightforward sense, all Scheme programs would transliterate
>> trivially into (natural) ML programs, but they don't. Transliterating
>> Scheme programs into ML programs with one type involves making type
>> tags explicit in the source program, which is not pretty and definitely
>> not useful.
>>
>
>All Scheme programs *do* transliterate directly into ML. It is a very
>simple matter to write a parser that translates Scheme code into ML
>code. Every Scheme program will have type sv, where sv is a recursive
>datatype of the form

Bob, Scheme already has a Scheme parser. This makes it very handy for
my purposes. It also has a Scheme reader, which is a different thing,
and is also handy for my purposes.

One of the reasons to use Scheme is that it already implements Scheme.
This seems like an advantage to me.

The fact that you can *translate* Scheme into ML is very high on my
list of uninteresting facts.

To clarify what I said earlier, I take macros to be part of Scheme.
Sure, they're not part of the R4RS *required* functionality, but essentially
all Scheme systems provide them, and you can use them to bootstrap
the Indiana implementation of hygeinic syntax-case. And good
implementations of Scheme will support at least syntax-rules macros
Real Soon Now if they don't now.

These things are crucial for my purposes.

Scheme has macros, ML doesn't. You can write an excellent metaobject
protocol more easily with syntax-case than with any other language support
I know of.

My understanding is that ML implementations don't support macros, and
that macro support is more difficult for ML than it needs to be because
ML has a more complex surface syntax, which makes it hard to do what
Scheme does.

Scheme has a two-level *transformational* grammar. This is very handy
for writing code transformationally. ML compilers usually use
nice, clean, transformational techniques internally, but make it much
more difficult than Scheme does to use transformational techniques
in normal, portable code, and to implement higher-level constructs
that manipulate scope.

To get this functionality for ML, you'd have to clone the reader,
the parser, and the macro system, as well as a lot of basic data
structures. Maybe you could do it, but it's not a trivial
"transliteration" by any means. You're welcome to try it, and I
think that would be interesting, but for those of us who are not
particularly wedded to ML it's not necessarily worth the trouble.
(E.g., why should Olin clone this much of Scheme when he can use Scheme
for scsh? Maybe ML with these nifty features would be a better language
than Scheme, maybe not, but that's not the point. The point is that
for some purposes, Scheme is a better language than ML right now.
ML people don't seem to want to admit that there might be *any*
purpose for which Scheme is superior.)

> [...]


>Summary: ML is strictly more expressive than Scheme because Scheme can
>be faithfully transliterated into ML, whereas the reverse is impossible.

No. Scheme has a transformational grammar which must be *translated* into
ML, not just transliterated. Its transformational grammar is strictly
more powerful than ML's grammar, for some very deep reasons, and in some
very useful ways.

When you've cloned define-syntax and syntax-case for ML (and demonstrated
than ML's surface syntax doesn't get in the way of writing metaobject
protocols, record definition facilities, control constructs, parameterized
module systems with inheritance, etc., *in the language*) come back and
talk to us again.

BTW, I am not hostile to ML. Far from it. I *like* ML. My earlier
posting pointed out weaknesses in Scheme as well as ML, and I said
that I thought it was a shame that there's such a split between the
Lisp/Scheme camp and the ML/FP camp.

What I don't like is ML bigots in comp.lang.scheme sneering at Scheme
as though everybody in this group was ignorant of basic issues in
programming language design. Some of us are tired of being told
we're out of date by people who still don't "get it" about things like
macros.

Even if we were that ignorant, sneering is not appropriate, and
sneerers should expect some sneering back.

Please read Chomsky's 1957 _Syntactic_Structures_ before talking about how
easy it is to translate Scheme into ML. (For "phrase structure grammar"
in Chomsky, think "context free grammar," and then think about ML syntax.)

Scheme's Lisp heritage is important. Lisp had a transformational
grammar decades ago. Unfortunately, Lisp's transformational component
was broken. Scheme has similar surface syntax, but a deeply different
and more righteous transformational component.

Many language designers seem to think that Lisp's macro system was
just a hack, or a mistake. They are wrong. Lisp's macro system was
broken, but the idea was basically right, and recent Scheme macro
systems show the way to get the power without the bugs. Most languages
are stuck at the wrong level in the Chomsky hierarchy, because computer
scientists latched onto CFG's without realizing what it implies.

Transformational grammars are much more interesting theoretically, and
far more useful. Computer scientists like the tractability of CFG's,
but have mostly missed the fact that there are classes of
transformational grammars that are eminently tractable while being
far more expressive than CFG's. (They never really "got" Chomsky---just
ripped off the lower levels of his hierarchy and obsessed about them
for decades, reifying broken syntax (CFG's) as the sine qua non of
programming languages. So now we have LALR(k) and all that rot, and
we don't even seem to have a name for what Scheme does.)

BTW, I'm not married to Scheme's particular surface syntax, but I see why
it is the way it is. Any language that is not designed with macros
in mind from the start is broken, in my view.

--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wil...@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)

Mitchell Wand

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

>>>>> On Mon, 05 Aug 1996 12:07:31 -0400, Robert Harper <r...@cs.cmu.edu> said:

RH> All Scheme programs *do* transliterate directly into ML. It is a very
RH> simple matter to write a parser that translates Scheme code into ML
RH> code. Every Scheme program will have type sv, where sv is a recursive
RH> datatype of the form

RH> datatype sv = Nil | Cons of sv * sv | Func of sv list -> sv | ...

RH> The translation will make all tag checking and tag creation explicit,
RH> precisely as in a Scheme compiler. For example,

RH> fun car (Cons (a, _)) = a
RH> | car _ = raise RuntimeTypeError

RH> and so forth. It is entirely faithful to the Scheme semantics, and can
RH> be optimized precisely the same way as a Scheme compiler might.

RH> I have always maintained that Scheme is a typed language. In fact,
RH> Scheme is a statically typed language. But since it has only one type,
RH> the static checking is trivialized.

RH> Tag checking is not type checking. (Sorry to quibble about terminology,
RH> but we have to make distinctions if we are to get anywhere.) Tags
RH> cannot possibly supplant static types. For example, you cannot achieve
RH> proper data abstraction in Scheme precisely because data abstraction is
RH> a matter of static typing, and no amount of tag hacking can replace it.

RH> Summary: ML is strictly more expressive than Scheme because Scheme can
RH> be faithfully transliterated into ML, whereas the reverse is impossible.

OK, Bob, I was with you up until the very end. The idea that Scheme can be
translated into a "tiny corner" of ML, using the sv type is probably one with
which the readers of this group are unfamiliar. But I suspect that the same
readers have in mind a simple translation of ML into Scheme: just change ML's
bizarre (*grin*) syntax into parentheses, and forget about the type checking.
Instead, just check tags at primitive operations. Then any legal ML program
becomes a legal Scheme program; pre-execution type checking turns into
run-time tag-checking.

Now, this translation has obvious flaws: as you point out, it introduces
bunches of useless tag-checks that will have to be removed by analysis
(*grin*), and it does not address features of ML that lots of folks find
useful, like pattern-matching, exceptions, modules, etc.

But at the "ordinary functional programming" level, this seems to be a
reasonable translation.

So why do you say "the reverse is impossible"? Are the some additional
criteria that you have not elucidated?

--Mitch


Brian Harvey

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

wa...@delphi.ccs.neu.edu (Mitchell Wand) writes:
>3 + (int)x
> [...]
>Does this help?

It sure does. How embarrassing -- it's not as if I don't use C all the
time! Maybe now I'll be a little more sympathetic with my students who
seem to forget all the ideas from SICP as soon as they start programming
in C. :-)

Thanks...

R. Kent Dybvig

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

>Summary: ML is strictly more expressive than Scheme because Scheme can
>be faithfully transliterated into ML, whereas the reverse is impossible.

Is your claim that Scheme can be faithfully transliterated into ML or
that Scheme programs can be faithfully transliterated into ML
programs? If the former, I'm not sure what you mean. If the latter,
then I'd love to see the counter example of an ML program that cannot
be faithfully transliterated into a Scheme program. Actually, since
this discussion is about static vs. dynamic typing and not about other
distinctions between ML and Scheme, I'd love to see the statically
typed program that cannot be faithfully transliterated into a
dynamically typed program, given the same control structures and
run-time support. In reality, all statically typed programs *are*
dynamically typed programs, i.e., no translation is necessary. That's
what I consider a straightforward transliteration. I do not consider
making the run-time type (sorry) tags explicit a straightforward
transliteration.

Static types can be fun, and they allow you to say (express) more about
a given program, but I disagree that they allow you to express more
programs, which is the more obvious meaning of expressiveness. Indeed,
static typing prevents some forms from being programs, even if they
would run correctly in a dynamically typed setting.

Perhaps your claim is that all Scheme nonprograms can be faithfully
transliterated into ML nonprograms, but that not all ML nonprograms can
be faithfully transliterated into Scheme nonprograms. If this is the
case, then I agree, and I also agree that this is useful in some cases
(but wasteful in others).

By the way, contrary to your unbased assumption, I have of course
programmed in ML and other typed languages. I found that the types
distracted me from more important aspects of programming (yes, there
are other aspects of programming!) and unproductively limited my
programming style. I even enjoyed the hours I spent crafting clever
types, but I eventually realized that I was wasting more time than I
was saving.

Paul Wilson

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

In article <BLUME.96A...@zayin.cs.princeton.edu>,

Matthias Blume <bl...@zayin.cs.princeton.edu> wrote:
>In article <j7vbugs...@europa.cs.rice.edu> shr...@europa.rice.edu (Shriram Krishnamurthi) writes:
>
> bl...@zayin.cs.princeton.edu (Matthias Blume) wrote:
>
> > Why such cheap shots? ML has the right type system, at least for some
> > people, and they even get work done. And anything that can be done in
> > Scheme can obviously also be done in ML.
>
> Why such cheap shots? Scheme has the right type system, at least for
> some people, and they even get work done. And anything that can be
> done in ML can obviously also be done in Scheme.
>
>I didn't say anything to the contrary. And I wasn't making a cheap
>shot either.

Keep in mind that I said that ML may indeed have the right type system
for most people most of the time, and that your mileage may vary.
If you're happy with ML, I can respect that and be happy for you.

I just happen to favor certain programming techniques that Scheme
makes relatively easy, and ML doesn't. They involve things like
macros.

I like having a system where more of the system itself is exposed
and can be customized. I like having a customizable compiler,
which is what macros give you in a *portable* way---you don't
have to get inside a particular compiler to do a lot of compilerly
things.

I'm not saying Scheme is optimal for this, which is why we're developing
RScheme, but I'd argue that it's much better than ML. For this.

I am not impressed by the arguments that Scheme is essentially a subset
of ML, for two reasons:

1. Scheme is far more grammatically flexible than ML, at a deep
level, even if (and actually because) its surface syntax is
simpler and superficially more rigid.

2. I'm not convinced Hindley-Milner type systems are the right
thing. They make certain syntactic commitments as to what
the lines of modularity are in a program, and they seem to
interfere, in general, with typing issues I want to address
by other means.

I may be wrong about #2, but nobody has shown me that. You may be
able to fit H-M type inference into the kind of framework I want,
but I *know* I can fit Scheme into the kind of framework I want.

Later these issues may well turn out not to be problematic, but
starting from Scheme gives you a lot of flexibility.

If I'm going to build my own type system anyway (which I am) I
don't want to have to fit it into somebody else's preconceived
framework of the Right Thing. And even if what I want is basically
compatible with what ML is, I don't like system design philosophies
that keep me from getting at the things I may need to change to
smooth over stupid little incompatibilities. I don't like
sealed-off compilers, or dictated type systems.

Maybe I'm unusual---a professional driver on a closed course---and
maybe the tradeoffs are different from most people's.

On the other hand, I happen to think that more people should program
the way I do, and that the boundary between application programmers and
system programmers is too stark and too enforced in most languages
and systems. More people should be writing software system generators
and using those to generate most of their application code. Scheme
has interesting features that support that, within the language.
ML does not---you'd have to emulate Scheme's features to get those
benefits. Why bother?

> Contrary to what your newsreader probably says, this _is_
> comp.lang.scheme. I'd be as happy as anyone here to hear out any
> _new_ arguments you've got. What are they?
>
>I didn't claim to have any _new_ arguments. The old one I've got are
>sufficient for me. I can certainly say I know both languages fairly
>well, and I've come a long way of liking one more than the other. And
>it is precisely because of its type system. If this isn't convincing
>to you -- so be it.

It is not.

>And `Cheap shot?' you ask? Maybe I should have said: `Unfounded
>assertion' as in `The problem with ML for Real Work is that it doesn't
>have the right type system, ... ', which is certainly not true,
>because Real Work does get done in ML.

If you actually read the rest of my posting, you'll note that I said
that ML's type system is very nice, as far as it goes, and that for
some people it may be perfectly sufficient. For me it's not.
I think I also said that I'm not completely happy with Scheme because
it doesn't provide you with a medium-level framework for doing some
of the things that ML does. I'd like static typing, sometimes. It's
useful. I just don't want it all the time, and I don't want to have
to emulate Scheme to get around it.

I'm also willing to entertain the notion that ML's type system is just
great for many people all of the time, and for most of the rest most of
the time. As I've said before, I *like* ML. I think it's a beautiful and
interesting language, and I may well steal features from it for my eventual
Dream Language.

But I'm not sure I can buy H-M types all the way. I may have to bypass
them to build the type system of my dreams, and build a similar-but-different
type system on top of that. In which case, I'm happier using Scheme.
(I'm not arguing that ultimately I won't use a good ML compiler as a
back end, to make it possible to express things I can't express in
portable Scheme---particularly strong typing of very low-level types.
But there are already Scheme compilers that let me do that, too, like
RScheme's compiler and most of the high-quality compilers. Sometimes
"portability" in the sense of "can be ported without too much work" is
more important than "portability" in the sense of "can be translated
into a strictly portable language". Often de facto standard system
designs are more important than official language specs.)

Some of us are here in comp.lang.scheme because we like Scheme,
or because we like the system design philosophy underlying the Scheme
implementations we work with. Most of us don't particularly appreciate
simplistic arguments that ML subsumes Scheme. It does not, either
theoretically or pragmatically.

Some of us are professional programming language designers who
like to think we have a reasonably good grasp of why we're doing
what we're doing. (Some others are very well-informed amateurs
also deserving of a modicum of respect.) Maybe we're wrong, but the
polite thing is to give us the benefit of the doubt in our language's
newsgroup.

Paul Wilson

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

In article <4u5jck$d...@wobbegong.cs.indiana.edu>,
Eric Jeschke <jes...@cs.indiana.edu> wrote:

>Sin-Yaw Wang <sin...@cris.com> writes:
>
>I've never understood why there aren't different kinds of parsers
>for the same Scheme run-time system.

It's mainly because Scheme has a transformational grammar, with
a two-level, extensible parsing framework. The surface syntax
(parenthesized prefix expressions) is spectacularly well suited
to the deep syntax (transformation of trees into a canonical form.)

Conventional programming language syntax is poorly suited to the
extensible, transformational approach.

What you want is a surface syntax that can be automatically "chunked"
into hunks that can be reasonably dealt with by programmers
writing transformations. In Chomsky terms, there's a simple
phrase structure grammar that results in a representation of
phrases that programmers can understand, and transform in
intuitive ways, to implement the transformational grammar.

Scheme macros can do this very nicely because s-expressions
correspond fairly well (but not directly) to phrase boundaries,
and prefix notation is nicely uniform.

In effect, the head of a prefix expression names a node type in a
phrase-structure parse tree, and transformations of that
parse tree are easy to express because the printed representation
of the parse tree looks a lot like the normal surface syntax
of the language.

The programmer can write what appear to be surface-syntax-to-surface-syntax
transformations, but the macro system is smart enough to infer a
lot of the deeper properties of what's going on. (In particular,
for hygienic macros, to get scoping right in the face of transformations.)

It's also significant that Scheme parsing is top-down, in two
separate top-down phases. The first one is the phrase-structure
parse (construction of s-expressios by the reader).

The second is the transformational parse, which operates top-down on
trees (not token strings). It's really important that this phase
be top-down, because it allows transformations of higher-level
constructs to determine the meaning of nested constructs. That's
the way programming language semantics generally works, so
when you're implementing the semantics by transformation (into
things directly understood by the compiler) it's the only reasonable
thing to do.

A less regular syntax will generally bite you in one or more ways.
You want something that's roughly-LL (but extensible) so that
it can be parsed top-down.

You also want something that's very regular, so that transformations
can be written clearly---you don't want to complicate the recognition
of things that you may have to transform.

Pure prefix syntax is great for this. If you have both infix and
prefix operators, you either need to burden the transformation writer
with having to specify patterns of both types, or you have to
convert to a canonical form that doesn't look as much like the
surface syntax. The former is just a big drag---the macro writer
has to implement little hunks of parser here and there. The latter
is kind of a drag, too---the macro writer has to work with two
languages that are closely related but have a different syntax.

(The two-syntax approach is already taken in some languages, to
some degree---Sather comes to mind. You can write infix operators in
prefix function-call notation if you want to. This makes it easier
to write program-generating programs, because you can spit out
the same syntactic form for constructs that a normal programmer
would use different syntactic forms for. It complicates transformations
of user code, though, because you have to recognize the variants.)

Ville Herva

unread,
Aug 6, 1996, 3:00:00 AM8/6/96
to

>>>>>> On 5 Aug 1996 14:05:00 GMT, b...@anarres.CS.Berkeley.EDU (Brian Harvey) said:

>BH> Is there some language in which that isn't true? I mean, if you say
>BH> (+ 3 'foo) in any language, surely an error must result, right?

>C is an untyped language with some static type checking. If the variable x


>somehow contained the string "foo", then 3+x would be rejected (I think). In
>particular, it would not print "starting!".

vhe...@grasun.hut.fi:/usr/vherva>cat > foo.c
foo.c: File exists.
vhe...@grasun.hut.fi:/usr/vherva>cat > zot.c
main()
{
printf("%i", 3 + "foo");
}
vhe...@grasun.hut.fi:/usr/vherva>gcc zot.c
vhe...@grasun.hut.fi:/usr/vherva>a.out
8859


-- v --