In article <9601041551.AA15114@grunt.adi.com>,
Franklin Chen <chen@adi.COM> wrote:
>email@example.com (Darius Bacon) writes:
>I'm surprised nobody besides me has mentioned that ML already has this
>kind of syntax, and that since the proposed ideas look so much like
>ML, nobody has said, "Hey, why don't we make Scheme look like ML?"
>(or to carry it further, "Hey, why don't we use ML instead, and create
>an ML shell?" :-))
Maybe you're reading the wrong newsgroup? :-)
But seriously, you're right, and I had thought about the fact that
functional languages often don't have parentheses around arguments.
I just didn't know what to say about it. I don't have enough experience
with ML, Haskell, or whatever to know what conclusions to draw from
those languages. And they're not popular enough that I can easily
use them to infer what's acceptable to programmers in general.
For my own purposes, I'd rather have an object-oriented scheme shell,
which can be arbitrarily extended by linking with RScheme modules.
A plain Scheme shell would be okay too, as long as I can implement
a superset using RScheme and objects.
I think a dynamically-typed language makes a convenient basis for
a shell, but I wouldn't argue that an ML shell is a bad idea. I just
For my own personal purposes, I'd like to carefully design a syntax
so that it wouldn't be problematic for lexically-scoped macros. I
assume that this has not been a design goal for ML, but I don't know
where the trouble spots would be. I am also trying to scope out
how to actually implement such a thing, and I have a Scheme compiler
that seems suitable lying around. I wouldn't know how to go about
it for ML.
>Equivalent of above:
>fun gosh wow =
> let val x = wow * wow
> val y = 42
> in if foo
> then x + y
> else ~ x
>Note that no parentheses at all are necessary for this example.
Yep. Darned close to what I'm talking about. I'm concerned about
the infix expressions, though, and how to disambiguate them from
function calls with arbitrary following symbols (e.g., an unbound
function that defaults to running an external program, with the
following stuff coerced to strings).
For some fixed set of infix operators, I assume that this can abe
done---and that's probably good enough---but I'm not clear on how to
do it yet. I want to be very careful not to screw up the parsing
of lexically-scoped macros, including local macros. (Our system handles
local macros, which is very useful, but it may complicate the syntax
issues. You can't count on knowing the syntactic role of many things
until you see how they're used---i.e., at the appropriate step of
Things can be simplified if we assume we're coming up with a "just a shell"
language, and just disallow the tricky constructs in shell scripts.
(E.g., you can't use local macros, or macros that use local macros.)
I'd really rather not take that step, because I don't believe in "just a
shell" languages---e.g., the Tcl disaster. People should be able
to write whole programs in the new syntax if they want to. And iff people
want to use the full power of the underlying language, they should be able
to, by just linking with the appropriate modules.
The goal, I think, is to come up with a language that's like Perl in
that it's relatively complete and has features for systems programming,
but like Scheme in that it's clean and well-designed and can be compiled
to efficient native code, and different in that the syntax isn't bad for
just typing commands interactively or writing trivial little scripts. One
language for everything! Call me crazy, but I think this can be done
reasonably well if we're clever.
And I think it'd be a big boon for Scheme. Much better to have an
alternative syntax than to have almost everybody use a completely
different, non-interoperable language.
>Franklin Chen firstname.lastname@example.org
>Applied Dynamics International
>3800 Stone School Road
>Ann Arbor, MI 48108
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (email@example.com)
| 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/)