multiple values
Olin Shivers
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
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
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
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
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
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
| 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
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
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
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
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
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
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
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:
>>
>> > something better were available? Isn't there enough experience to say
>> > that static typing, like static scoping, is the Right Thing?
>> >
>>
>
>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
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
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
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
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.
--
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
> 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
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
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
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
[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
[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
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
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
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
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
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
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
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?
>
> 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
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
[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
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
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
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
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
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
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
> 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
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
In article <4u4v2c$8...@agate.berkeley.edu>,
>>proponents is that Scheme is not strongly typed. In fact, it is, but
>
>(+ 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
>>>>> 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
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
"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
[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
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
>>
>> ...
>>
>> 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.
>>
>
>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
>>>>> 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
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
>Summary: ML is strictly more expressive than Scheme because Scheme can
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
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
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
>>>>>> 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 --
Daniel C Wang
> >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.
Consider the following in ML syntax
fun fident x:'a -> 'a = x
i.e. fident is the identity function that only works on arguments that are
functions that take some data structure of a particular type and return a
value of that same type.
The naive Scheme transliteration would probably go something like.
(define fident (lambda (x) x))
but the above function accepts inputs that would signal a type error in the
ML code, so the ML function differs from the Scheme function since
fidnet (fn x => "this is an 'a -> string function")
would signal a type error in ML while
(fident (lambda (x) "This is a string"))
in Scheme won't cause a type error.
(define fident (lambda (x) (lambda (arg) (let ((v (x arg))
(if (eqtype v x)
v (error "wrong type
arge")))))))
is a probably more sophisticated version that comes closer to ML behavior,
but still doesn't cut it because you have to actually call the function
returned by fident to catch type errors. Of course you could use some funky
hack to peek at the actual source code definition of the argument passed to
the scheme function and then do some sort of ML style type inference to
check that fident only works on the right kind of functions, but then why
not just write an ML compiler in Scheme and pass the ML program source text
to it.
Of course in one sense this argument is some what suspect because any well
typed ML program can be (and is in SMLNJ) translated into an untyped lambda
term. This translation assumes that the translated untyped lambda version
of the ML program is only called on type appropriate for it, something that
can be enforced/checked by the ML type-checker.
ML is Scheme with a screwy syntax and a
type-checker/proof-checker/program-verifier. I think the claim being made is
that having that built-in type-checker/proof-checker/program-verifier lets
you make certain correctness claims/assumptions that are difficult if not
impossible to express in an untyped language. If you want to transliterate ML
programs as well as the implicit correctness guarantees that you get from
programming in ML you just can't do it nicely. So I think the claim being
made is that you can't transliterate ML/statically type programs and the
correctness constraints into Scheme/dynamically type programs.
Matthias Blume
Scheme has macros, ML doesn't.
I think the original argument was about the expressiveness of the two
type systems.
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.
True. And indeed, I agree with you here: The only interesting thing
about Scheme these days is its uniform syntax and hygienic macros.
>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.
Again, he was talking about the type system. You can take any Scheme
program and translate it (straightforwardly) to ML and it will
type-check. You can also take any legal ML program and translate it (more
or less straightforwardly) into Scheme and it will (trivially)
type-check. But you can NOT always take any ML sub-program, translate
it to Scheme, and get the same type-errors when you use it in an
illegal fashion that you would have gotten in ML.
It all comes down to what one considers a strength: being able to get
away with about anything (Scheme) or being told by the compiler that
you are about to violate certain abstractions (ML).
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,
I have never been a fan of OO, and the purpose of MOPs escapes me entirely.
record definition facilities,
... are already in ML ...
control constructs,
... are subsumed by higher-order functions (although it is a matter of
taste if one finds this solution pretty) ...
parameterized module systems with inheritance,
... are already in the language, and average Joe-blow Scheme user will
be hard-pressed to come up with a set of macros powerful enough to
emulate the semantics of the ML module language ...
etc., *in the language*) come back and
talk to us again.
-----------------------------
The following paragraph is taken from an earlier thread which was
going on in the Scheme authors mailing list. Since people who defend
ML are thought of a ``sneerers'' in this forum, it might be worthwhile
to post it here as well:
I wrote:
``Even if I give the impression that my intent is to put
Scheme down and tell everybody how great ML is -- this impression is
slightly inaccurate. I have expressed my opinions of which direction
I would like to see Scheme develop into. Usually I am in favor of
more statically decidable information in the program, better means for
expressing abstractions, better support for separate compilation, and
simplicity. My saying so involved mentioning the bad word ``type'',
and some people are now jumping all over me. In order to defend my
views I have to use examples from my own experience -- and as it so
happens, this experience largely involves SML. So, yes, my views are
heavily influenced by the way things are done in SML. And no, I don't
think SML is superior in *every* aspect. There are still a few stong
points about Scheme, I just happen to believe that the type system is
not one of them.''
Regards,
--
-Matthias
Jeffrey Mark Siskind
In article <4u3s3s$3...@blackrabbit.cs.uoregon.edu> bh...@blackrabbit.cs.uoregon.edu (B. Robert Helm) 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, 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.
QobiScheme, available free from my home page, includes a DEFINE-STRUCTURE
macro for Scheme->C that eliminates the need to explicitly write code to store
and check type tags. Stalin, also available free from my home page, includes a
compatible DEFINE-STRUCTURE facility built into the compiler, and safely
eliminates of the storage and checking of type tags for defined structures
when possible. Together, these provide a convenient way to extend the type
system of R4RS and keep Scheme programs from violating user-defined type
systems.
Many, maybe even most, Scheme/Lisp dialects and implementations have record
definition mechanisms for extending the type system. In Common Lisp the
mechanism is standardized. To my knowledge, however, no Scheme/Lisp
implementation other than Stalin does type inference to eliminate storage and
checking of type tags on record data.
--
Jeff (home page http://tochna.technion.ac.il/~qobi)
Patrick Stickler
Erik Naggum <er...@naggum.no> wrote:
>[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.
Not at all. I'm sorry if I gave that impression. I suppose I was
expressing the opposite extreme in support of SGML in order to balance
out the weight of your criticizms against it. I am well aware of many
of SGML's shortcomings, and look forward for improvements in the field.
>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.
I did get your points, but I thought that they were unfairly broad in
their rejection of SGML as a useful technology. Perhaps you too have missed
my point, that -- accepting that SGML may not be the answer to all types
of modelling information, in general -- this does not mean that it
is to be avoided like the plague, is totally "wrong" in its approach,
has no value, that is not the "better" solution for specific problems
in specific fields, etc. I accepted your points, I just think
that they do not justify the total rejection of SGML as a useful
technology. In that, your conclusion to defame SGML on all fronts is
unfair, however valid your complaints.
Your disillusionment with SGML due to its lack of certain qualities you
need/want has apparently blinded you to those qualities which it does
possess and which offer benefit to its users. As I said before, SGML is
not the answer to all problems, but don't discredit the technology across
the board and tell folks to steer clear of SGML, because IMO for several
problems, it is the solution of choice.
>first, there are all sorts of reasons why something becomes widely used.
Sure. Look at MS-DOS! What a dog! But it did serve it's purpose at
the time. It's "failure" was to stagnate and not improve with competing
technologies... Perhaps SGML will fall into that same pit eventually...
And perhaps it will recover somewhat as DOS did with Windows 95 (still
an inferior OS, but a big step forward nonetheless).
>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.
Well, one certainly can't argue that SGML is "good" because lots of people
use it -- because it still isn't widely used. As for existing technologies
in the publishing world being "very good technologies", that is true. There
are very good for what they are intended to do -- to put black dots on
paper in a particular way as specified by some author/compositor. Your
argument is somewhat of a misnomer as SGML does not replace existing
publishing technologies, but adds a layer on top of those technologies, for
the express purpose of giving more control over the information to the
editors/authors/etc.
>SGML has
>been a political vehicle for a very long time, not a technical one.
This has not been my experience. I would love to hear your arguments for
this claim. Granted, getting SGML adopted by any given organization will
certainly involve politics. Anytime new technology is introduced, folks
who do not understand it will fear for their jobs, or worry that it will
increase the amount or diffuculty of their work. However, it has been my
experience that once they understand what SGML will do for them, they are
usually strong supporters of its adoption and use.
It is also true that SGML has been a component of several politically
sensitive issues, such as CALS, IETM's, etc., but these have mostly been
limited to mandates issued by a governing authority, and most of the
bruhaha has certainly been due simply to the fact that X had been
mandated, regardless as to whether X=SGML or any other technology.
>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.
No argument there. No company is going to be interested in *any*
technology which does not increase their profits. And, believe it or not,
most publishers are interested in getting away from distributing products
on "dead flat trees".
>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.
Hold on there, you are mixing a ideological vision for some "higher
purpose" of SGML with the actual technology embodied by SGML. Let's
not blur the true issue here; which IMO is whether SGML is a valid,
beneficial, and *preferred* technology for several real-world
applications. We must keep separate the technical notion of "reuse",
and the more general notion of "reuse" which falls within the realm
of copyrights. SGML addresses the former, and not the latter. If you
saw SGML as a vehicle for providing the latter (as well as the former)
then it is no suprise that you were disappointed.
>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.
Hmmmm. Which do you think is cheaper:
a) change the wording electronically in 5 places in a 1000+ page
document, then just reflow, repaginate, a generate new hard copy
or
b) re-key and format, at a minimum, 5 pages -- hoping that the
changes do not invalidate page breaks (which they probably will),
and then make page-specific formatting corrections to patch
the appearance, and possibly be faced with generating point pages,
etc., etc.
Or better yet, the editor decides that all 3rd level headings will be
inlined with the first paragraph of the section rather than separated
by 7pt whitespace, so the compositor must go in and manually change
238 headings in a 1200 page document, *rather* than just tweaking
a FOSI, or DSSSL instance, or formatting conversion filter, etc.
Note that in a traditional format-based markup language, this requires
that two physical paragraphs be merged into one. Even style sheets
such as those provided by high-end page layout packages cannot handle
changes at this resolution. It is a *trivial* change for an SGML system.
I can't see how *any* process dealing with printed material could be
concieved to be a form of more efficient reuse, then that same process
working with the material in electronic format.
>(even today, re-keyboarding is often
>much cheaper than using experts at "legacy data conversion".)
Sometimes re-keyboarding is cheaper. Sometimes legacy data conversion
is cheaper. It depends on the type of input data, the semantic
richness of the markup it has been encoded in, the consistency of
the markup, etc. If a document has been encoded e.g. in Framemaker
using paragraph and font styles (almost) exclusively, and those
paragraph and font styles were designed along functional, as opposed
to presentational, lines; then automated legacy data conversion is
much cheaper than re-keyboarding. If all a document has for markup
is font change codes, spaces and tabs for indentation, etc., then to
get to a "meaningful" SGML encoding, re-keyboarding to a high level
DTD is probably the best way to go. Sometimes, I use a combination
of re-keyboarding *and* automated postprocessing. Each case is unique,
and must be addressed on its own terms.
>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.
If done "right", it almost always is.
>we can convert between simple formatting languages with great
>ease, but as soon as we attempt to convert between higher-level languages,
>we lose.
But does this 'truth' make SGML any less useful. Will not this argument
apply equally well to any high level language. It is always easier to
convert between simple formalisms than between complex formalisms. Your
comparing apples to oranges here, Erik. Are you suggesting that we
abandon functional markup, and just go back to font shift codes and
linefeeds?!
>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.
One of the marks of a good information specialist is the ability to look
past the present needs and to envision how the information *might* be used;
and, given the fact that noone is fully omniscient, to encode the data
in a way that does not lock one into a particular viewpoint and preclude
the evolution of that data. This is *very* hard to do, and our knowledge
of how to do this is still in its infancy. SGML done "wrong" does NOT
however disvalue SGML done "right". Doing SGML "right" is a challenge,
and it is a sad fact that many folks using SGML do not understand its
purpose and/or strengths, and thus fail to derive its full benefit. This
is true for any technology. A case in point, several studies have
determined that a large portion of C++ programmers are actually just
programming in ANSI C, and thus encounter great diffuculties when later
trying to "reuse" their code or extend classes which were defined
improperly. Does this make C++ any less useful a tool, when done
right, following "good" OOP technique?
>| 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.
Firstly, I was *NOT* comparing SGML as equal to other formatting-based
markup languages. I was asking if *YOU* were, as suggested by your
arguments. I certainly see SGML in a different class to TeX, nroff,
and the like.
As for SGML winning in comparison to formatting-based markup languages,
I hardly consider it an empty victory for SGML because it offers
functionality that the others do not. Better technologies win, precisely
because their competitors "argue 'nolo contendere'" to key functionalities.
>| 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.
This fact will apply to *any* high level functional encoding of
information, even that which you envision as the better successor
to SGML. This is in no way a valid criticism of SGML itself.
>fact: once the
>information is in SGML, it is extremely difficult to improve on the
>document type (and associated software) without invalidating legacy
>information.
I have a hard time envisioning a case where information can be
"improved" *without* invalidating legacy data based on the old
model. Certainly, there are cases where data has been kept backwardly
compatible with earlier versions of a DTD -- but in most cases,
an improved model of information means a change to the organization
of that information, which means that the newly modeled information
no longer conforms to the old model -- if it still did, then it
wouldn't be "improved"!
And the problem of a change in the model invalidating associated
software applies for *any* complex modelling of information. Just
talk to any SQL programmer...
>both of these are _more_ difficult operations than in any
>other reasonable storage format.
If we substitute "reasonable" for format-oriented, then I agree. Noone
said that functional modelling was "easier" than format modelling; but
the gains are worth the added effort required.
I seem to get the impression, Erik, that you are arguing for a return
to format-based markup, since functional based markup is so "hard".
>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).
But keeping data in a format-based markup is not benefiting users who
must maintain information having either a complex structure or a long
life cycle, or both. Again, are you arguing for the abandonment of
functional markup in favor of older more limiting technology?
>that is not going to happen with SGML, not being a format
>that any particular company will have a competitive advantage using.
It is true that SGML will probably not show up in low-end word processors
in the near future (if ever) as these tools are used primarily for one-off
documents with very short lives, where the extra effort involved in using
SGML does not provide sufficient benefit to be cost effective.
But this argument does not have much (if any) relevance in verticle
markets dealing with large volumes of information which have long
lives and larger potential for reuse.
>second, converting between document types is extremely hard, and might well
>_require_ the power that DSSSL embodies.
It certainly does require the power that DSSSL embodies, which is why
the SGML community is pushing so hard for DSSSL implementations. DSSSL
is filling a large hole that has existed in SGML for far too long.
>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.
Again, SGML done "wrong" does not disvalue SGML done "right". Look at all
of the *horriffic* C and C++ code out there! Should the standards for
ANSI C and C++ be made more stringent so that "clueless idiots" will not
ever write "bad" code! One of the *strengths* of SGML is that it does
not presuppose nor enforce a "correct" way of doing things -- which ensures
that the technology can evolve with our understanding of how to do
functional markup "right".
>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
I must say Erik that I am disappointed in the level at which you are
arguing against SGML. It is evident that you have become highly
disillusioned with SGML, for whatever reasons, and that disillusionment
is making it difficult for you to discuss SGML with any measure of
objectivity. I will read the articles at your web site, as time
permits, as I truly am interested in your views. I think that you
had expected SGML to do something it could not, and its failure
(or the failure of those in the SGML community) appears to you to
be absolute. I would hope, though, that for the sake of those not
familiar with SGML, and seeking a solution to one of the problems it
addresses, that you would be fairer and more focused in your arguments
and not "throw the baby out with the bath water", so to speak.
Regards,
========================================================================
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
========================================================================
Robert Harper
My comments about Scheme have nothing to say about surface syntax.
I can see no use for macros, but even if ML were to have them, it's
unimaginable to me that they'd be done at the level of surface syntax.
For example, derived forms in ML compilers I've seen are done at the
level of abstract syntax where issues of grammar are irrelevant.
Bob
Paul Wilson
In article <3208B9...@cs.cmu.edu>, Robert Harper <r...@cs.cmu.edu> wrote:
>My comments about Scheme have nothing to say about surface syntax.
>
>I can see no use for macros, but even if ML were to have them, it's
>unimaginable to me that they'd be done at the level of surface syntax.
Exactly right. That would be the wrong thing to do. It's exactly the
problem with Lisp macros---you're writing surface syntax transformations and
the surface syntax doesn't respect little things like scope.
This is what Scheme gets right, and why Scheme's lexically-scoped ("hygienic")
macros are so interesting. A Scheme macro system lets you write what
superficially appear to be surface syntax transformations, but really Scheme
infers what you mean in terms of more abstract syntax. That is, the surface
syntax of macro definitions is just a convenient way of expressing
transformations over interpreted expressions, *not* just surface syntax
parse trees.
>For example, derived forms in ML compilers I've seen are done at the
>level of abstract syntax where issues of grammar are irrelevant.
They're not irrelevant, though, because it's hard to write transformations
over AST's, especially if they do anything interesting with scope.
Scheme provides support for writing transformations, in the language itself,
without having to muck around with gunk like renaming variables apart in
most cases. You usually only have to do funky things about scope when
you're implementing something that messes with scope. If you're not,
the default scope rules of macros are intuitive because they are the same
as the scope rules for normal code. If you are messing with the scope
rules, you have to think harder but the macro system supports it.
When you write compiler innards by transformation in the usual Scheme/FP
implementation style (which I've done), you have to do a lot of things by
hand that the Scheme macro system automates for you.
This makes transformations easier to write, because you can usually
deal with expressions (or abstractions of expressions) that look like
expressions, rather than something that looks like a backend representation.
The other great thing about Scheme macros is that you can use them in
normal programs, without needing access the innards of your compiler,
and without having to clone the compiler's transformational features
in your code. Scheme comes with an extensible compiler framework.
This is not to say that syntax-rules macros are the be all and end all;
for serious transformational implementation, you want at least the power
of (Dybvig et al.'s) syntax-case macros. (Syntax-rules macros are
pattern-matching and template-filling macros, which are surprisingly
powerful but still limited. Syntax-case macros are procedural transformers,
but allow you to mix procedural transformation with pattern-matching and
template filling.)
I think this is by far the most powerful support anybody's ever come up
with for making transformational programming practical, and eventually
people will realize that transformational programming can be really
important if the language doesn't make it unnecessarily hard.
Shriram Krishnamurthi
wil...@cs.utexas.edu (Paul Wilson) wrote:
> 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.
As someone will inevitably point out, you can get around some of this
using Cardelli, Matthes and Abadi's "extensible syntax" mechanism. A
contemporary Samuel Johnson might comment, as the original did about a
pertinent matter of his own time (but an unsavory one now), that it is
like a dog walking on its hind legs: it is done poorly, but one is
surprised to see it done at all.
Of course, I'm not saying Cardelli &c did a poor job: rather, they
were constrained by a poor medium (for reasons Paul Wilson has just
gone into detail about).
'shriram
Jay A. Carlson
Forgive my detour into being a C apologist. Do not infer any
endorsement. Please.
In article <wwd915v...@delphi.ccs.neu.edu>,
Mitchell Wand <wa...@delphi.ccs.neu.edu> wrote:
> 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",
There's no string type in C, unfortunately. There's char*, but...
> then 3+x would be
> rejected (I think). In particular, it would not print "starting!".
Here's a naive translation of your code into C.
~ slothrop1$ cat bar.c
#include <stdio.h>
int
main(argc, argv)
int argc;
char **argv;
{
printf("starting!\n");
printf(3 + "foobar\n");
return 0;
}
~ slothrop1$ gcc -Wall bar.c
~ slothrop1$ ./a.out
starting!
bar
~ slothrop1$
What's going on here is that "foobar\n" is of type char*, and adding 3
to it gets you three char cells into the string constant. This
is well-defined.
> 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).
The situation with structs isn't so bad, as long as we're not using
pointers:
~ slothrop1$ cat baz.c
#include <stdio.h>
struct Stringlike
{
int len;
char body[100];
};
int
main(argc, argv)
int argc;
char **argv;
{
struct Stringlike foo = {3, "foo"};
printf("starting!\n");
3 + (int)foo;
return 0;
}
~ slothrop1$ gcc -Wall baz.c
baz.c: In function `main':
baz.c:17: aggregate value used where an integer was expected
baz.c:17: warning: statement with no effect
~ slothrop1$
...and that first error halts compilation and we don't get to see
"starting!" after all. If you dike out the (int) cast, you get
baz.c:17: invalid operands to binary +
instead. So as long as you stay away from pointers (yeah, right), C
will reject these kinds of errors. Adding pointers to pointers will
also be caught at compile-time, unless you cast at least one of them
to int.
Most decent C compilers will try to warn you when you do anything
really outrageous or stupid. The results of most of these pointer
arithmetic shenanigans is undefined; nothing prevents a conforming
ANSI C implementation from doing a good deal of runtime checking.
Supposedly, market pressures have kept people away from doing that,
but I keep thinking there's a reason Purify is so popular....
As you've probably guessed by now, the situation in C++ can be
several orders of magnitude worse.
--
Jay Carlson n...@kagoona.mitre.org n...@nop.com
The MITRE Corporation, Bedford MA
Flat text is just *never* what you want. ---stephen p spackman
Robert Harper
Mitchell Wand wrote:
>
> 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?
>
There are two points. One is what you point out: if you "strip" the ML
code to get Scheme code, you find that the detailed operational behavior
is not faithful to the ML precisely because of the tag manipulation.
But in the reverse direction (from Scheme to ML), it is completely
faithful in every detail.
The second is discussed by Dan Wang, namely that the ML type system can
enforce abstraction boundaries that are lost once you pass to Scheme.
So there is no way to recover critical (for software engineering
reasons) distinctions such as are routinely enforced through the use of
the ML type system. So in this sense it is not faithful either.
A final point is that you'll notice that the SML/NJ compiler, which
originally used the "stripping" transformation, no longer does so. The
TIL compiler takes the type-theoretic viewpoint from the start. The
reasons in both cases are exactly to do with the arguments I'm making:
it's too lossy to transform to Scheme from ML, but, as Greg mentions,
there is no loss (in fact, substantial gain) in going the other
direction.
As an aside, many people feel compelled to point out how much they like
ML. This is great, but it's beside my point. In truth I find Scheme
charming myself, which is why I read this newsgroup. But it pains me to
see that so many people still don't understand basic issues about type
systems. So much progress has been made over the last 10-15 years
(especially), yet so little of it appears to have gotten through to
places where it could really matter.
> --Mitch
Bob
Matthias Blume
In article <wwohkoo...@delphi.ccs.neu.edu> wa...@delphi.ccs.neu.edu (Mitchell Wand) writes:
[ ... ] Then any legal ML program
becomes a legal Scheme program; pre-execution type checking turns into
run-time tag-checking.
[ ... ]
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?
The point is that this straightforward translation also translates
some *illegal* ML code into *legal* Scheme. And no, runtime
typechecking won't catch it either, because an abstract type whose
concrete implementation is int will be compatible with every other
int, even though in ML is isn't supposed to.
--
-Matthias
Scott Draves
>>>>> "Paul" == Paul Wilson <wil...@cs.utexas.edu> writes:
In article <4uakvb$5...@jive.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
Paul> you want at least the power of (Dybvig et al.'s) syntax-case macros.
papers on syntax-case are available at:
ftp://ftp.cs.indiana.edu/pub/techreports/TR356.ps.Z
ftp://ftp.cs.indiana.edu/pub/techreports/TR355.ps.Z
Paul> I think this is by far the most powerful support anybody's ever
Paul> come up with for making transformational programming practical,
probably true, but i think this kind of system is very soon going to
get some competition from partial evaluation systems based on binding
time analysis. basically these systems use a type system to determine
what part of a program can be run at macro expansion time, thus
avoiding name problems completely.
see http://www.irisa.fr/lande/schism.html, or
http://www.diku.dk/research-groups/topps/activities/similix.html
Paul> and eventually people will realize that transformational
Paul> programming can be really important if the language doesn't make
Paul> it unnecessarily hard.
i certainly agree with this.
--
balance
equilibrium
death
Paul Wilson
In article <SPOT.96A...@goober.graphics.cs.cmu.edu>,
Scott Draves <sp...@goober.graphics.cs.cmu.edu> wrote:
>>>>>> "Paul" == Paul Wilson <wil...@cs.utexas.edu> writes:
>In article <4uakvb$5...@jive.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
>
>Paul> you want at least the power of (Dybvig et al.'s) syntax-case macros.
>Paul> I think this is by far the most powerful support anybody's ever
>Paul> come up with for making transformational programming practical,
>
>probably true, but i think this kind of system is very soon going to
>get some competition from partial evaluation systems based on binding
>time analysis. basically these systems use a type system to determine
>what part of a program can be run at macro expansion time, thus
>avoiding name problems completely.
I don't see it. I think partial evaluation and abstract interpretation
are wonderful things, but I think macros serve a fundamentally different
role a lot of the time.
In general, there's no way a general analysis and optimization system
can do the things a macro system can do.
When I write macros that transform programs, I often want to express
what happens at compile time separately from what happens at run
time. I do *not* want to have to write things as though everything
happened at run time, and have the optimizer automatically sort it
out. Trying to use partial evaluation to do this misses the point,
in many cases.
There are two reasons for this. One is simply that some of the analyses
and optimizations I do in macros are simply not feasible for a
*general-purpose* optimizer to do, despite being pretty simple. (A
sufficiently smart analyzer and optimizer may *often* get these, given
enough time, but not always. It's fundamentally intractable.)
A more important reason is that I want my code to be understandable
and to give me feedback. I want to be able to specify constraints
on transformations that are impossible to specify with a conventional
type system, and I want it to be clear that those transformations
*must* happen for the program to successfully compile---I want an
error message when the transformation is illegal, rather than having
the compiler assume I know what I'm doing, and generate crummy code
because the analysis didn't work and the transformation wasn't applied.
In Matthias's terms, I need a language for telling my compiler what
theorems to try to prove, and how to prove them. I also need to
be able to tell it whether a failure to prove a theorem should
default to some conservative code-generation strategy that will
work (perhaps issuing a warning), or whether the program just
doesn't make sense.
The nice thing about procedural macros like syntax-case is that
I can write any theorem prover I want, to prove any properties
I know how to prove. For well-developed proof systems, I'd naturally
want to cobble up a (mostly) declarative interface, but I don't want
To be limited to first-order programming over runtime data.
(Note that I don't mean "first order" in the sense of no
first-class and higher-order functions. I mean first-order
in the sense of being "about normal program objects" as
opposed to "higher-order" in the sense of being "about
programs", i.e., meta-level in a very strong sense.)
This raises some very funky issues in type systems, which is why
I like Scheme and am queasy about ML, for these purposes. Scheme
lets me do what I need to do, as long as it "works out" to code
that compiles. (It's up to me to cover my ass, but I can build
facilities that cover my ass for me later, when I'm doing
"normal" programming with my extended language.)
Eventually, I'd like my metalevel programming facilities to
be strongly typed, but with a notion of meta-types that allows
me to control interfaces that restrict composition. This is
a different thing from the normal notion of types, which are
about how the resulting normal data objects interact. In essence,
I want a design-rule checker for program composition. In general,
this can't always be expressed in a remotely conventional type
system, so there will always have to be procedural hooks
for design-rule checking. (My extensible language will have
an extensible framework for design-rule checking, which will
always have back doors for adding provers for properties a
type system just can't understand, much less prove.)
I'm not saying there's anything wrong with partial evaluation,
and in fact ultimately I'd like an extensible framework for
abstract interpretation and partial evaluation. I just don't
agree with the widely-held view that macros are a poor substitute
for better compilers.
Paul Wilson
In article <j7v4tmf...@europa.cs.rice.edu>,
Shriram Krishnamurthi <shr...@cs.rice.edu> wrote:
>wil...@cs.utexas.edu (Paul Wilson) wrote:
>
>> 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.
>As someone will inevitably point out, you can get around some of this
>using Cardelli, Matthes and Abadi's "extensible syntax" mechanism. A
Dylan is also worth a look. Dylan is essentially Scheme with a
sipple CLOSish metaobject protocol, with a conventional Algol-ish
syntax.
Unfortunately, so far Dylan only has a subset of Scheme syntax-rules
macros, and I believe the limitations are largely due to the conventional
surface syntax. It will be interesting to see how gracefully it
can be extended with things like let-syntax, letrec-syntax, and
syntax-case.
![Michael Sperber [Mr. Preprocessor]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW1Ug-7D5rvPAe0Dy8QWlBwdoMp8sHWFACGdNTzwJ9mF7CkTQ=s40-c)
Michael Sperber [Mr. Preprocessor]
>>>>> "PRW" == Paul Wilson <wil...@cs.utexas.edu> writes:
PRW> In article <SPOT.96A...@goober.graphics.cs.cmu.edu>,
PRW> Scott Draves <sp...@goober.graphics.cs.cmu.edu> wrote:
>> probably true, but i think this kind of system is very soon going to
>> get some competition from partial evaluation systems based on binding
>> time analysis. basically these systems use a type system to determine
>> what part of a program can be run at macro expansion time, thus
>> avoiding name problems completely.
PRW> I don't see it. I think partial evaluation and abstract interpretation
PRW> are wonderful things, but I think macros serve a fundamentally different
PRW> role a lot of the time.
PRW> [ ... ]
PRW> When I write macros that transform programs, I often want to express
PRW> what happens at compile time separately from what happens at run
PRW> time. I do *not* want to have to write things as though everything
PRW> happened at run time, and have the optimizer automatically sort it
PRW> out. Trying to use partial evaluation to do this misses the point,
PRW> in many cases.
Depends on what your definition of partial evaluation is. Offline PE
has two passes: a specializer which performs the actual compile-time
stuff, and the binding-time analysis which tells the specializer what
to do.
Nothing keeps you from using offline PE without the binding-time
analysis, essentially writing two-level code. It's almost trivial to
write libraries (or macros :-}) that implement combinators that do
that. The DIKU folks, Robert Glueck, and Peter Thiemann have done
work on this and have implementations. This is not much different
from what you do when you write macros---it does look nicer,
occasionally, though. Also, you can extend the principle to an
arbitrary number of levels. And it's still very readable if done
right.
Tim Sheard has just recently come up with a syntactic extension
facility for SML which is also based on this. He also has a type
system for it. It's not implemented, however, as far as I know.
PRW> I'm not saying there's anything wrong with partial evaluation,
PRW> and in fact ultimately I'd like an extensible framework for
PRW> abstract interpretation and partial evaluation. I just don't
PRW> agree with the widely-held view that macros are a poor substitute
PRW> for better compilers.
PE is a technique with prospectives well beyond the use in optimizing
compilers (although significant work remains to be done to even make
that work), and for what you want, you'd obviously want a system that
works separately from the compiler proper.
So multi-level code can handle the code generation issues that macros
can handle easily, and also takes care of naming problems. It isn't
particularly suited for making different flavors of syntactic sugar.
For that, on the other hand, syntax-rules is spectacularly well
suited, and syntax-case doesn't buy you anything new, at least not in
a particularly elegant manner.
Cheers =8-} Mike
Paul Wilson
In article <y9lbugk...@modas.informatik.uni-tuebingen.de>,
Michael Sperber [Mr. Preprocessor] <spe...@informatik.uni-tuebingen.de> wrote:
> [... much interesting stuff deleted ...]
>PE is a technique with prospectives well beyond the use in optimizing
>compilers (although significant work remains to be done to even make
>that work), and for what you want, you'd obviously want a system that
>works separately from the compiler proper.
Right. I think PE and macros are interestingly related, and in
the future I may do some things with PE that I currently do with
macros. I still think macros are different, though, and that they'll
still be useful even when PE is more advanced.
>So multi-level code can handle the code generation issues that macros
>can handle easily, and also takes care of naming problems.
I'm skeptical. Some "problems" are actually opportunities. One thing
you can do with macros is define new binding constructs. For example,
you can write a FOR loop construct that introduces a binding and makes
it visible to its body "argument".
Macros are like inline call-by-name procedures, EXCEPT that you can
do things that seem to violate lexical scope, yet implement a new
lexically-scoped construct.
My impression is that you can't do this with PE. I could be wrong
(corrections welcome.)
BTW, I'm not talking about Lisp macros here. Lisp macros are simply
broken with respect to scope. What's cool about Scheme macros is
that if you write something (like OR or COND) that doesn't do scope
tricks, it does the righteous lexically-scoped thing. But you
still have the ability to easily manipulate scope *when you want to*.
FOR isn't really the most interesting example. A more interesting
example is implementing module or object scope, where you extend
the notion of lexical scope to include identifiers visible inside
a module definition or class definition, and provide code to
implement references to the things they identify.
In Scheme, I can write an object system with private variables, and
integrate it into the language without modifying the compiler.
> It isn't
>particularly suited for making different flavors of syntactic sugar.
>For that, on the other hand, syntax-rules is spectacularly well
>suited, and syntax-case doesn't buy you anything new, at least not in
>a particularly elegant manner.
It depends on what you do with it. Our version of syntax-case is
*not* going to be implemented in the traditional way, as a separate
pass. Our macro system is integrated directly into the compiler,
and macros are not actually "expanded" at all. They're compiled
inline, as though the body expression had occurred inline at
the call site. (This is philosophically more similar to Bawden-Rees
"syntactic closures" than to traditional macroexpansion, but the
effect is essentially the same as syntax-case for most purposes.)
This allows us to build a framework where macroexpansion happens
at a well-defined time during compilation, so that we can gracefully
expose little bits of the compiler internals to procedural macros.
(Eventually we'll have a well-defined metaobject protocol that says
what you can do and what you can't. Right now we're just hacking
around, trying to identify what we can fruitfully expose without
limiting the compiler's freedom unduly.)
This allows us to query and decorate the compiler's representation
of expressions as macros are expanded. Since macroexpansion is done
outside-in in the normal course of compilation, we can decorate
the compiler's representation of an outer construct as we encounter
inner constructs, and then use that information when we come back
up from the depth-first traversal of nested expressions.
This gives us an extensible framework for many kinds of analysis and
optimization, where the analysis can be done in a depth-first
descent, and optimization can be done during the ascent, after enclosing
expressions have been analyzed. Eventually we want to provide a more
powerful framework that reifies later passes of the compiler and supports
more sophisticated control flow; the challenge there is to keep it
intuitive, where you have a natural representation of somewhat-optimized
code and the algorithms that operate on it.
(We're looking at something based on fixed-point computations, sort of like
UNITY, as a framework for extensible abstract interpretation and partial
evaluation. That's definitely hairier, and far down the road. For
now there's plenty we can do with what we've got.)
Guillermo (Bill) J. Rozas
In article <4u7pmh$j...@garbo.cs.indiana.edu> d...@cs.indiana.edu (R. Kent Dybvig) writes:
| From: d...@cs.indiana.edu (R. Kent Dybvig)
| Date: 6 Aug 1996 10:51:45 -0500
| 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.
I hate to beat on a dead horse, but static types do not allow you to
say anything more about a given program. Comments can be at least as
expressive, and in particular, you can choose a stylized discipline
that comes arbitrarily close to ML's type language. The issue is
purely whether you want them automatically checked or not.
To take an extreme example, I can write any program I want using
Godelization, and it would not be very intelligible unless I added
additional information in the form of meaningful variable names and
additional comments. This language could be as expressive as I wanted
and not be subject to whatever constraints a particular type checker
imposes on me. However, if I wanted my assertions/invariants
automatically (and a-priori rather than dynamically) checked I would
have to restrict myself to whatever language my tool accepted.
ML imposes one such tool on all programs. Scheme does not.
BTW, the expressiveness issue is really funny since people seem to
make a big deal out of the fact that you don't have to declare most
types in ML because of the inference engine. Well, they can't quite
have their cake and eat it too. Either it is a bonus for program
redability or it is an annoyance. Practice seems to imply that it is
more of the latter than the former since my experience is that people
only use them when the inferencer won't "guess" what they really want.
Matthias Blume
FOR isn't really the most interesting example. A more interesting
example is implementing module or object scope, where you extend
the notion of lexical scope to include identifiers visible inside
a module definition or class definition, and provide code to
implement references to the things they identify.
I don't think hygienic macros can do that. In fact, hygienic macro
expansion algorithms don't work in the presence of module scoping
rules, unless you modify the algorithm. Check out
http://www.cs.princeton.edu/~blume/macmod.ps
for a dicussion of this problem and a solution. The macro system must
be made aware of the presence of scoping rules that aren't the normal
lambda-calculus onces.
[ ... ]
It depends on what you do with it. Our version of syntax-case is
*not* going to be implemented in the traditional way, as a separate
pass. Our macro system is integrated directly into the compiler,
and macros are not actually "expanded" at all. They're compiled
inline, as though the body expression had occurred inline at
the call site. (This is philosophically more similar to Bawden-Rees
"syntactic closures" than to traditional macroexpansion, but the
effect is essentially the same as syntax-case for most purposes.)
I don't think this is much of a difference. I am sure your compiler
uses some kind of intermediate language, which is very much like pure
lambda calculus with extensions (or call it core Scheme without
macros). It might be the case that your compiler is written in such a
way that expressions of this intermediate language never really
materialize, because they are eliminated by some form of deforestation
(which was coded by hand). But this doesn't matter much.
--
-Matthias
Richard Gabriel
Bob, you wrote:
. . . But it pains me to see that so many people still don't
understand basic issues about type systems. So much progress has been
made over the last 10-15 years (especially), yet so little of it
appears to have gotten through to places where it could really matter.
This is something I can comment on. When I teach people to write I
tell them there is one criticism of their work that they cannot argue
with: ``I don't understand it.'' It seems to me that if the ML folks
and type theorists don't feel that their work has been understood
(``so little of it appears to have gotten through''), then it is a
failure to communicate, and the blame, if there is to be any, is on
the ML/type folks' side. Certainly the remedy is to explain and
illustrate better and not to think harder and understand better.
To communicate what you want about types, I think you have to divorce
it from a comparison of one programming language with another. In the
discussion that has raged on these pages, the underlying emotional
theme is that ML is better/worse than Scheme, and that one or the
other of these languages sucks for various reasons. There are many,
many reasons to like a language and to use it, and so when one person
tries to narrow the argument to one issue and argue that in this
dimension one language is inferior to another, there is only one
outcome: animosity.
So, it seems that the ML/types community has its work cut out for it
- how to communicate about types so that everyone else ``gets it'' and
so that religious wars about languages is avoided. I think this is
your problem, not the audience's problem and I await the solution.
Now to flame a bit: I find ML to be an abhorrent language to look at,
and I count some of the most important papers about ML to be among the
worst written pieces I have ever seen. When I teach writing, I use
some of these pieces as laughable examples of technical writing. This
is in contrast to some of the ideas underlying the language, which I
admire and consider important, and the implementation work, which I
believe is the best going on right now. It strikes me as no
coincidence that the ugliness of the language itself matches the
ugliness of the writing about it. I guess there just isn't much
artistry in the ML community (not none, just not much). It will be a
challenge to present these ideas beautifully.
Scheme is indeed a charming language, and it's quite entertaining and
educational to see just what would happen if a cloister of medieval
monks were holed up on top of a granite pinnacle somewhere in the
Italian Alps thinking about programming languages. I consider the
Scheme community the stylites of programming languages. That is,
Scheme's concerns are so out of touch with real programming that it
makes for high enjoyment indeed.
I'd say that Scheme's view of real programming matches that of the
early to mid '60's while ML's has leapt into the '70's somewhere
(which is good, which is good). I might even go with the early '80's
if it would causes less heartache to hear me say it.
Now, there is nothing wrong with someone perfecting the techniques of
stone knives, but there is a relevance question.
Ok, so I bet I've insulted both camps about equally. Let me leave the
ML camp with this challenege: Explain it so we get it, and don't sell
us a refrigerator and a programming language on the same visit. Or, if
you're going to hand out pamphlets and talk about the last days ahead,
we won't answer the doorbell.
-rpg-
Paul Wilson
In article <y9lbugk...@modas.informatik.uni-tuebingen.de>,
Michael Sperber [Mr. Preprocessor] <spe...@informatik.uni-tuebingen.de> wrote:
>
>Depends on what your definition of partial evaluation is. Offline PE
>has two passes: a specializer which performs the actual compile-time
>stuff, and the binding-time analysis which tells the specializer what
>to do.
>
>Nothing keeps you from using offline PE without the binding-time
>analysis, essentially writing two-level code.
>Tim Sheard has just recently come up with a syntactic extension
>facility for SML which is also based on this. He also has a type
>system for it. It's not implemented, however, as far as I know.
As near as I can tell, Sheard is reinventing macros in the context
of ML, allowing people to write syntactic closures-style macros
using a subset of ML as the metalanguage. This seems like a
good thing as far as it goes.
If I read him right, Sheard's macro system can't do some fo the neat
things you can do with syntax-rules, much less syntax-case. He
seems to be interested in staging more than in more powerful
transformations. E.g., you can't write FOR or an object system with
encapsulated scopes. (I could be wrong about this---I haven't put
enough effort into understanding exactly what he's up to.
Paul Wilson
In article <izwwz85...@atomic.Princeton.EDU>,
Matthias Blume <bl...@atomic.cs.princeton.edu> wrote:
>In article <4ufr6k$6...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
>
> example is implementing module or object scope, where you extend
> the notion of lexical scope to include identifiers visible inside
> a module definition or class definition, and provide code to
> implement references to the things they identify.
>
Yes, they can. At least, our macros can.
I haven't tried it with just syntax-rules, but the
only problem I see is a trivial one---being unable to redefine a
raw use of an identifier as a macro, rather than just forms of
the form (identifier ...). You can do it with syntax-case, I'm
pretty sure. That's not to say it's the most efficient way to
do it---you can benefit from having procedural macros (like
syntax-case, only more so) to reduce the work in repeatedly
instantiating parameterized modules.
I'm not sure if our modules are exactly what you want, though, so
I'm not sure if what we're doing would satisfy you. I do think they're
what we want.
> In fact, hygienic macro
>expansion algorithms don't work in the presence of module scoping
>rules, unless you modify the algorithm.
We thought of that.
Are you claiming there's a deep problem here, or just that (of course)
you have to do something fairly obvious to get the compile-time environments
right?
> Check out
> http://www.cs.princeton.edu/~blume/macmod.ps
>for a dicussion of this problem and a solution.
OK. I wonder if your solution is the same as ours. In our solution,
macros come first, and module scope is defined with macros.
>The macro system must
>be made aware of the presence of scoping rules that aren't the normal
>lambda-calculus onces.
I think the that it's cleaner to use the scoping rules of lambda calculus
plus hygienic macros to define the scoping rules of modules.
> Our macro system is integrated directly into the compiler,
> and macros are not actually "expanded" at all. They're compiled
> inline, as though the body expression had occurred inline at
> the call site. (This is philosophically more similar to Bawden-Rees
> "syntactic closures" than to traditional macroexpansion, but the
> effect is essentially the same as syntax-case for most purposes.)
>
>I don't think this is much of a difference.
Oh?
>I am sure your compiler
>uses some kind of intermediate language, which is very much like pure
>lambda calculus with extensions (or call it core Scheme without
>macros).
Sure, sort of.
>It might be the case that your compiler is written in such a
>way that expressions of this intermediate language never really
>materialize, because they are eliminated by some form of deforestation
>(which was coded by hand).
Nice glib description, and maybe not *too* far off.
(Too bad you don't understand the significance.)
>But this doesn't matter much.
Rats. I guess we'll just have to junk that part of our research program,
then, since you don't understand the merit of what we're doing.
Back to the drawing board. :-)
Robert Harper
Jeff Dalton, Dick Gabriel, and others have made some good points, and
raised some interesting questions. Unfortunately they come at a
somewhat inconvenient time for me (I leave town in two days for two
weeks), but I plan to reply as soon as I get the chance.
Bob
S W Dyer
wil...@cs.utexas.edu (Paul Wilson) writes:
>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.
Here I must differ. I've never seen this done, but I think it's
certainly possible to build a language with built-in datatypes for the
different kinds of parse-tree nodes that are used to represent it in
some canonical way. Then parse-trees could be returned from functions
and a similar macro-defining tool could be created for this language,
you just use constructors like "function-call-expression",
"addition-expression", "conditional-expression", etc. instead of "cons"
when writing the macro.
Of course, is it worth it? For simplicity scheme's syntax is among the
best, but for ease of reading I would raise some questions. Most human
time spent learning how a program works is spent matching parentheses
or performing similar matching operations, the bottleneck of which is
the very small amount of short-term memory availible to the human.
While I know your editor does parenthesis matching for you, it only
matches one at a time and there are syntactic alternatives that are
much less parenthesis-rich. For such a language to support macros
though would entail the solution in the paragraph above....
-- S W D
Paul Wilson
In article <4uldpk$q...@crcnis3.unl.edu>, S W Dyer <s...@cse.unl.edu> wrote:
>wil...@cs.utexas.edu (Paul Wilson) writes:
>>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.
>
>Here I must differ. I've never seen this done, but I think it's
>certainly possible to build a language with built-in datatypes for the
>different kinds of parse-tree nodes that are used to represent it in
Certainly. Some existing languages do just this. (Beta does, I think.)
This is certainly better than no meta-level programming facility at
all and for some purposes, with an advanced enough system, one shades
off into the other.
A really powerful procedural macro system *is* a system for messing
around with the compiler's internal representations---or a precompiler's
internal representations.
(Hygienic macro systems that operate as a prepass are really precompilers,
not just simple preprocessors. They must parse and analyze expressions
down to syntactic primitives.)
The advantage of a good macro system per se is that it gives you a
very intuitive user interface for writing transformations over
parsed expressions. For the most part, you can specify patterns
in what looks very much like the object language that you're transforming.
The parser is your friend---you can specify patterns and code templates
in something very much like the normal source language.
With macros, you can write things as though they were normal source
code and implicitly tell the compiler to operate on the corresponding
AST's---"the kind of thing this parses to". You're using the parser
and macro system as an inference engine to let you do things mostly
declaratively, and it infers the transformations over compiler
internal data structures.
What I'm arguing for (and what we're building) is a system where
you can do the easy things easily, using a declarative transformation
system like Scheme's syntax-rules macros, but where you have more
powerful availble when you need it, with things like syntax-case
and still more primitive operations on first-class objects that
represent things like expressions and scopes.
For really hard analyses and optimizations, you'll ultimately have
to do similar things to what AST-mangling systems give you. But
even when you're doing something complicated, *most* of your code
can be written at the friendliest, cleanest level of abstraction.
(For example, you can write most of your macros with syntax-rules,
some of them with syntax-case, and some of them with first-class
representations of type and scope objects. All of these things
should interoperate gracefully, so that even when you're doing
something fancy, you only have to dip down to a lower level
of abstraction in a few places.)
>Of course, is it worth it? For simplicity scheme's syntax is among the
>best, but for ease of reading I would raise some questions. Most human
>time spent learning how a program works is spent matching parentheses
>or performing similar matching operations, the bottleneck of which is
>the very small amount of short-term memory availible to the human.
Sure.
But correspondingly, you don't want to make transformational programming
any harder than it has to be.
Just think of a good macro system as a very nice front-end to a fully
general extensible compiler toolkit.
>While I know your editor does parenthesis matching for you, it only
>matches one at a time and there are syntactic alternatives that are
>much less parenthesis-rich. For such a language to support macros
>though would entail the solution in the paragraph above....
I certainly think a "more conventional" syntax with more visual
markers could be designed without *too* much difficulty for writing
macros, but it's not an easy problem. Lots of tradeoffs.
Matthias Blume
In article <izwwz85...@atomic.Princeton.EDU>,
Matthias Blume <bl...@atomic.cs.princeton.edu> wrote:
>In article <4ufr6k$6...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
>
> FOR isn't really the most interesting example. A more interesting
> example is implementing module or object scope, where you extend
> the notion of lexical scope to include identifiers visible inside
> a module definition or class definition, and provide code to
> implement references to the things they identify.
>
>I don't think hygienic macros can do that.
Yes, they can. At least, our macros can.
Probably we have different ideas of what a module system should do.
And I don't think that *my* idea of a module system can be realized
with hygienic macros. But I can't say more before I have seen a
specification of your module languages and/or your implementation.
I'm not sure if our modules are exactly what you want, though, so
I'm not sure if what we're doing would satisfy you. I do think they're
what we want.
Fair enough.
> Check out
> http://www.cs.princeton.edu/~blume/macmod.ps
>for a dicussion of this problem and a solution.
OK. I wonder if your solution is the same as ours. In our solution,
macros come first, and module scope is defined with macros.
Well, then our solutions can't possibly be the same, because my
solution requires the macro system to be already aware of the
existence of nested scope and qualified names.
> Our macro system is integrated directly into the compiler,
> and macros are not actually "expanded" at all. They're compiled
> inline, as though the body expression had occurred inline at
> the call site. (This is philosophically more similar to Bawden-Rees
> "syntactic closures" than to traditional macroexpansion, but the
> effect is essentially the same as syntax-case for most purposes.)
>
>I don't think this is much of a difference.
Oh?
>I am sure your compiler
>uses some kind of intermediate language, which is very much like pure
>lambda calculus with extensions (or call it core Scheme without
>macros).
Sure, sort of.
Well, in this case the paragraph below doesn't apply. Your algorithm
actually does expand macros -- but the result is not expressed in
Scheme but in something roughly isomorphic to that.
>It might be the case that your compiler is written in such a
>way that expressions of this intermediate language never really
>materialize, because they are eliminated by some form of deforestation
>(which was coded by hand).
Nice glib description, and maybe not *too* far off.
(Too bad you don't understand the significance.)
What *is* the significance?
>But this doesn't matter much.
Rats. I guess we'll just have to junk that part of our research program,
then, since you don't understand the merit of what we're doing.
Back to the drawing board. :-)
Deforestation certainly has its merits. I was just saying that
whether it is done or not doesn't alter the principal mechanism
underneath. You can still think of macros being expanded in the
`traditional' way if this is convenient. I wasn't criticising any
particular approach.
Regards,
--
-Matthias
Jeffrey Mark Siskind
Exactly right. That would be the wrong thing to do. It's exactly the
problem with Lisp macros---you're writing surface syntax transformations and
the surface syntax doesn't respect little things like scope.
This is what Scheme gets right, and why Scheme's lexically-scoped
("hygienic") macros are so interesting.
One thing that people often forget about when discussing macros is that
procedural macros are often used not just to extend the syntax of Lisp/Scheme
with little special forms like DO, LOOP, etc. but rather to implement whole new
sublanguages. People use macros to implement Prolog, forward chaining rule
systems, grammars for natural language, languages to write expressions in
various logics, etc. The bodies of such macros are not Lisp/Scheme code. They
are not intended to be interpreted by the same semantics as Lisp/Scheme
expressions. For such purposes, any macro system that attempts to integrate
the semantics of the host programming language into the macro expansion
process actually gets in the way. This includes variable scoping issues, type
inference, and the like.
One of the nice things about Lisp/Scheme is that the surface S expression
parser is so language neutral. This comes in very handy and allows a useful
form of macro reuse: Most languages can use some form of IF, independent of
whether if it Prolog, forward chaining rule systems, grammars for natural
language, various logics, etc. In Lisp/Scheme it is natural to represent this
construct as (IF <antecedent> <consequent> <alternate>) in any embedded
language. Now besides the trivial benefits like that my editor now nows how to
indent IF constructs in all of these embedded languages, and aesthetically,
these IF constructs, have a uniform appearance, there is an additional
benefit: if I write my macro correctly, and design my embedded language
correctly, it can inherit all of the macros from the base Lisp/Scheme
environment that expand into IF. Things like COND, WHEN, UNLESS, CASE, etc.
I'd also like to emphasize the point of the syntactic uniformity of
S expressions and their use in sublanguages that are implemented via macros.
Lisp/Scheme programmers have been writing things like the following:
(prove
(every x
(implies (and (integer x) (> x 2) (even x))
(some y (some z (and (prime y) (prime z) (= x (+ y z))))))))
for almost 40 years. Or:
(parse
((constrain (=> s (seq np vp)) (and (= (person np) (person vp))
(= (number np) (number vp))))
(constrain (=> vp (seq v np)) (and (= (person vp) (person v))
(= (number vp) (number v))))
...)
(colorless green ideas sleep furiously))
The important thing about these example is that many embedded languages inherit
syntactic notions from the host language: Logic and Lisp/Scheme share notions
like EVERY, AND, INTEGER, >, EVEN, SOME, =, and +. Unification grammars and
Lisp/Scheme share notions like AND, =, and function application. Nothing about
this is particular to prefix syntax. One could imagine an infix syntax that
allowed one to use host-language syntactic constructs to express Goldbach's
conjecture:
prove(every(x,(integer(x)&x>2&even(x))->
some(y,some(z,prime(y)&prime(z)&x=y+z))));
or a grammar:
parse([s-->np,vp{person(np)=person(vp)&number(np)=number(vp)},
vp-->v,np{person(vp)=person(v)&number(vp)=number(v)},
...],
"colorless green ideas sleep furiously");
But the important point is that most non-Lisp/Scheme implementations do not
let you use the host language syntax in such a fashion. Instead they force you
to write things like:
prove(['every', 'x'
['implies', ['and', ['integer', 'x'],
['>', 'x', '2'],
['even', 'x']]
['some', 'y',
['some', 'z',
['and', ['prime', 'y'],
['prime', 'z'],
['=', 'x', ['+', 'y', 'z']]]]]]]);
or:
parse([['constrain', ['=>', 's', ['seq', 'np', 'vp']],
['and', ['=', ['person', 'np'], ['person', 'vp']],
['=', ['number', 'np'], ['number', 'vp']]]],
['constrain', ['=>', 'vp', ['seq', 'v', 'np']],
['and', ['=', ['person', 'vp'], ['person', 'v']],
['=', ['number', 'vp'], ['number', 'v']]]]
...],
"colorless green ideas sleep furiously");
This is very unnatural and ugly. It hinders proper writing and understanding
of programs. You might think that this is just a parody. That real programs
don't do this very often and that real programs don't look this unnatrual and
ugly. Well, here is some ML code that I have excerpted from the TIL Leroy
benchmark:
val Group_rules = [
(1, (1, (Term("*", [Term("U",[]), Var 1]), Var 1))),
(2, (1, (Term("*", [Term("I",[Var 1]), Var 1]), Term("U",[])))),
(3, (3, (Term("*", [Term("*", [Var 1, Var 2]), Var 3]),
Term("*", [Var 1, Term("*", [Var 2, Var 3])]))))];
val Geom_rules = [
(1,(1,(Term ("*",[(Term ("U",[])), (Var 1)]),(Var 1)))),
(2,(1,(Term ("*",[(Term ("I",[(Var 1)])), (Var 1)]),(Term ("U",[]))))),
(3,(3,(Term ("*",[(Term ("*",[(Var 1), (Var 2)])), (Var 3)]),
(Term ("*",[(Var 1), (Term ("*",[(Var 2), (Var 3)]))]))))),
(4,(0,(Term ("*",[(Term ("A",[])), (Term ("B",[]))]),
(Term ("*",[(Term ("B",[])), (Term ("A",[]))]))))),
(5,(0,(Term ("*",[(Term ("C",[])), (Term ("C",[]))]),(Term ("U",[]))))),
(6,(0,
(Term
("*",
[(Term ("C",[])),
(Term ("*",[(Term ("A",[])), (Term ("I",[(Term ("C",[]))]))]))]),
(Term ("I",[(Term ("A",[]))]))))),
(7,(0,
(Term
("*",
[(Term ("C",[])),
(Term ("*",[(Term ("B",[])), (Term ("I",[(Term ("C",[]))]))]))]),
(Term ("B",[])))))
];
Now I haven't spent the time tying to decipher this code. It appears that it
expresses some rules for an equational theorem prover. But this is
unintelligible.
Now the ML community can spend as much time as it wants arguing about abstract
syntax, suface syntax, and the like. And maybe they will eventually figure out
a way to write more intelligible versions of the above. But then they will
simply be reinventing the something that the Lisp/Scheme community has been
doing for almost 40 years.
Jeffrey Mark Siskind
This purpose of this message is to ask clarification questions, not to
flame. I find that I do not understand the argument that the ML folks are
raising and I want to try to understand.
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.
One can implement the Scheme object system in almost any programming language.
Whether or not it's implementation supports static type inference. That
includes Algol-68, PL/I, C, and ML. And one can transliterate Scheme to such
languages by a local transformation. This is well known. But I don't
understand why this makes these languages strictly more expressive than Scheme
or for that matter why ML would have this property when say Algol-68, PL/I, or
C would not.
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.
By `the overhead of all the tag manipulations' do you mean programmar overhead
or computational overhead? If you mean programmar overhead than I really don't
understand because I have been writing Lisp/Scheme code for 15 years, defining
my own data types for all of that period, and have never once written explicit
tag checking. If you mean computational overhead than that is a different
story. Yes, my Lisp/Scheme implementations do run-time checking (most of the
time). But that is a language implementation issue, not a language design
issue. One can imagine implementation of ML that do run-time checking (like
SML/NJ did at one point) and one can imagine implemetations of Scheme that do
static inference (like Stalin). Now if by `overhead' you mean computational
overhead then you must be refering to language implementations, not the
languages themselves. And I could understand an argument of the form TIL or
SML/NJ are run programs faster than Chez. But it appears that you are not
making such an argument. Or you could be making an argument that the design of
ML inherently allows for better compilers than Scheme. I could understand such
an argument. And it may very well be true. But I have yet to see such an
argument formulated in a well-expressed fashion. So please clarify this issue
for me. I really want to understand.
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.
I really don't understand what your notion of `type' is that would make ML
types defined by ML datatype constructs distinct types whereas Common Lisp
types defined by DEFSTRUCTs would all constitute a single type. Please clarify
this for me.
Tag checking is not type checking. (Sorry to quibble about terminology,
but we have to make distinctions if we are to get anywhere.)
I agree that without a common terminology we are not going to get
anywhere. But I don't understand the difference that you are making. Please
explain it to me.
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.
Please give me an example of data abstraction that cannot be performed in
Scheme but can be performed in ML. It will help me understand the point that
you are trying to make.
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.
Can you please elaborate on the above points. I don't understand what you mean.
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.
Again, I don't understand the above remark. It appears that everything is a
static type disipline. If not, than what is not a static type discipline?
Please give me an example. It will help me understand the point that you are
trying to make.
Summary: ML is strictly more expressive than Scheme because Scheme can
be faithfully transliterated into ML, whereas the reverse is impossible.
Please give me an example of an ML program that cannot be transliterated into
Scheme. It will help me understand the point that
you are trying to make.
Jeffrey Mark Siskind
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*),
I don't understand how the fact that such a translation needs analysis to
remove bunches of useless tag-checks is conceptually any different from the
fact that ML needs H-M type inference to decorate undecorated source code with
the information needed to remove bunches of useless tag-checks.
There are two points. One is what you point out: if you "strip" the ML
code to get Scheme code, you find that the detailed operational behavior
is not faithful to the ML precisely because of the tag manipulation.
You are confusing language definition with implementation. If you translate ML
code to Scheme code and compile the Scheme code with Stalin you will find that
the detailed operational behaviour *is* faithful to ML because there is no tag
manipulation.
Scot Dyerrivenburgh
This article has low Scheme content. Sorry.
wil...@cs.utexas.edu (Paul Wilson) writes:
>>While I know your editor does parenthesis matching for you, it only
>>matches one at a time and there are syntactic alternatives that are
>>much less parenthesis-rich. For such a language to support macros
>>though would entail the solution in the paragraph above....
>I certainly think a "more conventional" syntax with more visual
>markers could be designed without _too_ much difficulty for writing
>macros, but it's not an easy problem. Lots of tradeoffs.
Actually, I'm thinking "less conventional." Experience has shown me that
most function applications are applications to one argument. If we write
f x
instead of
(f x)
or
f( x )
we eliminate a pair of parenthesis to match. Thanks to basic algebra, we
may then write
g f x
in place of
(g (f x))
or
g( f( x ))
both of which I* claim are harder to read. Don't even get me started
about the evils of infix notations when you have to read big expressions.
There are other ways of eliminating some of the human work required to
understand syntax, like by using indentation to mark scopes (I know
I'll get flamed for even suggesting this, so let me say that I know
such a feature can be implemented as an option and also in such a way
as not to impose stylistic constraints). After all, humans use
indentation to reduce the amount of matching they have to do, why not
make this valid by making indentation part of the program? (How many
incorrectly indented programs have people brought you to fix? If you
can't indent it consistently, should you really be programming it?)
On the other hand, this takes us right back to the icky macro issue
that this thread is supposed to be -- a language with a "larger" syntax
than Scheme's would have an even more complex macro system. Since
we're already considering different types of program fragments (like
scopes), we're probably already half-way there.... ;-)
-- S W Dyer
ObScheme: Can anyone point me to a CLOS-style object system for Scheme?
(Of course, to have such a system one must first have types, at least
notionally.)
--
* There are actually people who measure human cognitive performance who
agree with me about this -- "human factors" engineers. They don't
work in programming language design -- yet.
Scott Draves
In article <4u7pmh$j...@garbo.cs.indiana.edu> d...@cs.indiana.edu (R. Kent Dybvig) writes:
| 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.
In article <GJR.96Au...@hplgr2.hpl.hp.com> g...@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas) writes:
gjr> I hate to beat on a dead horse, but static types do not allow you
gjr> to say anything more about a given program. Comments can be at
gjr> least as expressive, and in particular, you can choose a stylized
gjr> discipline that comes arbitrarily close to ML's type language.
gjr> The issue is purely whether you want them automatically checked
gjr> or not.
and the answer is `yes'. comments and variable naming conventions are
rarely enforced, always get out of date, and in general are a
disaster. putting static types through a back-door when they could be
tightly integrated is backwards.
gjr> ML imposes one such tool on all programs. Scheme does not.
not only does Scheme not impose it, but it makes it quite difficult:
such tools are just leaving the research stage now. the lack of
type-checking is just like the lack of standard macros (only half
resolved now) and modules (still): they balkanize the users and
prevent code interchange.
Bill Sommerfeld
Of course, is it worth it? For simplicity scheme's syntax is among the
best, but for ease of reading I would raise some questions. Most human
time spent learning how a program works is spent matching parentheses
or performing similar matching operations, the bottleneck of which is
the very small amount of short-term memory availible to the human.
Hmm. That's not been my experience.
While *reading* lisp or scheme (or C, for that matter, which is almost
as paren-rich albeit in a different way), I generally rely on
indentation to understand the "statement level" structure within a
function, and ignore (most) parens. I rarely use paren-matching
operators.
While *editing*, I use paren-matching a lot, to do things like figure
out exactly *where* in the sequence of 17 consecutive close-parens at
the end of the function to put the next expression..
While I know your editor does parenthesis matching for you, it only
matches one at a time and there are syntactic alternatives that are
much less parenthesis-rich.
When you tell it to indent an sexp, it matches a large number of
parens all at once for you..
- Bill
Paul Wilson
In article <izu3u96...@atomic.Princeton.EDU>,
Matthias Blume <bl...@atomic.cs.princeton.edu> wrote:
>In article <4uj5hf$1...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
>
> In article <izwwz85...@atomic.Princeton.EDU>,
> Matthias Blume <bl...@atomic.cs.princeton.edu> wrote:
> >In article <4ufr6k$6...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
> >
> >I don't think hygienic macros can do that.
>
> Yes, they can. At least, our macros can.
>
>Probably we have different ideas of what a module system should do.
>And I don't think that *my* idea of a module system can be realized
>with hygienic macros. But I can't say more before I have seen a
>specification of your module languages and/or your implementation.
>
>
> > Check out
> > http://www.cs.princeton.edu/~blume/macmod.ps
> >for a dicussion of this problem and a solution.
>
> OK. I wonder if your solution is the same as ours. In our solution,
> macros come first, and module scope is defined with macros.
>
>Well, then our solutions can't possibly be the same, because my
>solution requires the macro system to be already aware of the
>existence of nested scope and qualified names.
I think that's backwards from the Right Thing.
The core language should have the ability to to manipulate scope,
and that should be sufficient to implement module scope.
Trying to do things by traditional macroexpansion is the Wrong Thing,
although it has advantages for portability.
> [ ... ]
>Well, in this case the paragraph below doesn't apply. Your algorithm
>actually does expand macros --
No, it doesn't, at least in the sense of "expand" that makes sense to me.
We never rewrite expressions. It is not necessary. Identifiers are
resolved correctly by our compile-time environments. To compile
a use of a macro, you simply call the compiler recursively, handing
it the code for the macro and *two* compile-time environments. One
encodes the scope where the macro was defined, and the other encodes
the scope where it's used.
> but the result is not expressed in
>Scheme but in something roughly isomorphic to that.
It's not expressed in R4RS Scheme, but in core Scheme plus lexically-scoped
macros with an escape to bypass hygiene.
(Don't make too much of the "escape"---we're not doing tacky hackery.
All we need to do is be able to have a macro accept raw identifiers,
and then bind them in a local environment. The *interesting* scoping
tricks are doable with syntax-rules, because syntax-rules includes
an inference mechanism to tell when you're advertently capturing
a name.)
The core language understood by the compiler includes the ability to
manipulate scope. This is what you need for implementing just about
any scoping discipline you're likely to think of.
> >It might be the case that your compiler is written in such a
> >way that expressions of this intermediate language never really
> >materialize, because they are eliminated by some form of deforestation
> >(which was coded by hand).
>
> Nice glib description, and maybe not *too* far off.
>
> (Too bad you don't understand the significance.)
>
>What *is* the significance?
Hard to say, since I don't know what counts as significant to you.
But I think the right way to look at it is that we don't do macroexpansion
and deforestation, because macro expansion simply isn't necessary.
It's a holdover from Lisp thinking, or a portability hack.
It's backwards to say that our technique is an optimization of traditional
hygienic macroexpansion. I think it's closer to the truth to say that
our techniques solve the scoping problem directly, using an extension
of traditional (SICP-style) compile-time environments, and that traditional
hygienic macro expansion is an awkward kludge to achieve the same effect.
The whole business of "painting" or "tagging" variables and then stripping
the paint or tags off is just an awkward and hard-to-explain way of
emulating compile-time environments that directly encode the right
information.
The successive optimizations of hygienic macroexpansion algorithms
(using syntactic environments in the preprocessor/precompiler) approach
the direct way of doing it.
We just do it the direct way, with no preprocessor at all.
I think most of what we're doing is pretty much isomorphic to what others
do, and if you really want to you can identify the little parts of
our compiler that *correspond* to a preprocessor, doing rewriting steps.
I think you'd be wrong in saying that it *is* doing rewriting, because
rewriting-with-renaming is simply the wrong idea.
The difference between our system and a traditional hygienic macroexpander
may not be significant, if all you care about is being able to expand
syntax-rules macros. But when you start writing procedural macros that
do sophisticated analysses and optimizations, it gives you a much better
framework.
And when you're trying to identify the "core" langauge and the "right"
transformational facilities, thinking about renaming and rewriting will
lead you off into the weeds.
> >But this doesn't matter much.
>
> Rats. I guess we'll just have to junk that part of our research program,
> then, since you don't understand the merit of what we're doing.
> Back to the drawing board. :-)
>
>Deforestation certainly has its merits. I was just saying that
>whether it is done or not doesn't alter the principal mechanism
>underneath. You can still think of macros being expanded in the
>`traditional' way if this is convenient.
Yes, you can think of it this way, and for some simple purposes it
can be handy to explain things that way. It's an indirect and
misleading explanation, however.
To do what we do with a separate "expander", you'd have to effectively
emulate our system in a "macro processor" that is really a compiler
that understands scope-manipulating transformations. This is where
syntax-case seems to be headed.
If you push that idea through, then you find that precompiling to
Scheme isn't especially attractive. You've written a compiler for
Scheme-plus-macros that happens to emit Scheme-without-macros,
but it could just as well generate C. (That's exactly what our
RScheme compiler does. You could also generate ML, and we may
do that sometime, but it's not particularly interesting. We
might also generate TIL intermediate code to avoid having to go
through ML's front end.)
My claims here are that:
1. You cannot simply transliterate Scheme with macros into
into Scheme without macros (or ML). You have to *compile* it
into Scheme-without-macros, whether or not you call your
compiler a compiler.
2. Once you've recognized that, you can unify the "precompiler"
with the "compiler", and get something very interesting:
a compiler that lets you manipulate scope from within the
language, and which can be straightforwardly extended
so that it becomes a framework for analyses and optimizations.
In effect, you have a microkernel-like compiler that can
be extended with external analyzers and optimizers. You
also have a micro-language that is fundamentally transformational.
It isn't just lambda-calculus-with-added-sugar anymore.
> I wasn't criticising any
>particular approach.
Sorry, but I think you were. You were claiming that the points I was
making were insignificant, without understanding them, and you were
basically claiming that you have all the relevant answers already. Maybe
you do, and maybe when you understand what we're up to you'll still think
it's insignificant; I can't know that. But it's very tedious to have ML
bigots coming into comp.lang.scheme and minimizing what I consider
some of the most important and interesting issues in language and
compiler design, which Scheme basically gets *right* and ML doesn't
address at all.
If you're going to read comp.lang.scheme "for amusement value",
could you just giggle quietly to yourself?
Thant Tessman
In article <1996081016...@library.PPS>, r...@parcplace.COM (Richard
Gabriel) wrote:
[...]
> This is something I can comment on. When I teach people to write I
> tell them there is one criticism of their work that they cannot argue
> with: ``I don't understand it.'' It seems to me that if the ML folks
> and type theorists don't feel that their work has been understood
> (``so little of it appears to have gotten through''), then it is a
> failure to communicate, and the blame, if there is to be any, is on
> the ML/type folks' side. Certainly the remedy is to explain and
> illustrate better and not to think harder and understand better.
[...]
I don't buy this argument. I will admit that Scheme has a shallower
learning curve than SML, but C++ on the other hand is MUCH harder to fully
understand than SML. And its syntax is much uglier as well (amazingly
enough). The difference is that people are much more willing to put
energy into learning C++. It's a marketing issue, not an
understandability issue.
-thant
Mitchell Wand
Yes, Dick, you have indeed insulted both camps quite adequately. But when I
learned composition, I learned that you can't make a convincing argument (even
of opinions!) without backing your assertions with good supporting evidence.
Show, don't tell, as they say in the fiction biz. So I think you owe both
sides some more specifics on your assertions.
rpg> Bob, you wrote:
rpg> . . . But it pains me to see that so many people still don't
rpg> understand basic issues about type systems. So much progress has been
rpg> made over the last 10-15 years (especially), yet so little of it
rpg> appears to have gotten through to places where it could really matter.
rpg> This is something I can comment on. When I teach people to write I
rpg> tell them there is one criticism of their work that they cannot argue
rpg> with: ``I don't understand it.'' It seems to me that if the ML folks
rpg> and type theorists don't feel that their work has been understood
rpg> (``so little of it appears to have gotten through''), then it is a
rpg> failure to communicate, and the blame, if there is to be any, is on
rpg> the ML/type folks' side. Certainly the remedy is to explain and
rpg> illustrate better and not to think harder and understand better.
I agree in general, but adoption of technology, as you well know, is NOT just
a matter of explaining things better.
rpg> So, it seems that the ML/types community has its work cut out for it
rpg> - how to communicate about types so that everyone else ``gets it'' and
rpg> so that religious wars about languages is avoided. I think this is
rpg> your problem, not the audience's problem and I await the solution.
rpg> I find ML to be an abhorrent language to look at.
Please tell us what you find objectionable in the syntax of ML. There are
certainly things to criticize, but tell us which of them bother you, and why.
rpg> I count some of the most important papers about ML to be among the
rpg> worst written pieces I have ever seen. When I teach writing, I use
rpg> some of these pieces as laughable examples of technical writing.
We would all love to learn to write better. Please share with us some
examples of ML papers that you consider bad examples of technical writing, and
point out how they could have been improved.
rpg> This
rpg> is in contrast to some of the ideas underlying the language, which I
rpg> admire and consider important, and the implementation work, which I
rpg> believe is the best going on right now. It strikes me as no
rpg> coincidence that the ugliness of the language itself matches the
rpg> ugliness of the writing about it. I guess there just isn't much
rpg> artistry in the ML community (not none, just not much).
You are entitled to your opinions (positive OR negative) about the work, and
even about the writing. But I doubt any positive purpose is served by
artistic generalizations such as these. Is your goal to decrease animosity or
to increase it?
rpg> [Inflammatory allegory about Scheme deleted]
rpg> I'd say that Scheme's view of real programming matches that of the
rpg> early to mid '60's while ML's has leapt into the '70's somewhere
rpg> (which is good, which is good). I might even go with the early '80's
rpg> if it would causes less heartache to hear me say it.
There may be something to this; the Scheme Symposium last January had a number
of people trying to figure out how to bring Scheme into the '90's. But tell
us, please, just what important issues Scheme 9x or ML 9x need to address.
What do you need to get either of these languages into the 90's?
rpg> Ok, so I bet I've insulted both camps about equally. Let me leave the
rpg> ML camp with this challenege: Explain it so we get it, and don't sell
rpg> us a refrigerator and a programming language on the same visit.
Umm, I don't understand this comment. It seems that you are advising
theorists to sell type theory like refrigerators:
Me: Why should I want a refrigerator?
Salesman: With a refrigerator, you can keep your food cold and YOU DON'T HAVE
TO CARRY BIG BLOCKS OF ICE UP THE STAIRS!
Me: Sounds good! How do I get one?
Schemer: Why should I bother to learn type theory?
Type Theorist: With type theory, you can ....
Schemer: Sounds good! Where do I start?
Isn't this the kind of interchange you'd like to see?
--Mitch
Mitchell Wand Internet: wa...@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
Christian Lynbech
>>>>> "Daniel" == Daniel C Wang <dw...@andrew.cmu.edu> writes:
...
Daniel> I think the claim being made is that having that built-in
Daniel> type-checker/proof-checker/program-verifier lets you make
Daniel> certain correctness claims/assumptions that are difficult if
Daniel> not impossible to express in an untyped language.
Daniel> If you want to transliterate ML programs as well as the
Daniel> implicit correctness guarantees that you get from programming
Daniel> in ML you just can't do it nicely. So I think the claim being
Daniel> made is that you can't transliterate ML/statically type
Daniel> programs and the correctness constraints into
Daniel> Scheme/dynamically type programs.
I am confused.
If the claim is that there is things you can do with typechecking that
you cannot do without (such as rejecting certain programs at compile
time), then this is certainly correct.
If the claim is that you cannot do advanced typechecking in scheme,
then this is not correct. You can apply the typeanalysis through an
external tool that takes in programs and checks the contents. And
there is people that have done so, if I am understanding the preface
to Andrew K. Wright's PhD Thesis "Practical Soft Typing" correctly (I
haven't the entire thesis though, so I could be wrong!).
His work is in fact applied to scheme and a prototype is (according to
an appendix in the thesis) available via ftp in:
cs.rice.edu:/public/wright/match.tar.Z
Of course, such a checker is not built in to the language standard,
but I cannot see that the analysis is any less relevant or powerfull
if applied as a (sort of) preprocessing stage to actual
compilation/running.
Perhaps I should quickly quote the first paragraph from the abstract:
"Soft typing is an approach to type checking for dynamically typed
languages. Like a static type checker, a soft type checker infers
syntactic types for identifiers and expressions. But rather than
reject programs cotaining untypable fragments, a soft type checker
inserts explicit run-time checks to ensure safe execution."
---------------------------+--------------------------------------------------
Christian Lynbech | Computer Science Department, University of Aarhus
Office: R0.32 | Ny Munkegade, Building 540, DK-8000 Aarhus C
Phone: +45 8942 3218 | lyn...@daimi.aau.dk -- www.daimi.aau.dk/~lynbech
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Alan Bawden
Date: 11 Aug 1996 19:54:28 GMT
From: s...@cse.unl.edu (S W Dyer)
wil...@cs.utexas.edu (Paul Wilson) writes:
>BTW, I'm not married to Scheme's particular surface syntax, ...
Here I must differ. I've never seen this done, but I think it's
certainly possible to build a language with built-in datatypes for the
different kinds of parse-tree nodes that are used to represent it in
and a similar macro-defining tool could be created for this language,
you just use constructors like "function-call-expression",
"addition-expression", "conditional-expression", etc. instead of "cons"
when writing the macro.
It does seem like something like this would work.
The difficulty is not with what macros return as -output-, but with what
what they accept as -input-. The input to a macro can't necessarily be
represented using function-call-expressions and conditional-expressions
because, well, it might not actually be made up of -any- of those -- you
might well be using macros to construct your own new language. The genius
of representing program text using S-expressions is that S-expressions are
simple recursive data structures that are easy to manipulate (using `cdr',
`nth', `symbol?', `map' etc.) and they make very little commitment to any
particular higher level semantics -- which leaves you free to impose your
own additional semantics upon them.
S-expressions are an unusual little language engineering compromise, but it
proves to be remarkably difficult to come up with a superior one.
Paul Wilson
In article <BLUME.96A...@zayin.cs.princeton.edu>,
Matthias Blume <bl...@zayin.cs.princeton.edu> wrote:
>In article <4u7gus$i...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
>
> Scheme has macros, ML doesn't.
>
>I think the original argument was about the expressiveness of the two
>type systems.
I think it would be a good idea if we *all* clarified just what argument
we're having here.
I thought the original argument was about whether it was a good idea
to base new stuff like scsh on Scheme, or to use ML, since ML essentially
(allegedly) subsumes Scheme. This has split into to two somewhat interrelated
arguments about type systems and macros. What I remember most is somebody
asking Olin why he based scsh on Scheme instead of ML, and him saying
"macros".
The axe I've been grinding is that macros are important, and that ML doesn't
have macros, and secondarily that his may have something to do with type
systems. (I also made a weaker and semi-independent point that I don't
know if Hindley-Milner type systems are ultimately the way to go, because
I worry that a strong syntactic commitment to a particular type system
doesn't restrict flexibility to change the type system in useful ways.)
I also made the point that I'm uncomfortable with the ML community's
general system-building philosophy, which is more like Niklas Wirth's
"I design the language, you just use it" than Lisp's "here's something
you can extend pretty much any old way you like---be careful out there".
I have not claimed that you couldn't extend ML with macros without breaking
the Hindley-Milner type system, but I think there's something to worry about
there. There are really two issues to worry about. One is whether there
really is a problem, and the other is the pragmatic issue of whether
and when it will be established that there's no conflict---and when
the results will be available for use.
This is not just an issue of language design, but of system-building
philosophy. Scheme is too small for some purposes and everybody knows it,
but there's a back door: everybody has macros, even if they're not officially
standard. (And the standardization of syntax-rules is a big step forward.)
> 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.
>
>True. And indeed, I agree with you here: The only interesting thing
>about Scheme these days is its uniform syntax and hygienic macros.
I mostly agree, but with maybe a different assessment at the bottom
line.
What's good about Scheme is the flip side of Dick's group of monks
on a mountain in Italy. (I'm not an RRS author, but I've done
CS at a former monastery in Italy, and I kind like the image!)
Scheme's language design is very conservative in some ways, kind of
like Wirth's designs, but I like the basic paradigm it embodies much
better. The risk of being less conservative is that things will be
standardized in the *wrong* way, and restrict future options.
Until more is standardized, there will be annoying problems with
incompatible libraries.
I think Scheme is at a turning point. The conservative language design
has reached a point of diminishing returns, resulting in a diamond-like
jewel. Adding new features will gore some oxen, and maybe it can't
be done via the standardization process so far---and maybe it shouldn't
be done. (Maybe groups like mine and some like-minded friends should
design a new extended Scheme "standard" based on R5RS, with important
extensions that not everybody will go for. There might be multiple
competing standards if one group forms and succeeds, and others react
against it by organizing. That might be a good thing, at least livening
things up with controversy so that issues are forced.)
> >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.
>
>Again, he was talking about the type system.
This has certainly not been clear to me, and it is not clear from the
statement above. People have made the claim repeatedly, never once
qualifying it with "but of course you really can't because Scheme is
transformational and ML is not". It has appeared that people have
been making the leap from "the type system is transliteratable" to "the
language is transliteratable". The former is at least sort of true, but
the latter is simply false. I think its falsity is quite important.
It also has appeared to me that there's a been a leap to "therefore
ML subsumes Scheme and Scheme is obsolete", which isn't true for
a long list of reasons. Maybe I misinterpreted, but I think at this
point it would be good for people to clarify what they're *not* claiming,
since this stuff is open to misinterpretation.
Given what *I* take to the bottom line in this discussion---whether Scheme
is obsolete and is subsumed by ML---I am very resistant to letting such
(apparent) leaps slide by. (Maybe it's only one of the bottom lines,
and only for some people, but my impression is that this is a recurring
theme. Maybe I've misread some people's statements, and missed implicit
qualifiers, but I don't think I'm the only one.)
>You can take any Scheme
>program and translate it (straightforwardly) to ML and it will
>type-check.
I'd add the qualifier "but of course you really can't, because
the translation is not straightforward". (We may have different
thresholds for "straightforward.")
> 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,
>
>I have never been a fan of OO, and the purpose of MOPs escapes me entirely.
Fine. It doesn't escape me, and I think I know what I'm doing. I'm not
an OOP bigot, but I want objects and a MOP. They're handy. I'm willing
to explain that, but should I have to?
This is exactly the problem that I have with ML. Anything ML people don't
know the reason for, and how to do, and how to type check, you "probably
shouldn't be doing," so "we won't let you do it."
(I think Sheard's macroish system for ML is a pretty good example of this.
I'm not putting down his work, which appears good insofar as I understand
it, but it seems very ML-like that his macro language has limitations
to ensure termination. It's not Schemely, and it's not what I want.
I don't want the compiler to force me to prove to it that my macroexpanders
terminate. It's not bad to *let* me prove it, but a compiler that
rejects my program at meta-compile time---even if in fact they would
compile to provably type-safe code---is going a bit far! This seems
emblematic of the ML camp's approach to systems, raised to a meta-level:
we'll build neat things, but we won't let you build your own because we
don't trust you. Besides all that, I think these things are easier
to build in Scheme.)
The painful thing about this is that I like ML reasonably well, and
I lust after TIL, but I can't use ML to do some things I want to do
in any convenient fashion.
Again, this is not just a problem with the language, but with the
system-building philosophy. Scheme has some of the same problems with
the language, but not the actual systems. For example, I can use eval,
and I do---very sparingly, and in carefully controlled ways, but to good
purpose. It doesn't even bug me that eval's not standard Scheme.
For my sparing uses, it's usually not hard to adapt to whatever eval is
available on a decent Scheme system.
> record definition facilities,
>
>... are already in ML ...
ML's idea of records, that is.
> control constructs,
>
>... are subsumed by higher-order functions (although it is a matter of
>taste if one finds this solution pretty) ...
I don't always find it pretty, in practical terms, and ML doesn't
give me the ability to prettify it by transformation. ML implementors
get to prettify their core language by transformation, but they
don't give this ability to the users.
I think this is important. Most complex software systems end up
being programming languages, or perhaps several interacting programming
languages. What normally happens is that people implement *bad*
programming languages, and often don't even recognize them as programming
languages.
> parameterized module systems with inheritance,
>
>... are already in the language,
Not in the form I want, to support software system generators.
I need the ability to consistently refine multiple types
in parallel, to express covariance safely, *and* use transformations
that allow modules to transform their arguments before using them.
I'm not positive I *can't* do that in ML, in some way, but I don't
think so. (At least, not the transformations I have in mind.)
I also want procedure hooks into the type instantiation mechanism
so that I can have external design-rule checkers that warn about
fishy compositions. I want to implement something like an extensible
type system for the software composition process. This type
system should have first-class representations of types and
modules, so that I can build interactive program composition
tools.
(ML seems to be biased toward flattening out all forms of dynamism.
Sometimes I want dynamism, if only at a meta-level.)
> and average Joe-blow Scheme user will
>be hard-pressed to come up with a set of macros powerful enough to
>emulate the semantics of the ML module language ...
Fine. I never disagreed with this. But I would like to be able
to implement a cool new parameterized type system that makes it
easier to write reusable libraries, and _give_it_to_ Joe Blow.
I have a colleague (Don Batory) who has done just this, but can't
just give his type system away as a library, because it's hacked
into a C compiler in an awkward way. Bletch. It would have been
much easier in Scheme, especially with syntax-case, and even
easier with a MOP.
I want to write software system generators, for which I may
need to customize the parameterized type system. ML won't let me.
Scheme lets me build my own. As I said, and Greg said, it is
unfortunate that Scheme only provides low-level tools, when
I want higher-level frameworks. (By the way, that's *exactly* what
MOPs are for. If you don't believe in OOP, you could do something
similar in a more MLish way.)
I never claimed that ML isn't a pretty good language for Joe Blow.
I never claimed that Scheme was the best language for Joe Blow. I
agreed that Scheme is problematic because you have to build too
much stuff yourself.
I claimed that ML does not subsume Scheme, and that there are some
good reasons to prefer Scheme to ML for some purposes. (Mine,
for example, and I think Olin's.)
I may have overstated problems with ML, by leaving out some qualifiers,
I apologize. As I said before, ML is problematic for *me*, and I think
it is problematic for people like me, who do meta-level programming,
and I think such programming styles are more common than is realized,
and should be more common still
(I also said that ML is quite a nice language overall.)
>The following paragraph is taken from an earlier thread which was
>going on in the Scheme authors mailing list. Since people who defend
>ML are thought of a ``sneerers'' in this forum,
I think there's been a continuing misunderstanding, or set of
misunderstandings. You and I seem to agree on a whole lot of things,
and need to have a clearer discussion of what we disagree on.
I have nothing against ML or people who defend it, as long as they
don't oversimplify and make (what appear to be) too-broad claims.
We don't particularly like being told that we "still don't get it."
Some of us do understand some of that stuff, and are willing to learn,
and should be cut a little slack rather than being talked down to.
>it might be worthwhile
>to post it here as well:
>
>I wrote:
>``Even if I give the impression that my intent is to put
>Scheme down and tell everybody how great ML is -- this impression is
>slightly inaccurate. I have expressed my opinions of which direction
>I would like to see Scheme develop into. Usually I am in favor of
>more statically decidable information in the program, better means for
>expressing abstractions, better support for separate compilation, and
>simplicity.
I am in agreement with all of these goals, but we may disagree on
how to achieve them. I want a core language that's transformational,
and a bypassable framework erected on top of that. I don't want
the high-level features of the language set in stone as they
are in ML. I want to be able to bypass layers of abstraction and
build up new abstractions when necessary. I also want to be
able to do things dynamically, rather than statically, if I think
I have good reasons.
> My saying so involved mentioning the bad word ``type'',
>and some people are now jumping all over me.
I was certainly not attacking you for talking about types. I agree
that types are important, and that ML embodies some useful ideas.
I was just saying that I don't think ML's particular idea of types is
what I want, or what Scheme should have. There's already ML.
I realize that's a little unfair, and I don't really mean "take
it or leave it". Either ML should have macros, or Scheme should have
a portable and convenient way of building optional strong type systems,
or both.
> [ ... ]
>Regards,
>-Matthias
Brian Harvey
wil...@cs.utexas.edu (Paul Wilson) writes:
>I think Scheme is at a turning point. The conservative language design
>has reached a point of diminishing returns, resulting in a diamond-like
>jewel. Adding new features will gore some oxen, and maybe it can't
>be done via the standardization process so far---and maybe it shouldn't
>be done. (Maybe groups like mine and some like-minded friends should
>design a new extended Scheme "standard" based on R5RS, with important
>extensions that not everybody will go for. There might be multiple
>competing standards if one group forms and succeeds, and others react
>against it by organizing. That might be a good thing, at least livening
>things up with controversy so that issues are forced.)
This is, I guess, a more positive way to say the same thing as Dick
Gabriel's comment that Scheme is stuck in the '60s. (Since I, too, am
stuck in the '60s -- Ron Daniels for president! -- maybe that's why I
like Scheme so much. :-)
I would like the participants in this discussion (and especially you,
Paul, from whom I've been learning quite a lot lately) to take a moment
to talk about the implications of their views, if any, for beginning
computer science education. The reason I think this isn't such a bizarre
leap is that Scheme's "diamond-like" quality means that our freshman
students (or at least the best of them) can understand it through and
through, and I think this affects the way they write programs much more
profoundly than the sort of stylistic exhortations you get in Pascal class.
But are we teaching these students to understand a dead-end paradigm?
Is that what you guys are saying? And if so, do you have an accessible
route into your preferred paradigm(s)? I would hate to have to get our
freshmen to understand either type inference or transformational grammar
before they start writing programs--but perhaps I'm extrapolating badly
from the tone of this discussion among experts.
Thanks.
Jeffrey Mark Siskind
Harley Davis
wil...@cs.utexas.edu (Paul Wilson) writes:
> I think Scheme is at a turning point. The conservative language design
> has reached a point of diminishing returns, resulting in a diamond-like
> jewel. Adding new features will gore some oxen, and maybe it can't
> be done via the standardization process so far---and maybe it shouldn't
> be done. (Maybe groups like mine and some like-minded friends should
> design a new extended Scheme "standard" based on R5RS, with important
> extensions that not everybody will go for. There might be multiple
> competing standards if one group forms and succeeds, and others react
> against it by organizing. That might be a good thing, at least livening
> things up with controversy so that issues are forced.)
Your plan sounds similar to what we tried to do with EuLisp (and the
commercial dialect Ilog Talk) in the recent past, and I haven't yet
seen any better attempt in the Lisp community to update the two major
aging dialects while staying squarely within the Lisp language model.
Perhaps you should start there for some good ideas on how to bring
Scheme into the 90's.
-- Harley Davis
-------------------------------------------------------------------
Harley Davis net: da...@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
Daniel C Wang
lyn...@cobalt.daimi.aau.dk (Christian Lynbech) writes:
> >>>>> "Daniel" == Daniel C Wang <dw...@andrew.cmu.edu> writes:
> ...
> Daniel> I think the claim being made is that having that built-in
> Daniel> type-checker/proof-checker/program-verifier lets you make
> Daniel> certain correctness claims/assumptions that are difficult if
> Daniel> not impossible to express in an untyped language.
>
>
> If the claim is that there is things you can do with typechecking that
> you cannot do without (such as rejecting certain programs at compile
> time), then this is certainly correct.
I'm making this claim.
{soft typing stuff remvoed}
> Of course, such a checker is not built in to the language standard,
> but I cannot see that the analysis is any less relevant or powerfull
> if applied as a (sort of) preprocessing stage to actual
> compilation/running.
Having such a tool not built into the language standard is as bad as not
having a sufficently standard library that goes along with the standard.
(Think of C with out the ansi defined library functions or cpp) I think that
this whole conversation started because some one from the ML camp suggested
that rather than arguing about multi-return values the Scheme camp think
about adding such a system/tool to the Scheme standard.
Raymond Toy
wil...@cs.utexas.edu (Paul Wilson) writes:
>
> I think Scheme is at a turning point. The conservative language design
> has reached a point of diminishing returns, resulting in a diamond-like
> jewel. Adding new features will gore some oxen, and maybe it can't
> be done via the standardization process so far---and maybe it shouldn't
> be done. (Maybe groups like mine and some like-minded friends should
> design a new extended Scheme "standard" based on R5RS, with important
> extensions that not everybody will go for. There might be multiple
> competing standards if one group forms and succeeds, and others react
> against it by organizing. That might be a good thing, at least livening
> things up with controversy so that issues are forced.)
>
I, for one, would like to see something like this happen. There are
lots of scheme implementations out there and they're all different.
Some have hygienic macros; some don't. Some have object systems, and
some don't, and when they do, they're all different.
I'd love to see some kind of standardized scheme that would include
some the things that I take for granted in Lisp like structures and
CLOS. I've looked briefly at several implementations like STk,
RScheme, MrEd, Elk, and guile. Each of them has nice features, but
not all have everything that I want.
Basically, I want something like CLOS-like objects (STk), dynamic
loading of modules (most), and an easy to use GUI (STk, MrEd?,
guile?). I also want compiler comparable to CMU Lisp's compiler.
Stalin is apparently quite good, but the one time I tried it I didn't
like having to wait 20 minutes to compile a simple benchmark.
While I'm not totally familiar with the history of Lisp, it seems that
scheme is also headed that way: lot's of different implementations
with their own incompatible extensions that are all begging for some
kind of standard. Perhaps scheme will go the way of Lisp too---a
great language rarely used because no one could agree on a standard
until it was too late. I hope not!
No flames, please. I like Lisp and Scheme, and I'll continue to use
them, but life would be easier if I could write reasonably portable
object-oriented scheme that would run fast. Say as good as CMU Lisp
runs.
My 2 cents as a user of Lisp and scheme,
Ray
Paul Wilson
In article <4uqdtv$7...@agate.berkeley.edu>,>>I think Scheme is at a turning point. [ ... ]
>This is, I guess, a more positive way to say the same thing as Dick
>Gabriel's comment that Scheme is stuck in the '60s. [ ... ]
Yes, it is. Being stuck in the 60's can be a wonderful thing. (I think
Dick could relate to that.)
There are a lot of things that Lisp got right---or partly right---in
the 60's, and it's all been downhill from there, or maybe mostly uphill
but not necessarily in the right directions.
>I would like the participants in this discussion (and especially you,
>Paul, from whom I've been learning quite a lot lately) to take a moment
>to talk about the implications of their views, if any, for beginning
>computer science education.
OK. This is a subject that interests me a lot. (I'm currently writing
a book on Scheme and its implementation and extension, for use in
language and compiler classes---as well as being a reference on the
Right Way to do things :-) .)
>The reason I think this isn't such a bizarre
>leap is that Scheme's "diamond-like" quality means that our freshman
>students (or at least the best of them) can understand it through and
>through, and I think this affects the way they write programs much more
>profoundly than the sort of stylistic exhortations you get in Pascal class.
Yes.
>But are we teaching these students to understand a dead-end paradigm?
>Is that what you guys are saying?
No. The nice thing about Scheme for educational purposes is that it's *not*
a dead-end language. You can demonstrate just about any language principle
in Scheme, easily and in a small amount of code. There is no better language
for education.
> And if so, do you have an accessible
>route into your preferred paradigm(s)?
(Even though I said no to the previous question...) my preferred route is
to demonstrate language principles with implementations of langauges,
as many Scheme books do, in Scheme.
I think you could take this a lot further using macros and more
transformational programming. Scheme could be used to demonstrate more
principles more elegantly than it has been (even though I think some of
the Scheme-based books are among the best textbooks in CS).
>I would hate to have to get our
>freshmen to understand either type inference or transformational grammar
>before they start writing programs--but perhaps I'm extrapolating badly
>from the tone of this discussion among experts.
I don't think you have anything to fear from Scheme.
In regard to transformational grammar, you don't have to understand the
theoretical underpinnings---they're irrelevant except that they describe
something that is actually deeply elegant and useful. (For most purposes,
the theoretical terms are just something to bash theoretically-inclined
skeptics over the head with when they say that macros aren't a good thing
and/or aren't a theoretically respectable topic. Then you can get back to
real work.)
Transformational grammar is like lambda calculus. You can use it without
knowing any abstruse theory. (This is NOT a slam against theory. Often
the attempt to describe things theoretically shows that it's unnecessarily
complicated, and that alone justifies theory.) Many people have programmed
in Lisp for decades, using macros, without ever using the term
"transformational grammar", just as most Scheme programmers don't worry
about the lambda calculus when reading and writing code. Whether you talk
about it formally or just demonstrate a cool idea, it's straightforward and
powerful.
(Not to mention that most people in the world use transformational grammar
every time they speak or listen, and it works, even though most of them
have never heard the term. :-) )
Scheme makes it much easier and more intuitive to use transformational
grammar than Lisp ever did---it's what Lisp always should have been, in
many ways. In the 70's Scheme fixed what Lisp got wrong with scoping. Now
it's fixing what Lisp got wrong in terms of transformations. This is huge
progress. And it's light years beyond what you can do in other languages.
Scheme is just elegant and useful, and you use it. You learn by example,
and you learn a few powerful principles that aren't hard. And the easist way
to explain new principles is in terms of those few powerful principles.
("Look! you can implement let in terms of lambda and procedure calling,
as a macro... and by the way, you just used transformational grammar...
here's how to think about it so you can do it again in other contexts.")
The worst thing about having to explain Scheme grammar is all the other
languages with well-developed and complicated but deeply boring grammatical
categories. :-) We just need names for the simple-but-powerful stuff that's
actually worth knowing and using.
The best thing about Scheme grammar is that it's so close to the semantics
that you don't have to explain many excruciatingly unimportant ideas, like
operator associativity and LALR(k) parser generators.
For education purposes, it's nearly ideal.
The only interesting version of the "is Scheme a dead end" question is
whether it will ever be a smash hit outside of edcuational contexts.
I think that it *should*, but I don't know if it will. Things like
Guile and scsh are happening, but long overdue. We let Visual BASIC
and Tcl and Perl take over the world, when Scheme was a better core
language for the same purposes all along. We've let ML take over a
lot of our constituency, by failing to do the Lisp thing and give
them the tools to conveniently build the type systems they need.
(I prefer something in the middle ground between Common Lisp's
butt-ugly hack of a type system and ML's bondage-and-discipline
we-know-what's-good-for-you type system. There's got to be something
more principled than Common Lisp, but more flexible than ML.)
But for education purposes, these things are less critical. It's
easy to build prototype-quality prototypes of language features in
Scheme, to illustrate principles. To get good performance and
functionality, you sometimes have to rely on not-trivally-portable
features of underlying Scheme implementations.
As for type systems, I think one of the most important priniciples
to teach is that a type system is just a handy theorem prover for
certain kinds of invariants. A type system can be very useful,
but it's important to realize that it will never capture all the
different kinds of invariants---or more subtle properties---that
matter to program correctness.
I think one of the best ways to teach about things like covariance vs.
contravariance is to use a dynamically-typed language and teach
them as design principles rather than language features. Then
you can explain how a strong type system can assist you in checking
some of the properties you care about, if its abstractions are
appropriate, but is unlikely to capture all of the interesting
ones. The important thing to realize is that all languages
are knowledge-representation languages in some sense. If you
declare the wrong things to the system (by designing a bad
type hierarchy, for example), it will infer the wrong things.
(Garbage-in/garbage out applies at all levels.) And if it
is too lame-brained to let you explain your reasoning, and won't
let you say "trust me" now and then, it may get in your way.
Stephen J Bevan
In article <4uq9do$j...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
Fine. I never disagreed with this. But I would like to be able
to implement a cool new parameterized type system that makes it
easier to write reusable libraries, and _give_it_to_ Joe Blow.
I have a colleague (Don Batory) who has done just this, but can't
just give his type system away as a library, because it's hacked
into a C compiler in an awkward way. Bletch. It would have been
much easier in Scheme, especially with syntax-case, and even
easier with a MOP.
How easy is to take two independent macro based extensions and use
them in a program? If it takes no effort at all i.e. it just works
then great. However, if it isn't possible to get two independent
systems to work without rewriting either both to be aware of the other
then IMHO this diminishes the value of a macro system.
Marc Wachowitz
Harley Davis (da...@laura.ilog.com) wrote:
[in reply to Paul Wilson's suggestion of designing an Extended Scheme]
> Your plan sounds similar to what we tried to do with EuLisp (and the
> commercial dialect Ilog Talk) in the recent past,
> Perhaps you should start there for some good ideas on how to bring
> Scheme into the 90's.
In fact, I think one should take the current version 0.99 of EuLisp,
add hygenic macros (already alluded to as intention in 0.99 - though
not yet part of the spec), maybe polish things a bit (why would one
want to name a printing function "prin" instead of "print"? ;-), and
use levels 2 (or above) later for even more powerful stuff. [If having
a definition as proper superset of Scheme is important, it shouldn't
be hard to change the IMO quite few and relatively simple points of
real incompatibility; i.e. what can't be done portably with a few
simple macros and a library anyway.]
This might help not to take yet another decade until there are usable
results, while still having a quite clean - and cleanly extensible -
base. For a determined group of experts, who are willing to do this
without trying to push their particular traditional style/implementation
or something like that, I'd guess it wouldn't take more than a few
(non full-time) weeks, and would even be suitable to be done without
any personal meetings (i.e. on the net).
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Guillermo (Bill) J. Rozas
In article <SPOT.96Au...@goober.graphics.cs.cmu.edu> sp...@goober.graphics.cs.cmu.edu (Scott Draves) writes:
| From: sp...@goober.graphics.cs.cmu.edu (Scott Draves)
| Date: 12 Aug 1996 15:34:24 GMT
|
| In article <GJR.96Au...@hplgr2.hpl.hp.com> g...@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas) writes:
|
| gjr> I hate to beat on a dead horse, but static types do not allow you
| gjr> to say anything more about a given program. Comments can be at
| gjr> least as expressive, and in particular, you can choose a stylized
| gjr> discipline that comes arbitrarily close to ML's type language.
| gjr> The issue is purely whether you want them automatically checked
| gjr> or not.
|
| and the answer is `yes'. comments and variable naming conventions are
| rarely enforced, always get out of date, and in general are a
| disaster. putting static types through a back-door when they could be
| tightly integrated is backwards.
It is not if it allows me to have a customizable theorem prover
instead of being limited to a canonical one that I can't circumvent.
For example, the runtime overhead of array bounds checking is
typically much higher than the overhead of tag checking. Thus if I am
a performance bigot I might be far more interested in a theorem prover
that can prove non-local properties (via suitable inference and
declarations) about array indices than in eliminating a couple of tag
checks.
ML does not help me in any way to accomplish this goal.
Scheme at least gives me the syntactic hooks to add any additional
information that I want -- without having to worry about extending the
core compiler. In addition it is more honest and lets me know from
the start that static invariant checking is always a compromise
between what I can say (or how conveniently I can say it) and what the
tools that check the invariants understand and can prove.
| gjr> ML imposes one such tool on all programs. Scheme does not.
|
| not only does Scheme not impose it, but it makes it quite difficult:
| such tools are just leaving the research stage now. the lack of
| type-checking is just like the lack of standard macros (only half
| resolved now) and modules (still): they balkanize the users and
| prevent code interchange.
So let's rush and put in the wrong type system from day one and limit
what people say.
This is analogous to allowing only downwards funargs because we know
how to implement them, even if we have to go through contortions to
express something else.
Yes, upwards funargs (or full continuations) can cause all sorts of
pain to an implementation, but I wouldn't given them up. Similarly,
until I see a type system that I'm confident will not cramp my style,
I won't be happy with it and it will be premature for Scheme as a
mandatory component. By not fixing it to what is technologically
possible, it encourages experimentation, and additional research will
be done, while it might not by hardwiring it early.
Yes, lack of standardization is a problem, but things can be
standardized in layers, with optional components that can be ignored.
Paul Wilson
In article <STEPHENB.96...@sorrol.harlqn.co.uk>,
Stephen J Bevan <step...@harlequin.co.uk> wrote:
>In article <4uq9do$j...@roar.cs.utexas.edu> wil...@cs.utexas.edu (Paul Wilson) writes:
> to implement a cool new parameterized type system that makes it
> easier to write reusable libraries, and _give_it_to_ Joe Blow.
> I have a colleague (Don Batory) who has done just this, but can't
> just give his type system away as a library, because it's hacked
> into a C compiler in an awkward way. Bletch. It would have been
> much easier in Scheme, especially with syntax-case, and even
> easier with a MOP.
>
>them in a program?
Sometimes it's trivial, and sometimes it's almost impossible. It's
like any other software development problem---if things are orthogonal
(both conceptually and in implementation), they combine easily.
If they're not, they don't, and often you have to rethink the structure
of at least one of the things being combined.
This is why I believe in a layered language design and good support for
transformations.
Layers are important so that you can re-engineer the upper level(s)
of things that conflict, without re-engineering the lower levels if
they *don't* conflict.
When you're "lucky" (which is often correlated with clean design in
the first place, and foresight about fundamental issues), you can
often just combine things and they work. If you're a little less
lucky, you have to open things up a little and tweak them.
Often this shows you what was wrong with the design in the first place.
You end up simply improving the thing that caused the problems---it
becomes cleaner and more powerful. If you're lucky, you can preserve
the exact semantics of the changed component, perhaps extending them.
If you're less lucky, you have to make incompatible changes, with
the usual standardization and compatibility hassles.
In either of those relatively-lucky cases, though, openness is a win.
If the component's implementation can simply be improved, you can
distribute those changes as a library, so that everyone can use
them. If you have to make incompatible changes, it's still a lot
better to be able to distribute a portable implementation as a library.
There's much less resistance to change when you can simply distribute
a new library, and modify client code a little, than if you have to
dig down into each and every compiler (or whatever the next layer down
is) and modify it in unportable ways.
Open implementations have a lot of advantages, and I think they're
soundly in the Lisp/Scheme development tradition.
Traditionally, Lispers and Schemers have traded metacircular interpreters
around, so that people could run new languages or extensions in emulation.
With an open implementation, you can actually trade around *real*
implementations of things, implemented outside the compiler but
generating good quality code. You can extend your system to be the
new system, rather than emulating it in your system. This is how
CLOS was developed---a bunch of people experimented with Portable
Common Loops and it evolved into CLOS.
(You don't have to like where they took things to see the advantages
of the general open development paradigm. I happen to like the
CLOS MOP reasonably well, and want to steal ideas from it, as
many people have.)
>If it takes no effort at all i.e. it just works
>then great. However, if it isn't possible to get two independent
>systems to work without rewriting either both to be aware of the other
>then IMHO this diminishes the value of a macro system.
One of the nicest things about open implementations is that you can
quickly find out if what one person is doing conflicts with what
another is doing---you can share reasonable-quality prototypes and
find out in a hurry whether their basic external *or internal* abstractions
are compatible. This can help in developing later, higher-quality
versions that won't conflict either.
One of the nicest things about Scheme is its macro system makes
a lot of this stuff easier than it is in Lisp.