Good Language/Bad Compiler
Bif
First, let me say that Inform is a great language. It's innovative and
extremely useful. The documentation is very good; I like the writing
style. The author also wrote two big games, which is a morale booster
for those of us slogging through our programming.
Secondly, let me say that the compiler sucks. It prints out five times
as many error messages as there are errors. It doesn't handle nested ifs
right.
Can you change the program so that it prints only one error message and
halts? And I think else's should always match the last if that doesn't
already have its own else; this makes some complicated routines more
readable (less unreadable).
--BIF
Andrew Plotkin
Bif (bifu...@geocities.com) wrote:
> First, let me say that Inform is a great language. It's innovative and
> extremely useful. The documentation is very good; I like the writing
> style. The author also wrote two big games, which is a morale booster
> for those of us slogging through our programming.
> Secondly, let me say that the compiler sucks. It prints out five times
> as many error messages as there are errors. It doesn't handle nested ifs
> right.
Sometimes and recently. :)
> Can you change the program so that it prints only one error message and
> halts?
Gack, no no no. No compiler should ever do this (and I don't know any
compiler that does.) It is often possible for the compiler to recover
from discovered errors, which means that it can *correctly* find errors
later in the program. I would much rather ignore a lot of spurious errors
than have to recompile six times to find six real errors.
> And I think else's should always match the last if that doesn't
> already have its own else; this makes some complicated routines more
> readable (less unreadable).
Inform 6 does this.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Matthew Russotto
In article <32AFE4...@geocities.com> bifu...@geocities.com writes:
}First, let me say that Inform is a great language. It's innovative and
}extremely useful. The documentation is very good; I like the writing
}style. The author also wrote two big games, which is a morale booster
}for those of us slogging through our programming.
}
}Secondly, let me say that the compiler sucks. It prints out five times
}as many error messages as there are errors. It doesn't handle nested ifs
}right.
You know, if you're trying to motivate someone to do something, telling them
that their product "sucks" is really counterproductive. If I'd done as much
work on something as Graham obviously did on Inform 1-6, and someone said
it "sucked", I'd think about throttling that someone and then discard their
message, ignoring any suggestions contained therein.
Besides, if it only prints out five times as many error messages as there are
errors, it's doing better than most C compilers.
Bif
Andrew Plotkin wrote:
> > Can you change the program [INFORM compiler] so that it prints only one error message and
> > halts?
>
> Gack, no no no. No compiler should ever do this (and I don't know any
> compiler that does.) It is often possible for the compiler to recover
> from discovered errors, which means that it can *correctly* find errors
> later in the program. I would much rather ignore a lot of spurious errors
> than have to recompile six times to find six real errors.
It's a question of preference. Would I rather go through the errors
sorting real from spurious or rather sit through a recompilation? With a
fast comPOOHter I'd pick the latter.
Can a command line option be put into the compiler to limit the number
of
error messages printed?
> > And I think else's should always match the last if that doesn't
> > already have its own else; this makes some complicated routines more
> > readable (less unreadable).
>
> Inform 6 does this.
Great! Inform is an example of very good amateur programming. :)
--BIF
"Good judgement comes from experience.
Experience comes from bad judgement"
-- Fred Brooks
Graham Nelson
In article <32B256...@geocities.com>, Bif
<URL:mailto:bifu...@geocities.com> wrote:
> It's a question of preference. Would I rather go through the errors
> sorting real from spurious or rather sit through a recompilation? With a
> fast comPOOHter I'd pick the latter.
Inform, however, has to run on a wider variety of platforms than any
commercial compiler I know of.
> Can a command line option be put into the compiler to limit the number
> of error messages printed?
It is already limited to 100. I'm not sure there's enough of a
constituency that would like things to be different!
> > > And I think else's should always match the last if that doesn't
> > > already have its own else; this makes some complicated routines more
> > > readable (less unreadable).
So do I, and so does Inform. There's something to be said for reading
the documentation on a product before declaring that it "sucks".
Perhaps I might explain, doubtless in a patronising fashion, why
compilers of C-like languages often generate strings of error
messages in which only the first few are particularly meaningful.
It is not a particular foible of Inform: it is a consequence of
the syntax of the language, in one sense, and of the design of
a fast syntax analyser in another. (That is, if you like Inform
for being fast, you have to accept that one penalty is that it's
not so good at error recovery and error reporting: for example
errors are not always produced in "the right order".)
The problem is that the syntax has a number of "modes", and the
compiler needs to be right about which one it's currently in.
For instance, the three really important modes for Inform are:
parsing the body of an object definition
parsing the code in a routine
parsing directives
When an error in the source code corrupts the beginning or
end markers, the syntax analyser finds itself (e.g.) trying to
parse code in a routine as though it were directives, and
this causes a cascade of errors. Errors not affecting such
beginning/end markers are usually recovered from without
difficulty.
You can observe the same behaviour under almost any C compiler,
typically by missing out the final } from a routine, or
the ; after a type declaration. The only way to entirely
avoid such difficulties is to design the language with essentially
no "modes" in the sense above (BASIC is broadly speaking such
a language). It's therefore ironic that this thread began with
the claim that Inform is a good language and a bad compiler,
then went on to blame the compiler for a consequence of the
language design.
I don't want to overdo the injured pride act. But Inform,
though it is certainly an amateur piece of work, is a quite
high-performance compiler by comparison with many, perhaps
even most, professional works. It is faster than my C
compiler by a good-sized factor, and consumes much less memory.
The comparison is not entirely fair, but not entirely
unenlightening, either.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Ad...@beachyhd.demon.co.uk
Hi Graham!
GN> I don't want to overdo the injured pride act. But Inform, though it is
GN> certainly an amateur piece of work, is a quite high-performance compiler
I don't see how Inform can be described as "amateur" at all, to be quite
honest..!
.\dam. [Team AMIGA] //\ Ad...@beachyhd.demon.co.uk \//
> Homepage at http://www.rdainfotec.demon.co.uk/adam
bout...@blade.wcc.govt.nz
In article <32b7...@beachyhd.demon.co.uk>, <Ad...@beachyhd.demon.co.uk> writes:
>Hi Graham!
>
> GN> I don't want to overdo the injured pride act. But Inform, though it is
> GN> certainly an amateur piece of work, is a quite high-performance compiler
>
>I don't see how Inform can be described as "amateur" at all, to be quite
>honest..!
>
Olympics.
-Giles
Matthew T. Russotto
In article <32b7...@beachyhd.demon.co.uk>, <Ad...@beachyhd.demon.co.uk> wrote:
}Hi Graham!
}
} GN> I don't want to overdo the injured pride act. But Inform, though it is
} GN> certainly an amateur piece of work, is a quite high-performance compiler
}
}I don't see how Inform can be described as "amateur" at all, to be quite
}honest..!
Well, Graham's not getting paid for it. Possibly another British
vs. American difference in connotation?
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
David Baggett
>I don't see how Inform can be described as "amateur" at all, to be quite
>honest..!
I think Graham simply means he's not getting paid for Inform, which is what
"amateur" really means.
And I don't see why it's OK to harshly criticize IF works that people write
for free, but it's not OK to criticize the tools. Those of you who are
lauding *or* criticizing Inform's language design: do you really know much
of anything about programming language design and implementation? (I know
Thomas Nilsson does, but how about the rest of you?)
I've spent a great deal of time reading about the subject over the past few
years, and it's quite clear to me that there are serious problems with
*all* the existing IF development systems, and that none of them deserves
anything like a "professional-quality compiler" label.
One very basic requirement for a "professional quality compiler" is that it
perform nontrivial optimizations like strength reduction; do any of these
compilers do that? For that matter, have any of the people writing these
compilers even thumbed through the Dragon Book to see what other people who
have designed languages and written compilers over the past 50 years have
done? This is, in the long run, what we should expect of the tool
designers, just as we ultimately expect our authors to have read the major
works of (interactive) fiction.
I don't mean to be pointlessly critical, and I'm not saying these tools are
useless (far from it), but if we're going to hold our fiction up to the
high standards of the literary world, shouldn't we fairly judge the tools
by the equivalent langauge design and implementation standards? I've said
myself that improved tools are the main reason (IMO) for IF's renaissance
in the 90's. But the flip side of the coin is that, as with the fiction,
we're nowhere near where we could be. Certainly there is no reason to put
a moratorium on criticisms of tools!
Dave Baggett
__
d...@ai.mit.edu
"Mr. Price: Please don't try to make things nice! The wrong notes are *right*."
--- Charles Ives (note to copyist on the autograph score of The Fourth of July)
Morten Pedersen
David Baggett wrote:
>
>
> One very basic requirement for a "professional quality compiler" is that it
> perform nontrivial optimizations like strength reduction; do any of these
> compilers do that?
Just exactly why does Inform need to do that, isn't the Z-code it
produces
fast enough?
--
Morten Holm Pedersen
Departement de Physique Theorique - Universite de Geneve
pede...@serifos.unige.ch http://mykonos.unige.ch/~pedersen/
Andrew Plotkin
David Baggett (d...@lf.ai.mit.edu) wrote:
> And I don't see why it's OK to harshly criticize IF works that people write
> for free, but it's not OK to criticize the tools. Those of you who are
> lauding *or* criticizing Inform's language design: do you really know much
> of anything about programming language design and implementation? (I know
> Thomas Nilsson does, but how about the rest of you?)
I took a class once. I have the Dragon Book you refer to...
> I've spent a great deal of time reading about the subject over the past few
> years, and it's quite clear to me that there are serious problems with
> *all* the existing IF development systems, and that none of them deserves
> anything like a "professional-quality compiler" label.
> One very basic requirement for a "professional quality compiler" is that it
> perform nontrivial optimizations like strength reduction; do any of these
> compilers do that?
This becomes a sore point, because there *is* a difference between Graham
and his spare time (on one finger), and MetroWerks (on the rest of the
platoon's appendages).
(Metrowerks is a Mac compiler vendor which started up a couple of years
ago and is now widely regarded as the best choice. They are a major
software company with revenues of $10 million a year. Graham is a bored
professor.)
It would be lovely if Inform applied all the optimizations that I expect
from Metrowerks' compiler, or even from gcc. I don't know what
optimizations it does provide. (I know it does some. See the tech
manual.) If it misses some, however, I don't regard it as a "major
problem".
It's a nuisance that a few games have come up against the resource limits
of the V5 Z-machine (notably Jigsaw -- even though there's a V8 version,
Graham said recently that some scenes were trimmed to make the V5 version
fit.) But you'd have to demonstrate that a typical game *could* be shrunk
significantly by optimization. I don't believe a C-like language on a
registerless architecture *has* many nontrivial optimizations. (Trivial
ones, like moving complex expressions out of loops, tend to be done by
hand by C-native hackers -- me, anyway. I admit that CSE elimination would
be nice.)
Put it this way: I would love to write a Mac Web browser that didn't
suck. But I simply can't compete with MS and NS. They can implement
"professional" features faster than I can *read* about them. (You decide
whether these are actually useful features, but it *is* what the market
wants.) Because of this, I haven't bothered. Therefore, I use a Web
browser that I hate. Is this bad? I think it is. I'm certainly glad that
there are amateur IF systems out there as opposed to none at all.
(Please don't write back pointing out the flaws in this analogy. It's not
a parallel, it's a point of view on the question of whether amateurs
should write software.)
> This is, in the long run, what we should expect of the tool
> designers, just as we ultimately expect our authors to have read the major
> works of (interactive) fiction.
Sure. I'm sure you noticed the total rewrite that went into Inform 6.
> I don't mean to be pointlessly critical, and I'm not saying these tools are
> useless (far from it), but if we're going to hold our fiction up to the
> high standards of the literary world, shouldn't we fairly judge the tools
> by the equivalent langauge design and implementation standards? I've said
> myself that improved tools are the main reason (IMO) for IF's renaissance
> in the 90's. But the flip side of the coin is that, as with the fiction,
> we're nowhere near where we could be. Certainly there is no reason to put
> a moratorium on criticisms of tools!
The other problem is that the particular criticisms that were posted
were, uh, unuseful. One change request which has already been
implemented, and one that badly misunderstood the way compilers are used
(although I don't object to the idea of a user-controllable option for
"max number of errors to tolerate.")
Marnix Klooster
d...@lf.ai.mit.edu (David Baggett) wrote:
> And I don't see why it's OK to harshly criticize IF works that people write
> for free, but it's not OK to criticize the tools. Those of you who are
> lauding *or* criticizing Inform's language design: do you really know much
> of anything about programming language design and implementation? (I know
> Thomas Nilsson does, but how about the rest of you?)
>
> I've spent a great deal of time reading about the subject over the past few
> years, and it's quite clear to me that there are serious problems with
> *all* the existing IF development systems, and that none of them deserves
> anything like a "professional-quality compiler" label.
Could you expand on this from the language design point of view
(as opposed to language implementation)? I've been thinking
about what features I would like to have in a general-purpose
imperative, perhaps OO, programming language, and if such a
language would be good to write IF in. What features should an
IF implementation language have, in your opinion?
> Dave Baggett
De beste wensen,
<><
Marnix
--
Marnix Klooster | If you reply to this post,
mar...@worldonline.nl | please send me an e-mail copy.
William Bryant
In <erkyrathE...@netcom.com> erky...@netcom.com (Andrew Plotkin)
writes:
>David Baggett (d...@lf.ai.mit.edu) wrote:
>> And I don't see why it's OK to harshly criticize IF works that
people write
>> for free, but it's not OK to criticize the tools. Those of you who
are
>> lauding *or* criticizing Inform's language design: do you really
know much
>> of anything about programming language design and implementation?
(I know
>> Thomas Nilsson does, but how about the rest of you?)
>
>
such title, latest edition about 1992?
William Bryant
wbr...@ix.netcom.com
Mark J Musante
David Baggett (d...@lf.ai.mit.edu) wrote:
> I think Graham simply means he's not getting paid for Inform, which is what
> "amateur" really means.
>
> for free, but it's not OK to criticize the tools.
[ snip ]
To answer the last question first, I *have* read the Dragon book. In fact
I've written an optimising pascal compiler as part of my graduate studies.
Having said that, I still don't feel qualified to critique the compiler or
language at all. In order to do that, I think I'd have to create my own
language & compiler. Has anyone done that? Is it possible to
compare/contrast different Z-Machine compilers? I think Inform's the only
one (currently available, that is).
However, I feel compelled to say that I think you're right that the Inform
compiler should be criticized -- but it should be done so constructively. If
memory serves, this thread was started when someone said, quite bluntly, that
Inform sucks. This is not a helpful criticism and has the added benefit of
being untrue. If someone feels that Inform is lacking in some are or
another, then certainly say so; and also say *why* you believe that to be
true.
- Mark
Matthew Russotto
}And I don't see why it's OK to harshly criticize IF works that people write
}for free, but it's not OK to criticize the tools.
I'll remember that next time someone gets defensive about a certain library...
}Those of you who are
}lauding *or* criticizing Inform's language design: do you really know much
}of anything about programming language design and implementation? (I know
}Thomas Nilsson does, but how about the rest of you?)
No, Dave, I'm just a complete ignoramus about such things, saying things at
random according to whatever strikes my fancy.
}I've spent a great deal of time reading about the subject over the past few
}years, and it's quite clear to me that there are serious problems with
}*all* the existing IF development systems, and that none of them deserves
}anything like a "professional-quality compiler" label.
Perhaps true, but not for the reasons you've stated. Not handling low
memory conditions gracefully, for instance, is one quality problem.
}One very basic requirement for a "professional quality compiler" is that it
}perform nontrivial optimizations like strength reduction;
Who says? IMO, the availability of an optimizer is a matter of power or
features, not quality. Quality is how well the tool does it's job, not which
job it does. Oh, and while the "professional" compilers from IBM (xlc) and
Sun (SparcWorks C) do include those optimizations, they long contained many
bugs which made them worse than useless. The project I maintain at work STILL
doesn't turn optimization on precisely because of this. That's what I'd
call "not professional quality". Better no optimizer than one which produces
incorrect code.
}do any of these
}compilers do that? For that matter, have any of the people writing these
}compilers even thumbed through the Dragon Book to see what other people who
}have designed languages and written compilers over the past 50 years have
}done?
Have you read the Inform technical manual?
}I don't mean to be pointlessly critical, and I'm not saying these tools are
}useless (far from it), but if we're going to hold our fiction up to the
}high standards of the literary world, shouldn't we fairly judge the tools
}by the equivalent langauge design and implementation standards? I've said
}myself that improved tools are the main reason (IMO) for IF's renaissance
}in the 90's. But the flip side of the coin is that, as with the fiction,
}we're nowhere near where we could be. Certainly there is no reason to put
}a moratorium on criticisms of tools!
Ignorant criticism, however, is useless. There's been plenty of criticism
of TADS (including a certain nameless library), Inform (including the
hanging-else bug), AGT (nevermind), etc. But saying that a tool "sucks"
because of two problems, one of which has been fixed and the other which is
common (and not considered a bug) even in "professional quality" compilers,
isn't a useful criticism. Nor is implying that the authors of these tools
haven't read anything about how these tools are written, when a small amount
of research would indicate otherwise.
Graham Nelson
In article <59cimp$2...@life.ai.mit.edu>, David Baggett
<URL:mailto:d...@lf.ai.mit.edu> wrote:
>
> >In article <32b7...@beachyhd.demon.co.uk>, <Ad...@beachyhd.demon.co.uk> writes:
>
> >I don't see how Inform can be described as "amateur" at all, to be quite
> >honest..!
> "amateur" really means.
Quite. In England it has old-fashioned connotations of gentility,
too (who would be a rude mechanic?).
> And I don't see why it's OK to harshly criticize IF works that people write
> for free, but it's not OK to criticize the tools.
I agree entirely.
> I've spent a great deal of time reading about the subject over the past few
> years, and it's quite clear to me that there are serious problems with
> *all* the existing IF development systems, and that none of them deserves
> anything like a "professional-quality compiler" label.
I think most of the weaknesses in Inform are due to (minor) flaws
in the language design, rather than the compiler itself, at
present. In some ways I would like to tear up the language design
and reshape some of it, but there's far too much existing code
which would be disrupted.
> One very basic requirement for a "professional quality compiler" is that it
> perform nontrivial optimizations like strength reduction; do any of these
> compilers do that?
Guilty; I don't know what "strength reduction" is. The Inform
compiler optimises for code size, except for some fiddling around
with "for" loops. Speed is not as serious an issue with Inform
as it as with TADS (for WorldClass users on low-end machines,
perhaps) -- but I doubt speed is a very serious issue for any
system. Whereas speed of compilation and amount of memory used
by the compiler are both important to users of this newsgroup,
I believe. Inform keeps only very local parse trees for both
reasons.
Besides this, optimisation theory is heavily dependent on the
hardware model. Inform compiles to a machine for which the
standard assumptions (you have many memory cells, but few
registers, etc.; the stack is expensive to use for temporary
storage) do not hold.
> For that matter, have any of the people writing these
> compilers even thumbed through the Dragon Book to see what other people who
> have designed languages and written compilers over the past 50 years have
> done? This is, in the long run, what we should expect of the tool
> designers...
The Dragon Book is cited at several points in the Inform Technical
Manual, as a convenient reference for shift-reduce parsing, hash
coding (where the Dragon Book has useful pragmatic advice) and
so on. Other standard algorithms, such as red-black tree balancing,
can also be found in Inform. The Inform lexer is a hand-coded
improvement on the typical lexer produced by "yacc". So I think
I can acquit myself on this score. (In fact, the only part of the
Dragon Book which Inform 6 is not heavily indebted to is the
section on compiling 3-address code to machine code: this is because
the Z-machine essentially runs 3-address code already.)
> I don't mean to be pointlessly critical, and I'm not saying these tools are
> useless (far from it), but if we're going to hold our fiction up to the
> high standards of the literary world, shouldn't we fairly judge the tools
> by the equivalent langauge design and implementation standards?
Yes! I spent significant amounts of time writing Inform 6 from
scratch, reimplementing the entire compiler, exactly because of
this (resulting in very large speed increases). I'm only saying
that the image of existing tools as entirely casual programs may
be a trifle unjust. One doesn't have to be a professional to have
read the basics of the professional literature.
Magnus Olsson
In article <59cimp$2...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
>In article <32b7...@beachyhd.demon.co.uk>, <Ad...@beachyhd.demon.co.uk> writes:
>>I don't see how Inform can be described as "amateur" at all, to be quite
>>honest..!
>
>I think Graham simply means he's not getting paid for Inform, which is what
>"amateur" really means.
Well, there is "professional" software that people are giving away for
free as well: GNU, FreeBSD, Linux (IMHO, at least some of that software
is just as professional as commercial counterparts - the Gnu C
compiler, for example, is one of the best Unix C compilers around).
There are many denotations of "amateur" - and even more connotations,
not all of the flattering. But whatever we put into that word, I think
it's important to realize that all the IF languages being discussed
here are written and maintained for free, as a labour of love, and
often by people who aren't professional programmers. This means that
we shouldn't - and can't - expect them always to compare favourably to
commercial products. (Mind you, in some aspects they do, but in others
they don't).
>And I don't see why it's OK to harshly criticize IF works that people write
>for free, but it's not OK to criticize the tools.
It has been alleged that the atmosphere of r.a.i-f is such that any
criticism of certain people, or certain software, is "forbidden". I
think such allegations are vastly exaggerated, and I hope it will
never be so. Criticism, and discussion of how things can be improved,
is essential. However, let's keep it polite.
>Those of you who are
>lauding *or* criticizing Inform's language design: do you really know much
>of anything about programming language design and implementation? (I know
>Thomas Nilsson does, but how about the rest of you?)
I'd say I know quite a lot about it. Not enough to put me on the level
with a professional compiler writer, but I do think I know what I'm
talking about most of the time. I don't feel like quoting my
resume here and now, but feel free to email me if you don't want to
take my word on it.
--
Magnus Olsson (m...@df.lth.se)
David Baggett
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
>This becomes a sore point, because there *is* a difference between Graham
>and his spare time (on one finger), and MetroWerks (on the rest of the
>platoon's appendages).
Is it also a sore point that we're writing IF games in our spare time, so
that when someone compares our works to "real" literature, it's not fair?
I say that's garbage.
And if it's a sore point, why claims like this:
"But Inform, though it is certainly an amateur piece of work,
is a quite high-performance compiler by comparison with many,
perhaps even most, professional works."
This is like someone saying their IF game is as good as many, even most
professional works of fiction. It's not inconceivable, but it's certainly
a statement that would come under quite a bit of scrutiny. I don't think
anyone would say anything about spare time work in evaluating it.
>[Metrowerks is] a major software company with revenues of $10 million a
>year. Graham is a bored professor.
But Kernighan and Ritchie were so different? We all have to live with
their choices, however professionally made, about language design and
implementation. The fact that they were writing Unix and designing C
partly on a lark doesn't exonerate them, frankly.
>If it misses some [optimizations], however, I don't regard it as a "major
>problem".
I didn't say that lack of optimization was a major problem. I said it was
an indication of a non-"professional" compiler. If you want an example of
a major problem, how about this: why are we writing text-based interactive
fiction in variants of a low-level systems programming language? This is
*not* a systems programming task; in fact it's at nearly the exact opposite
side of the spectrum. (This doesn't just apply to Inform, of course.)
>(Trivial ones, like moving complex expressions out of loops, tend to be
>done by hand by C-native hackers -- me, anyway. I admit that CSE
>elimination would be nice.)
ARRRGGH! We're writing interactive fiction here! People writing this
stuff shouldn't be expected to code like C hacks! There's no reason for
it...
>I'm certainly glad that there are amateur IF systems out there as opposed
>to none at all.
Ditto, of course.
>The other problem is that the particular criticisms that were posted were,
>uh, unuseful. One change request which has already been implemented, and
>one that badly misunderstood the way compilers are used ...
I don't agree that compilers for C-like languages *must* have the error
cascade problem, even though it's true that many professional C(++)
compilers do. And I certainly don't agree that C is a good choice of basis
for an IF language. And no matter what anyone thinks, it can't be good to
go into semi-flame mode when someone critcizes either tools *or* games...
David Baggett
In article <32ba50f5...@news.worldonline.nl>,
Marnix Klooster <mar...@worldonline.nl> wrote:
>What features should an IF implementation language have, in your
>opinion?
[I sent this note to Marnix, but decided to post it as well, in slightly
edited form.]
It's not so much features; if anything, it's that these languages have too
many features that ought to be in libraries, not hard-wired into the
language. As a consequence, the features are not very extensible, and you
have to spend lots of time learning special, bizarre syntax to be able to
use them or read other people's code.
My feeling is that a language should provide only the primitives you need,
and that everything else should be defined in terms of those primitives.
The designer should ensure that these primitves can be combined in such a
way that a compiler can perform useful optimizations, and the compiler
writer should ensure that the compiler takes advantage of the good design.
Neither of these things is by any means easy, which is why so many people
who "roll their own" languages screw them up.
As I've said before, I think Scheme is a really good base language to build
an IF system around. It has very few primitives, but the primitives are
extremely powerful in combination. There are well-known optimizations that
work well on Scheme code. And you can do things in Scheme that you can't
do easily in most other languages. Here are two examples:
1) 1st class functions. I can write a Scheme function that makes me a new
function with whatever properties I want. A very basic example relevant to
IF is this: suppose you want a function that tallies the weight of the
contents of a container. In TADS or Inform, you'd generally write this
directly, by iterating over the contents and adding up the values of all
the weight properties. In Scheme you can write a function that calls an
arbitrary function on each contents item, like so:
(define (do-contents obj score-func combine-func)
;; call score-func on each item in the (recursive) contents of obj
;; then combine all the scores into a single result using
;; combine-func.
Then the weight computer reduces to a call like this:
(do-contents backpack (lambda (obj) (weight-of obj)) +)
So this calls (weight-of) on each object, and then adds all the results
together using the + function. (Note that + is a function just like
do-contents, and vice versa; + does not have special status except perhaps
that the compiler may have been told to inline it very aggressively)
Why is the do-contents solution better? Because you can do *lots* of
things with do-contents. You can search for an object with a
particular property (more on this in a moment), use it to return you a
"flattened" list of the recursive contents, and lots of other things
one typically does in IF code. And since you already have do-contents
written and debugged, you don't need to repeat this work or risk
introducing new bugs.
This all works because the (lambda) function returns a function, which
can be passed off to some other part of the program.
2) Continuations. There's a Scheme primitive called call/cc that lets you
write elegant and readable code that does non-local exits. A simple use of
this is bailing out of a complicated (potentially recursive) computation
when some condition is met. Suppose we've got do-contents, defined above,
and we'd like to use it to search for a particular element in the recursive
contents. For the sake of efficiency, we'd also like to terminate the
search when we've found a matching object and skip the combine-func phase.
(No need to search once we've found our match, and no need to combine since
we've only got one thing.)
We can use continuations to do this. Here's our call:
(call/cc
(lambda (bail-out) ; (#)
(do-contents backpack (lambda (obj)
(when (match obj)
(bail-out obj))) #f)))
The call/cc primitive makes a function that, when called, will "teleport"
the computation back to the point of its own return value, and will return
the argument specifed. call/cc passes this teleportation function to the
arbitrary function you specify (the function labeled # above, in this
case). Then you can use the teleporation function wherever you want, just
like any other parameter. In our case, we call it inside the function that
we pass to do-contents, so that when we get a match we can immediately bail
out of the search and return back to the point of the call/cc call.
call/cc can be used for more complicated things, too. For example, you can
implement a tiny multitasking kernel in Scheme using call/cc to suspend and
restart processes. And you can implement backtracking searches a la
Prolog.
These are the kinds of features that are *good* to put in a language.
They're powerful, very general-purpose, and (though it's not obvious at
first) combine very efficiently, and without obscuring optimzation
opportunities.
If these examples seem esoteric, well, remember this: programming languages
train you not to want power they don't provide. Once you're used to
working with things like 1st class functions and continuations, you can't
stand writing code without them.
(Another good example is macros. Scheme's macro processor is... Scheme,
and with all your library routines to boot.)
Finally, not that, except for the macros, nothing in Scheme really depends
on the lispy syntax. Dylan is a language that does a lot of what Scheme
does (and with OO thrown in for good measure) without the (((((syntax))))).
David Baggett
In article <59evu4$4...@sjx-ixn4.ix.netcom.com>,
William Bryant <wbr...@ix.netcom.com> wrote:
>The "Dragon Book" wouldn't be "programming compilers in C" or some
>such title, latest edition about 1992?
Here's a Library of Congress listing for it:
Aho, Alfred V. Compilers, principles, techniques, and tools /
Reading, Mass. : Addison-Wesley Pub. Co., c1986. x, 796 p. : ill. ;
24 cm. LC CALL NUMBER: QA76.76.C65 A37 1986
There was an earlier edition with a slightly different title.
The book covers the basics of writing compilers for imperative languages
like C, Pascal, and FORTRAN. It's a bit dated, in that it doesn't talk
much about static type inference (a la ML), though it does mention it.
David Baggett
In article <59f5q8$v...@bartlet.df.lth.se>,
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>But whatever we put into that word, I think it's important to realize that
>all the IF languages being discussed here are written and maintained for
>free, as a labour of love, and often by people who aren't professional
>programmers.
Yes, and the same is true of Matt Barringer's Detective! I don't recall
anyone holding back on that...
>It has been alleged that the atmosphere of r.a.i-f is such that any
>criticism of certain people, or certain software, is "forbidden".
Well, it certainly does seem that way, doesn't it? Or is my hostility
detector getting false positives?
>Criticism, and discussion of how things can be improved, is
>essential. However, let's keep it polite.
Agreed, of course; as polite as reviews of games, for example?
>...but I do think I know what I'm talking about most of the time. I don't
>feel like quoting my resume here and now, but feel free to email me if you
>don't want to take my word on it.
Magnus, I can't tell you how little interest I have in your resume or in
getting into another pissing match with you or anyone else here. So forget
it.
The point is, we don't pay attention to ill-informed praise or criticism of
IF works, so why should we treat the tools differently? As (I believe)
Gareth said, this isn't Kindergarten.
Magnus Olsson
>writes:
>>
>>David Baggett (d...@lf.ai.mit.edu) wrote:
>people write
>are
>>> lauding *or* criticizing Inform's language design: do you really
>know much
>>> of anything about programming language design and implementation?
>(I know
>>> Thomas Nilsson does, but how about the rest of you?)
>>
>>
>such title, latest edition about 1992?
"Compilers: Principles, Techniques and Tools", by Aho, Sethi and Ullman.
I daresay a lot of people on this newsgroup have read the book, or at
least had it as required reading on some course. Most CS departments
use it, it seems.
But I think that the design of the *language* is far more important
than the design of the compiler. After all, a suboptimal compiler
design can be replaced by a better one transparently to the user (as
the Inform 6 compiler is a total rewrite compared to previous ones),
but a language tends to conserve its features, good as well as bad. I
suppose Fortran is the prime example of this. It must have taken
considerable courage on Graham's part to "fix" the dangling else's in
Inform, knowing that a lot of existing code would probably break.
--
Magnus Olsson (m...@df.lth.se)
David Baggett
In article <59g6p8$g...@bartlet.df.lth.se>,
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>But I think that the design of the *language* is far more important than
>the design of the compiler.
>...
>It must have taken considerable courage on Graham's part to "fix" the
>dangling else's in Inform, knowing that a lot of existing code would
>probably break.
Language design is critically important, but it cannot be done in the
absence of an understanding of how compilers are properly implemented.
Having to fix something as basic as improper dangling else in the 6th major
revision of a programming language shows totally ad-hoc design *and* a
refusal to use appropriate tools for the job of parsing in the compiler.
Everyone whose Inform 5 code is now invalid has to pay for the poor design
and implementation of Inform 5. I cannot see how you can put a positive
spin on this and keep a straight face.
And it's not just Inform. TADS had a similar upheaveal from v1 to v2, and
it, too, uses a hand-coded parser with plenty of bugs over the years.
Graham Nelson
In article <59fo51$l...@life.ai.mit.edu>, David Baggett
<URL:mailto:d...@lf.ai.mit.edu> wrote:
>
> In article <59evu4$4...@sjx-ixn4.ix.netcom.com>,
> William Bryant <wbr...@ix.netcom.com> wrote:
>
> >The "Dragon Book" wouldn't be "programming compilers in C" or some
> >such title, latest edition about 1992?
>
>
> Aho, Alfred V. Compilers, principles, techniques, and tools /
> Reading, Mass. : Addison-Wesley Pub. Co., c1986. x, 796 p. : ill. ;
> 24 cm. LC CALL NUMBER: QA76.76.C65 A37 1986
Aho, Sethi and Ullmann, to give all three authors.
The above is the second edition.
Andrew Plotkin
David Baggett (d...@lf.ai.mit.edu) wrote:
> The point is, we don't pay attention to ill-informed praise or criticism of
> IF works, so why should we treat the tools differently? As (I believe)
> Gareth said, this isn't Kindergarten.
On the contrary -- ill-informed criticism of IF works provokes the
biggest flames around here. Not so much specific works, but the
philosophy of IF authorship (or reasons why there shouldn't be any.
Philosophy, I mean.) (And, of course, for each such flame there's someone
who thinks the criticism was *well*-informed.)
I know I've filled your shorts with napalm on the subject in the past, so
don't look so ingenuous. :-)
I play as nice as I can, but I also like playing shishkebob when I find
something that deserves it. I don't like to let statements I strongly
disagree with go by.
As to your other posts, I am very interested by your comments on
features of IF languages, and will reply in that thread separately.
Squirm and twist all you like -- you're just not ill-informed enough
about programming languages to flame. Sorry.
Andrew Plotkin
David Baggett (d...@lf.ai.mit.edu) wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >This becomes a sore point, because there *is* a difference between Graham
> >and his spare time (on one finger), and MetroWerks (on the rest of the
> >platoon's appendages).
> Is it also a sore point that we're writing IF games in our spare time, so
> that when someone compares our works to "real" literature, it's not fair?
> I say that's garbage.
Writing *is* different. Everyone who writes does it in their spare time
(except a small minority, just about all of whom have been doing it for a
while) and there are no programming textbooks to study. No backlog of
technical info which applies to the field. There's just books (of which I
read as many as anyone, give or take) and stuff like writers' workshops
and composition classes, which are known to be optional.
Writing is also a singleton sport, which was my point about Metrowerks. For
most kinds of programs, you *can* do twice as much by hiring twice as
many programmers. (Up to obvious limits.) My Matrowerks C compiler has
buttloads of nice features -- source-level debugger, syntax-based
coloring in the editor, pop-up lists of functions, lots of libraries,
kept up to date with Mac system software, etc, etc. One person couldn't
do that, not at that rate. Kernighan and Ritchie didn't do it.
Whereas a book is written by one person staring at enough blank paper for
enough time.
> And if it's a sore point, why claims like this:
> "But Inform, though it is certainly an amateur piece of work,
> is a quite high-performance compiler by comparison with many,
> perhaps even most, professional works."
Well, I didn't say that. Now that you've brought up all these issues like
optimization, I'm wavering on it (mostly because I don't feel like
re-reading the Inform tech manual chapters on optimization, so I am, to
coin a phrase, ill-informed.)
> I didn't say that lack of optimization was a major problem. I said it was
> an indication of a non-"professional" compiler.
Well, but I agree with you on that. :-) I'm saying I don't expect as much
from Graham as I do from my commercial compiler/IDE.
> If you want an example of
> a major problem, how about this: why are we writing text-based interactive
> fiction in variants of a low-level systems programming language? This is
> *not* a systems programming task; in fact it's at nearly the exact opposite
> side of the spectrum. (This doesn't just apply to Inform, of course.)
Oop, different thread. The choice of design language features will be
dealt with next post. I *don't* think it's fair to criticize Graham (or
Mike Roberts) for their choice of tasks to tackle. Especially since, at
least for *me*, their tackles have been very successful, and enabled me
to do exactly the tasks I want to do. I'm a classic (ok, really ANSI) C
recidivist.
Andrew Plotkin
David Baggett (d...@lf.ai.mit.edu) wrote:
> In article <32ba50f5...@news.worldonline.nl>,
> Marnix Klooster <mar...@worldonline.nl> wrote:
> >What features should an IF implementation language have, in your
> >opinion?
> [I sent this note to Marnix, but decided to post it as well, in slightly
> edited form.]
> It's not so much features; if anything, it's that these languages have too
> many features that ought to be in libraries, not hard-wired into the
> language. As a consequence, the features are not very extensible, and you
> have to spend lots of time learning special, bizarre syntax to be able to
> use them or read other people's code.
I dance around, sprinkling saffron and holy oil upon your brow, as you
utter these holy words.
> My feeling is that a language should provide only the primitives you need,
> and that everything else should be defined in terms of those primitives.
> The designer should ensure that these primitves can be combined in such a
> way that a compiler can perform useful optimizations, and the compiler
> writer should ensure that the compiler takes advantage of the good design.
> Neither of these things is by any means easy, which is why so many people
> who "roll their own" languages screw them up.
> As I've said before,
...around the time I was trying to decide to do for the competition, for
example...
> I think Scheme is a really good base language to build
> an IF system around. It has very few primitives, but the primitives are
> extremely powerful in combination. There are well-known optimizations that
> work well on Scheme code. And you can do things in Scheme that you can't
> do easily in most other languages. Here are two examples:
> 1) 1st class functions.
> 2) Continuations.
[explanations snipped]
I certainly like features like these in languages. (SML, which I whine
for occasionally without doing anything about it, is pretty much made of
the idea of first-class functions, together with the Sexiest Type System
in the Universe. On the other hand, I still can't think in continuations.
Maybe someday I'll figure them out.)
However, on the *third* hand, Inform (being C-like) supports function
pointers (in its own icky typeless way), so you can do many of the tricks
you want to use first-class functions for. You could easily write an
iterator function like you describe, which takes (among other arguments)
a function pointer. The compiler doesn't keep you type-safe, but we C
recidivists know how to be careful, so we *do* get features like this
when we want them.
And the Z-machine has an exception mechanism which, unless I'm very much
mistaken, is essentially limited (one-use) continuations. (I've seen
sketchy Scheme implementations which had limited continuations like
this. They suffice for the loop-bailing example you gave.)
(None of this helps programming newbies, however.)
> These are the kinds of features that are *good* to put in a language.
> They're powerful, very general-purpose, and (though it's not obvious at
> first) combine very efficiently, and without obscuring optimzation
> opportunities.
> If these examples seem esoteric, well, remember this: programming languages
> train you not to want power they don't provide. Once you're used to
> working with things like 1st class functions and continuations, you can't
> stand writing code without them.
Now I will give the argument for the defense: C is, uh, not that bad.
I've used a bunch of languages, including Scheme, SML, C, C++, and Java.
(Java is an awful compromise of a language, BTW. I *really* miss
first-class functions when I use it. I understand they're being hacked
into the next version, which is good, I guess, except that it means that
Java is firmly on the path to becoming an awful bloated monstrosity of a
language -- like C++ is.)
Sorry -- tangent. The point is, I always wind up back at C. It's dumb
enough that I can get it to do what I want. If I need it to iterate on an
arbitrary function, I hack that together -- it's neither the hard part of
my programming day nor a major source of bugs. If I need a small amount
of OO behavior, I hack *that* together. If I need a large amount of OO
behavior, I switch to C++ and keep very tight limits on what C++ features
I use, and where, so that the program is essentially C in the easy
sections.
So C is great for hotshot geeks like me. Contrariwise, however, C isn't so
bad for beginners either. (I hear you sharpening your machetes out there
-- hold on -- I'm going to qualify that.) The original "language for
beginners" was BASIC. Idiots can demonstratably learn BASIC. Imperative
programming where numbers are the only first-class objects is really easy
for people. The problem is, BASIC causes inoperable brain tumors, because
it doesn't give you the tools to figure out recursion and modular design.
C is BASIC plus recursion and a certain amount of modularity. And the
roof is lopped off, so that you can write anything and everything in it,
if you're willing to become a hotshot geek about halfway through. This is
why it's so popular. Idiots can get started in it, and once they develop
a clue (which I have, I hope you don't mind me claiming) they (we) don't
have to leave.
(You may just say that I've developed a more advanced form of inoperable
brain cancer. This may be.)
(The hard part about getting started in C is traditionally strings, and
pointers, and other aspects of dynamic memory management. Note that these
are exactly the bits that were left out of TADS and Inform (except as
very advanced features, and then they're provided in a fairly idiot-proof
way, not like C at all.) So this is not an argument about C-like IF
languages.)
People *can* get started in TADS and Inform. I really believe that Scheme
(and SML) would be much harder for beginners, because of their purely
functional style. People had *trouble* with "Lists and Lists".
After typing all this, my feeling is that the real solution is an
imperative-looking language which contains Scheme-like features. So that
people can jump to it from BASIC, but not get stuck inventing their own
high-level features like I do. You say Dylan is this, and I've heard
something about a language called Haskell, too; I've never looked at
either of them.
If Inform 7 went this way, I wouldn't mind a bit. It might, however, be
too much for one person. (Kernighan and Ritchie didn't write Dylan. I
don't know how many people that took.) (On the other hand, I've heard
Scheme is pretty damn easy to implement. :-) Which makes a certain amount
of hash out of my point.)
It's late. I was going to talk about Phil Goetz's Prolog work, but I have
to go. (The summary is "Don't talk to be about Phil, man. I think he's in
the process of inventing a genre as different from Infocom-style IF as IF
was from Space Invaders.")
John West McKenna
erky...@netcom.com (Andrew Plotkin) writes:
>Whereas a book is written by one person staring at enough blank paper for
>enough time.
You mean writing is really that easy? Just stare at some paper for a
while? I think I chose the wrong job.
John :-) West
Admiral Jota
Easy? Appearantly you don't know how long 'enough time' can become, if
you're not an expert at staring at blank paper :)
--
/<-= -=-=- -= Admiral Jota =- -=-=- =->\
__/><-=- http://www.tiac.net/users/jota/ =-><\__
\><-= jo...@mv.mv.com -- Finger for PGP =-></
\<-=- -= -=- -= -==- =- -=- =- -=->/
Andrew Plotkin
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> In article <59fo51$l...@life.ai.mit.edu>, David Baggett
> <URL:mailto:d...@lf.ai.mit.edu> wrote:
> >
> > In article <59evu4$4...@sjx-ixn4.ix.netcom.com>,
> > William Bryant <wbr...@ix.netcom.com> wrote:
> >
> > >The "Dragon Book" wouldn't be "programming compilers in C" or some
> > >such title, latest edition about 1992?
> >
> > Here's a Library of Congress listing for it:
> >
> > Aho, Alfred V. Compilers, principles, techniques, and tools /
> > Reading, Mass. : Addison-Wesley Pub. Co., c1986. x, 796 p. : ill. ;
> > 24 cm. LC CALL NUMBER: QA76.76.C65 A37 1986
> Aho, Sethi and Ullmann, to give all three authors.
> The above is the second edition.
Sheerly for the sake of history, I'll note that I also have the old
_Introduction to Automata Theory, Languages, and Computation_ by Hopcroft
and Ullman (1979). The one with a picture of a girl labelled "Mathematical
Truth" struggling with a bizarre contraption labelled "NP-Complete
Problems". (And the back cover is the same girl in the contraption's
collapsed ruins.)
Please don't ask me what I'm doing with a textbook which was published a
year *before* I started hacking -- on that brand-new Apple II+ -- in BASIC.
David Baggett
>However, on the *third* hand, Inform (being C-like) supports function
>pointers (in its own icky typeless way), so you can do many of the tricks
>you want to use first-class functions for.
I liked your post a lot. But I do think that it's risky to believe that
function pointers (C, Inform) or property "pointers" (TADS) really do the
same thing as true first-class functions.
OK, I'll admit it. I've written several orders of magnitude more code in C
than in any other language. Next comes Atari 800 BASIC, probably, and
then various assembly languages. In a lot of ways, I'm a low-level guy at
heart.
But IF is so... high-level. Or at least, it should be. I don't *need* to
write in assembly to write a good IF game. I don't even need to write in
C, which IMHO is a fancy macro assembler with infix notation. In fact,
because IF is so "high-level", I *shouldn't* try to write it in any of
those languages, because I'm certain to have more bugs in my final product
if I do.
I want IF code to be reusable. Heck, I want all code to be reusable, but
it's an impossible goal with mainstream code. It's not with IF, though.
It's a limited domain, it doesn't require anything to be coded down to the
bare metal of the machine like 3D games do, and it's such a "clean"
problem. It's a problem that deserves a simple, elegant language, like
(yes, Phil) Prolog, ML, or Scheme.
Function pointers in C don't really give you the kind of reusability win
that good old Lambda The Ultimate does. I try to force C to do it for me.
I write iterators that walk trees and graphs and call a provided function
on each node. But it's not the same. I have to name every function I do
this with, and I have to precisely define its arity and types, which cannot
vary. When all I really want is something that "does X" on every node,
where I get to make X anything I want at the point of the call.
Compare C's qsort library function with a Scheme sort primitive, for
example. For qsort, you have to define a separate function (say,
"compare_thing") which only works on one specific type of object. Then you
have to pass a pointer to the function into the qsort routine. And if your
function pointer is hosed, you crash with no useful error message.
Here's a similar call, but in Scheme:
(sort '(1 4 5 3 2 5) <) -> (1 2 3 4 5 5)
I pass in a list of stuff (type-checked to be sure it's a list at
run-time), and a sorting function. How about this:
(sort '(1 4 5 3 2 5) (lambda (x y)
(if (and (odd? x) (even? y))
#t
(if (and (even? x) (odd? y))
#f
(< x y)))))
-> (1 3 5 5 2 4)
To go from a function that sorts numbers to a function that sorts and
separates odds from evens (or anything complicated, for that matter), I
just have to declare a little function inline to apply to each pair.
And it works on different types of arguments, too:
(sort '("the" "cat" "and" "the" "hat") string<?)
-> ("and" "cat" "hat" "the" "the")
(sort '(the cat and the hat) (lambda (x y)
(string<? (symbol->string x)
(symbol->string y))))
-> (and cat hat the the)
(sort '((5 3 4) (4 2 3) (4 5 6) (3 1 2)) (lambda (x y)
(< (apply min x)
(apply min y))))
-> ((3 1 2) (4 2 3) (5 3 4) (4 5 6))
(The last example sorts a list of lists according to each list's minimum
element.)
Write the last example in C code using qsort (itself a rare example of a
reusable C routine) and see how many lines of code you end up writing. No,
it's not like moving mountains, but it's not a one-liner either.
The advantage of the Scheme approach is that, since you're combining fewer
primitives, there's less chance you've screwed something up. You can
better leverage your utility functions so you don't have to write new ones
from scratch.
(Another example I didn't give is using the Scheme sort to sort objects
of different types; for example, a list of *both* strings and symbols.
You can't do this in C without subverting the static type system and
implementing your own dynamic type system by hand.)
>If I need it to iterate on an arbitrary function, I hack that together --
>it's neither the hard part of my programming day nor a major source of
>bugs.
The programmer's mantra: "I [can] do that without introducing bugs." :)
I don't doubt that you personally generate comparatively few bugs in your
code. But, as you point out, you are a serious C hack. C has trained you,
as it has trained me, to do these things in a specific way, and with great
caution, to get them to work.
You can always tell how programmed a person has become by C by removing a *
from a */ in their source code and seeing how long it takes them to find
the syntax error. You, Andrew, would probably come in under 30 seconds,
because that exact token error would be the first thing you looked for when
you got the usual flood of "100 errors --- limit exceeded". But how long
would it take a C newbie? Probably hours. (I've seen it.)
>People *can* get started in TADS and Inform.
Yes, and of course the best evidence is the raft of games that have just
been released...
But these languages also generate an inordinate amount of traffic from
beginners struggling with problems that should (often) have been fixed in
the language design (the classic case being TADS' do/io/VerDo/VerIo
complexity).
>I really believe that Scheme (and SML) would be much harder for beginners,
>because of their purely functional style. People had *trouble* with "Lists
>and Lists".
You may very well be right. If it's true, it's really a shame. The only
*really* daunting thing about Scheme and ML is the very un-C-like syntax.
You don't actually *have* to write Scheme functionally either. It's just
the preferred method. (Preferred by language theorists, at least.)
>After typing all this, my feeling is that the real solution is an
>imperative-looking language which contains Scheme-like features.
I think perhaps the best solution is a Scheme + objects with an optional
Newbie front-end that has more "conventional" syntax. (I put that in
quotes because Lisp has been around since 1956...) If you choose to use
the Newbie syntax, you don't quite get the full power of the language (no
macros, for example). But you can still use the same libraries and code
snippets that other people write.
But maybe that's the language design equivalent of Zaphod Beeblebrox, and
not such a good idea after all...
David Baggett
>I *don't* think it's fair to criticize Graham (or Mike Roberts) for their
>choice of tasks to tackle.
I think it's fair, but (obviously) not a politcally wise move. :) And I
guess I should reiterate that I'm not saying we should throw TADS or Inform
in the wastebasket, or even that they are not impressive pieces of work.
They both are great achievements. Few things are as difficult as writing
and maintaing a compiler that many people rely on.
If anything, I'm trying to raise the bar rather than beat on Graham and
Mike. I question anyone's claims that these tools are as sophisticated and
robust (in many senses) as, say Allegro Common Lisp, or GCC, which are
"professioal-quality" compilers written and maintained by a small number of
people, either for free or for not a lot of money.
Language design and implementation are *difficult*. I would just hate to
think that, once they've used Inform or TADS, people will:
- believe these languages are superbly designed and implemented
compared to other working systems that are out there (not for IF,
necessarily, but general-purpose languages with free and portable
virtual machine implementations)
- take offense to criticisms of the design or implmentation choices
made by these languages' designers and go into flame mode
- refuse to consider promising alternatives (like Phil's work on
Prolog)
Can I also remind everyone that the language originally used to write
Z-Machine interactive fiction was closer to Scheme than Prolog, ML, or C,
and that more high-quality games have been written in Zil (a MDL variant)
than in any other language?
If you're curious, you can get a glimpse of MDL code and some of the things
it added to the Lisp world in Steele and Gabriel's "The Evolution of Lisp"
(an ACM History of Programming Lnagugaes publication available on the web
somewhere).
Graham Nelson
In article <59eu68$6...@news.multiverse.com>, Matthew Russotto
<URL:mailto:russ...@ariel.ct.picker.com> wrote:
> Ignorant criticism, however, is useless. There's been plenty of criticism
> of TADS (including a certain nameless library), Inform (including the
> hanging-else bug), AGT (nevermind), etc.
Just to recap: there is no hanging-else bug in Inform.
It is a late bug. It has ceased to be. Bereft of life,
it rests in peace. It has shuffled off this mortal coil
and joined the choir invisible.
This is an ex-bug.
Graham Nelson
In article <59h6sq$6...@life.ai.mit.edu>, David Baggett
<URL:mailto:d...@rice-chex.ai.mit.edu> wrote:
>
> In article <59g6p8$g...@bartlet.df.lth.se>,
> Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>
> >But I think that the design of the *language* is far more important than
> >the design of the compiler.
> >...
> >It must have taken considerable courage on Graham's part to "fix" the
> >dangling else's in Inform, knowing that a lot of existing code would
> >probably break.
I know of no existing code that actually did break, by the way,
though I'm willing to be corrected.
> Language design is critically important, but it cannot be done in the
> absence of an understanding of how compilers are properly implemented.
Yes and no. In some respects the Inform language benefits from
not making compromises to suit compiler convenience (for example,
it would be easier to parse if it required far more commas and
braces, making it LALR(1), but it would be more tiresome to type
as source code). But broadly I agree.
> Having to fix something as basic as improper dangling else in the 6th major
> revision of a programming language shows totally ad-hoc design *and* a
> refusal to use appropriate tools for the job of parsing in the compiler.
> Everyone whose Inform 5 code is now invalid has to pay for the poor design
> and implementation of Inform 5. I cannot see how you can put a positive
> spin on this and keep a straight face.
No, Inform 6 was not really the 6th major revision. Inform 5
was the only version which anyone other than myself actually
produced any game which was ever posted to the Net. Inform 1 to
4 were not major releases so much as a series of updates rapidly
appearing in the first year of Inform's existence.
Nevertheless, yes, I agree that Inform 5 was poorly implemented
(though not that it was poorly designed). I bear full
responsibility for that and would expect to be criticised if
I were advancing Inform 5 as a professional-quality tool.
But I am not.
It is a simple procedure to update source code from Inform 5 to
Inform 6: far less effort than updating from K&R C to ANSI C,
for instance.
> And it's not just Inform. TADS had a similar upheaveal from v1 to v2, and
> it, too, uses a hand-coded parser with plenty of bugs over the years.
I wonder if you appreciate how poorly the parsers produced by
tools such as "lex" and "yacc" perform? They generally work
(provided the language design makes compromises so as to be
expressible to "lex" and "yacc" -- which would worsen Inform
in my view) but impose speed penalties of up to a factor of 2.
Have you read the Dragon Book, I wonder? It does make this
very point.
Matthew T. Russotto
In article <ant202329868M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
}In article <59cimp$2...@life.ai.mit.edu>, David Baggett
}<URL:mailto:d...@lf.ai.mit.edu> wrote:
}> One very basic requirement for a "professional quality compiler" is that it
}> perform nontrivial optimizations like strength reduction; do any of these
}> compilers do that?
}
}Guilty; I don't know what "strength reduction" is.
The quickest reference I have to hand defines it as reducing the
computational cost of an operation while providing mathematically
identical results.
One problem with trying to do this with a compiler for a virtual
machine is that the performance characteristics of the VM aren't
known, and probably vary from implementation to implementation. On my
PowerMac, for instance, I'll make an educated guess that the time for
any non-I/O operation is roughly proportional to the number of calls
to read_code_byte generated, no matter what the mathematics involved.
On something like a Z-machine on top of a 6502, this won't be the case
as things like 16-bit multiplication take a long time.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Bif
Okay, I'm the guy who started this thread. I apologize to Graham and
Andrew and everyone else for swearing and making bad criticism. Both my
complaints were just plain wrong and if I'd thought before using a
certain word, I would have realized that it has connotations of sodomy.
I suppose the reason (not an excuse) for sending that email is that I
was frustrated and a little angry when learning the Inform language. The
learning of most technical tools is frustrating. If it's any
consolation, Graham, I still think the language is neat enough to
continue using it.
--Bif
David Baggett
In article <59eu68$6...@news.multiverse.com>,
Matthew Russotto <russ...@ariel.ct.picker.com> wrote:
>}And I don't see why it's OK to harshly criticize IF works that people write
>}for free, but it's not OK to criticize the tools.
>
>I'll remember that next time someone gets defensive about a certain
>library...
I can't recall ever denying the problems with my own stuff. In fact, I'm
usually the first one to point them out, and to encourage others to so --
read the introductory note to the very first release of WorldClass for
example.
Here's a deal: when I start shooting off my mouth about how WorldClass is a
professional quality this or that, then you can flame the crap out of me,
OK?.
>Nor is implying that the authors of these tools haven't read anything
>about how these tools are written, when a small amount of research would
>indicate otherwise.
Right, right. I must have this opinion because I haven't read as much as
you about Inform. I've read the book on TeX, too, and I know that Don
Knuth's a really smart guy. That doesn't change my opinion on the TeX
language or its implementation...
David Baggett
In article <ant221443d07M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>I wonder if you appreciate how poorly the parsers produced by
>tools such as "lex" and "yacc" perform? They generally work
>(provided the language design makes compromises so as to be
>expressible to "lex" and "yacc" -- which would worsen Inform
>in my view) but impose speed penalties of up to a factor of 2.
The idea that it's reasonable to use a tremendously error-prone method to
solve a problem for which trivial tools exists, simply to save time on
lexical analysis -- a small proportion of the entire compilation task -- is
totally misguided, in my opinion.
Suppose that the best machine-generated lexical analyzer *were* twice as
slow as your hand-coded one. How much longer should it take to compile
code? Fractionally longer, unless your compiler's doing basically no work
to generate and optimize code.
Look, it takes TADS *less than one second* to compile Legend on my PC at
home. Even if all it were doing were lexical analysis, and the lexical
analysis took 10 times as long, I'd still be looking at very reasonable
compile times on huge programs (as programs in this area go).
There is no reason to give up reliable, bug-free, extensible parsing in a
tool like this. Yet you're compromising the robustness of the tool, and
your ability to modify it easily, in the name of efficiency?
(And making a grammar that's not even parsable by a standard
machine-generated parser is *really* evil. What happens when someone wants
to write a program that manipluates Inform 6 source code? They have to
adapt your hand-coded parser, bugs and all. If you can't fit your ideal
language syntax into regular grammars for the tokens and context-free
grammars for the expressions and statements, you're really hurting.)
And in any case, machine-generated lexical analyzers *are* very competitive
with hand-coded alternatives. Get a copy of RE2C or Wuu Yang's paper on
the lookahead problem. (AltaVista will find both.) It basically comes
down to figuring on how many characters of lookahead you need to tokenize
in the worst case, and managing the lookahead buffer wisely in the
generated code.
I suspect your answer to all this comes down to "I must compromise the
design and implementation of Inform so that I can play and compile games on
older hardware". I think it's madness to penalize the majority of your
language's audience (who have circa 1985+ hardware) for the needs a very
few who get a thrill out of running programs on their first computers. (I
still use my Atari 800, too; I just don't support it with compilers I write
here in 1996.)
To put it another way: speed of compilation and small compiler memory
footprint are noble goals, but only *after* you've gotten everything else
right
(And once again, many of the same criticisms can be made of TADS, too, so
I'm not just being partisan here.)
David Monniaux
You suggest Standard ML for writing IF. Maybe you should also check
Objective CAML, which is a dialect of ML with lots of interesting
features, such as yacc- and lex- like tools, native code compilers,
functors and modules.
See http://pauillac.inria.fr/ocaml/htmlman/.
"Si l'informatique marchait, cela se saurait."
David Baggett
In article <Pine.GSO.3.95.961223030440.25297F-100000@gerland>,
David Monniaux <dmon...@ens-lyon.fr> wrote:
>You suggest Standard ML for writing IF. Maybe you should also check
>Objective CAML, which is a dialect of ML with lots of interesting
>features, such as yacc- and lex- like tools, native code compilers,
>functors and modules.
Thanks for posting the pointer. The main reason I personally prefer Scheme
to ML for an IF system is macros. Macros let you make mini-languages. To
choose an IF example, you could implement Manhattan map layout (as someone
recently discussed implementing in Inform) with a simple macro:
(defmap general-store tree-lined-grove library
park town-square museum
river mayors-house)
could generate code to connect these locations as indicated (up being
north). The advantage of this is that the map connectivity is evaluated at
compile time rather than run-time.
What I'd really like to see is a Scheme with H/M type inference built into
the language (rather than grafted on after the fact). (Or perhaps that
would be an ML with lots of parentheses and ML as the macro prepocessor.)
I know of some attempts to apply static type inference to Scheme, but I
know of no one re-doing ML with lisp syntax. Has anyone done that?
The pattern-matching programming constructs ML provides are another very
powerful utility you don't get from C and friends. Andrew Wright and Bruce
Duba at Rice have brought this idiom over to Scheme, but it's a lot cleaner
in ML, IMHO.
Matthew Amster-Burton
Bif <bifu...@geocities.com> wrote:
>Both my
>complaints were just plain wrong and if I'd thought before using a
>certain word, I would have realized that it has connotations of sodomy.
Sorry to jump in now after completely missing the festivities over the
weekend (why do you do this to me every week), but ain't this one of
the strangest apologies you've ever seen?
Not that I doubt its sincerity, of course....
Matthew
Marnix Klooster
d...@lf.ai.mit.edu (David Baggett) wrote:
> And in any case, machine-generated lexical analyzers *are* very competitive
> with hand-coded alternatives. Get a copy of RE2C or Wuu Yang's paper on
> the lookahead problem. (AltaVista will find both.) It basically comes
> down to figuring on how many characters of lookahead you need to tokenize
> in the worst case, and managing the lookahead buffer wisely in the
> generated code.
If in need to generate efficient (better than yacc), general
(accepts almost any grammar), and simple (uses BNF notation)
parsers in C, use PRECC (or PRECCX). Free, written by Peter
Breuer (sp?), current version 2.44, runs with any ANSI C
compiler. (Sorry, I've got no URL.)
> Dave Baggett
Groetjes,
<><
Marnix
--
Marnix Klooster | If you reply to this post,
mar...@worldonline.nl | please send me an e-mail copy.
Marnix Klooster
d...@lf.ai.mit.edu (David Baggett) wrote:
> In article <Pine.GSO.3.95.961223030440.25297F-100000@gerland>,
> David Monniaux <dmon...@ens-lyon.fr> wrote:
>
> >You suggest Standard ML for writing IF. Maybe you should also check
> >Objective CAML, which is a dialect of ML with lots of interesting
> >features, such as yacc- and lex- like tools, native code compilers,
> >functors and modules.
>
> Thanks for posting the pointer. The main reason I personally prefer Scheme
> to ML for an IF system is macros. Macros let you make mini-languages. To
> choose an IF example, you could implement Manhattan map layout (as someone
> recently discussed implementing in Inform) with a simple macro:
>
> (defmap general-store tree-lined-grove library
> park town-square museum
> river mayors-house)
>
> could generate code to connect these locations as indicated (up being
> north). The advantage of this is that the map connectivity is evaluated at
> compile time rather than run-time.
Isn't this essentially an implementation issue? I mean, almost
always programming in a functional language comes down to
designing a mini-languague, in my (Haskell) experience. (Also,
when I did my first real Scheme programming using Andrew's superb
genieus optimizing IDE, I found that I could transplant these
techniques almost word-for-word.) Whether certain constructs in
this mini-language can be `executed at compile-time' depends on
the quality of the implementation.
In other words, what is the advantage of macros over ordinary
functions, except for more efficient execution? I suspect
languages such as Haskell, Gofer, Miranda, etc. do not have
macros because they have simpler semantics -- no side effects,
lazy evaluation, etc.
> What I'd really like to see is a Scheme with H/M type inference built into
> the language (rather than grafted on after the fact). (Or perhaps that
> would be an ML with lots of parentheses and ML as the macro prepocessor.)
Again, what advantages would the addition of macros to ML bring
you?
> I know of some attempts to apply static type inference to Scheme, but I
> know of no one re-doing ML with lisp syntax. Has anyone done that?
Not that I'm aware of; what would be gained?
> The pattern-matching programming constructs ML provides are another very
> powerful utility you don't get from C and friends. Andrew Wright and Bruce
> Duba at Rice have brought this idiom over to Scheme, but it's a lot cleaner
> in ML, IMHO.
Very true. If I ever design an IF language (or rather, a
general-purpose language well-suited to IF) this will most
definitely be in it.
Rhodri James
mar...@worldonline.nl (Marnix Klooster) wrote:
> In other words, what is the advantage of macros over ordinary functions,
> except for more efficient execution?
The advantage of macros is that they can hide messy language issues under
a kinder API. This is also their disadvantage!
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... I have too much time on my hands. Let's run another convention.
Rhodri James
d...@lf.ai.mit.edu (David Baggett) wrote:
> I suspect your answer to all this comes down to "I must compromise the
> design and implementation of Inform so that I can play and compile games
> on older hardware". I think it's madness to penalize the majority of
> your language's audience (who have circa 1985+ hardware) for the needs a
> very few who get a thrill out of running programs on their first
> computers. (I still use my Atari 800, too; I just don't support it with
> compilers I write here in 1996.)
I was going to leave this thread alone. I was. Honestly. No matter how
much I disagree with Dave about the quality of yacc and lex (implicitly),
lowest common denominators (explicitly) and so on and so forth. But then I
read the above paragraph and my head exploded. That was messy, and didn't
go with the pale green walls of the study.
Circa 1985+. Glibble. Dave, you must surely have a reasonable idea that
anyone comparing 1985 machines with 1996 machines isn't even using an
astronomer's approximation, the specifications are so far apart. I did
work out a few years ago that memory sizes in machines were roughly
doubling every two years, though I've heard others estimate that at 18
months. Supporting stuff on "older hardware" can easily mean supporting
*last* *year's* platform!
One of the truly dumb things that developers often do is to always use the
latest kit. It may be a breeze to do your work on, but a great majority of
the customers have positively ancient machines (say, two years old), and
that really neat trick that you stuffed in for some bell or whistle may
take enough cycles that for the customers your pride and joy moves like a
slug on valium. This has happened repeatedly in the commercial world.
Sales droids love it, because it means that they can tempt customers into
upgrading because they now "need" it. That way lies madness (and Windows
95, which is surely indication enough!).
--
Rhodri James *-* Wildebeeste herder to the masses
If you don't know who I work for, you can't misattribute my words to them
... but that's a herring of a different colour
David Baggett
In article <n40C...@wildebst.demon.co.uk>,
Rhodri James <rho...@wildebst.demon.co.uk> wrote:
>...I disagree with Dave about the quality of yacc and lex (implicitly),
>lowest common denominators (explicitly) and so on and so forth.
I know it's not your main point, but for the record: unless AP's inoperable
brain tumors are catching, I didn't specifically mention yacc and lex;
Graham did. Even I find it somewhat difficult to defend these specific
tools against hand-coded equivalents, because yacc and lex are so
wretched. :)
There are many other tools that do the same job for the same language (C),
but much better. It seems like over two dozen are available on the net,
and the aforesaid PRECC was developed at Oxford, (I'm totally guessing) a
stone's throw from Graham's office.
The idea that machine-generated lexical analyzers are, practically
speaking, slower than their hand-coded equivalents is outdated. Here are a
few quotes from Bumbulis and Cowan's 1994 RE2C paper, which I mentioned
earlier in this thread:
"Lexical analysis routines are still often coded by hand despite the
widespread availability of scanner generators. [...] One commonly cited
reason for not using Lex-geneated scanners is performance: they can be 10
times slower than equivalent hand-coded scanners. As a result, there has
been considerable research into improving the performance of mechanically
generated scanners. GLA, one such scanner generator, can produce scanners
that are faster than most hand-coded scanners."
"Table 1 compares two RE2C-generated C scanners wit the (hand-coded)
lcc scanner and comparable GLA- and flex-generated scanners on a variety
of platforms. It reports the times in seconds required by the various
scanners to scan about 170,000 lines of C source. The 5,607,820 byte
source file used essentially consists of 10 copies of the source to
James Clark's SGML parser, sgmls. The times reported are averages
for 10 trials; the sizes reported include everything but the C library
code. [...] As a general rule, the RE2C-generated scanners were the
fastest, followed by the FLA-generated scanner and then the lcc scanner.
The flex-generated scanners were significantly slower. Only the space-
optimized flex scanner was smaller than the default RE2C scanner, and
only by a narrow margin."
Table 1:
TIME SPACE
program user sys total text data bss total
flex -Cem 10.36 0.87 11.23 5200 4192 48 9440
flex -Cf 5.44 0.72 6.16 4688 64384 48 69120
lcc 3.19 0.67 3.86 7328 1216 8256 16800
gla 2.89 0.63 3.52 11552 3056 144 14752
re2c 2.54 0.68 3.22 13264 512 0 13776
re2c -s 2.38 0.67 3.05 11056 4528 0 15584
(Times listed are for an R4000. See the paper for other archiectures.)
Looks pretty convincing to me.
>Circa 1985+. Glibble. Dave, you must surely have a reasonable idea that
>anyone comparing 1985 machines with 1996 machines isn't even using an
>astronomer's approximation, the specifications are so far apart. I did
>work out a few years ago that memory sizes in machines were roughly
>doubling every two years, though I've heard others estimate that at 18
>months. Supporting stuff on "older hardware" can easily mean supporting
>*last* *year's* platform!
I'm not entirely clear on what you're arguing for or against here, but to
clarify my own position: If it takes just over two seconds to tokenize
170,000 lines of code on an R4000 (unspecified clock rate, but I don't
think MIPS made them faster than 200Mhz, so lets assume that), then how
long would it take to tokenize the same amount of code on a 33Mhz
i486-based machine? I'd guess that since (unless I am mistaken) the R4000
is clock-multiplied, the multiple would certainly be less than a factor of
7, the difference in quoted clock speeds. That means an RE2C-generated
scanner might be able to tokenize the source in around 15 seconds. This is
still very zippy; that's a huge amount of code. Doing any kind of
nontrivial code generation work would take considerably longer than that.
With an i486 we are not talking about last year's hardware. We're talking
about two-generations-old hardware; 3+ year old hardware. I think it is
reasonable to draw the line at compromising the language design or
implementation in the the name of hardware older than that. Obviously it's
subjective.
Incidentally, I picked 1985 because I've written lots and lots of code for
a fairly typical circa 1985 personal computer architecture, an 8Mhz 68000.
I remember what it was like trying to get compilcated programs like
compilers to run fast enough on such a machine, and in some cases one did
indeed have to resort to nasty hand-coding (or bail-outs to straight
assembly) where higher-level techniques would suffice for faster machines.
The Inform compiler looks a lot like a compiler written for that kind of
machine to me. And I don't think it makes sense to make that kind of
compromise; to make the language and its implementation ad hoc and
immutable for the sake of supporting my poor old Atari ST, which deserves
to rest in peace.
(On the other hand, I mentioned the Atari 800 flippantly. It's a salient
point, though, that one of Inform's inviolable implicit goals is to compile
binaries that will run on Atari 800's and Apple ]['s. This is a cool
thing, but once again I don't think it's worth making such great
compromises for. In other words, the Z-Machine as target architecture is
both the coolest and the worst choice Graham made for Inform. It makes the
language design much ickier than it might otherwise be.)
>One of the truly dumb things that developers often do is to always use the
>latest kit.
Well, just so you don't hate me, I swear I only gave up my 486 a few months
ago. I wrote much of WorldClass and Legend on a 486, waiting 30 seconds or
so for compiles. No big deal. I wrote UU2 on said Atari ST, enduring
glacial (and, thanks to a nasty TADS v1 lexer bug, sometimes infinite)
compile times.
>[...] and that really neat trick that you stuffed in for some bell or
>whistle may take enough cycles that for the customers your pride and joy
>moves like a slug on valium.
I'm certainly not ignorant of this, having "run" Windows 95 on my 486 box.
The flip side of the coin, however, is that faster machines provide
opportunities to make programs better. Going from an Atari 800 to an Atari
ST meant that I could start writing programs in C instead of assembly. You
could say I paid a huge price for that; back when I only had floppy drives
it took 15 minutes to compile a 15,000 line C program. But C let me write
more sophisticated programs in less time than I could have in assembly,
because for nontrivial tasks C was a better tool.
Likewise, the transition from an Atari ST to a Pentium makes even better
tools, like Scheme, ML, and Prolog feasible. It seems crazy to me to cling
to the C compiler, especially for a narrow, low-performance domain like
text-based IF.
I'll tell you something else, too. You shouldn't need to wait for compiles
any more. Your IF language should support interpreted and (VM-) compiled
execution, so you can test programs without a compile-link-test-crash-edit
cycle. You should be able to interrupt your running IF program, change a
variable -- heck, define a new function and test it out on a few boundary
cases -- and restart it given the new context. That will do vastly more to
reduce development times than making ever-faster compilers for C-like
languages.
Bob Newell
Rhodri James (rho...@wildebst.demon.co.uk) wrote:
: Circa 1985+. Glibble. Dave, you must surely have a reasonable idea that
: anyone comparing 1985 machines with 1996 machines isn't even using an
: One of the truly dumb things that developers often do is to always use the
: latest kit. It may be a breeze to do your work on, but a great majority of
: the customers have positively ancient machines (say, two years old), and
Point well taken; I often object to this sort of behavior (often driven
by greedy vendors such as Micro$oft). But there is a limit, too. For
instance, just this year I've given up supporting Inform on sub-386
machines (even though I own one and love it). There *are* reasonable
bottom limits, and now, when you can buy a used low-end 386 for pocket
change, there seems little point in compiler compatibility back to the 8088.
(Although run-time compatibility is much different... it seems nice to be
able to play games on a Psion even if you can't build 'em there...)
Bob
Matt Ackeret
In article <59obcq$t...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
>(On the other hand, I mentioned the Atari 800 flippantly. It's a salient
>point, though, that one of Inform's inviolable implicit goals is to compile
>binaries that will run on Atari 800's and Apple ]['s. This is a cool
>thing, but once again I don't think it's worth making such great
>compromises for. In other words, the Z-Machine as target architecture is
>both the coolest and the worst choice Graham made for Inform. It makes the
>language design much ickier than it might otherwise be.)
Oh wow, are you hypothesizing different backends for the same front-end
Inform compiler? That is, the same source language compiling into Zcode or
TADS code or some other virtual machine [such as Java.. dunno if that would
make any sense at all]?
As I told David in e-mail, it sounds to me like Inform isn't the language
for him. I mean, it seems to me that the whole reason for the existance of
Inform is to compile *into the existing Zmachine*. Graham may state that
I'm wrong. I don't even program in Inform, but with people talking about
the inability to create objects at runtime and other "arbitrary" limitations,
it seems to me that the reason people "put up with" this sort of stuff is
because they *want* their game as absolutely portable as possible. Otherwise
they would use some other more modern game development system.
--
mat...@apple.com
David Baggett
In article <32be93f5...@news.worldonline.nl>,
Marnix Klooster <mar...@worldonline.nl> wrote:
>In other words, what is the advantage of macros over ordinary
>functions, except for more efficient execution? I suspect
>languages such as Haskell, Gofer, Miranda, etc. do not have
>macros because they have simpler semantics -- no side effects,
>lazy evaluation, etc.
Although I have taken only a cursory look at Haskell and Miranda, and know
nothing at all about Gofer, I'll make the case for macros in lisp-like
languages, and then you can tell me if the case depends on something
besides the syntax.
I took a while to read through Paul Graham's book _On Lisp_ again so I
could find some good examples to show how macros are important, so I will
shamelessly borrow from that text in the following discussion. Definitely
buy this book, however, if you're even remotely interested in either lisp
or in the theory of programming in general. It will teach you more about
advanced programming techniques than any other book I know of.
Paul Graham points out that macros have two properties that ordinary
functions don't:
1) They can control the evaluation of their arguments.
2) They are expanded in the compilation context, not the run-time
context.
Consider implementing a basic while ... do loop in Common Lisp. Here's one
way to do it:
(defmacro while (test &body body)
'(do ()
((not ,test))
,@body))
This cannot be implemented in a function in lisp or Scheme, because a
function must evaluate all its arguments exactly once. (while) may
evaluate the body argument zero, one, or more times, depending on the
evaluation of the test expression at run-time. Likewise, the test will get
re-evaluated every time though the loop. Unlike a function argument, its
evaluation may change over time as the run-time context changes.
There are other ways in which capability #1 is critical. The Common Lisp
setf macro lets you assign values to expressions that are not normally
legal targets (or "lvalues" in C parlance). E.g.,
(setf (car my-list) 'a)
will put the symbol 'a in the first element of the list bound to my-list.
This kind of notation is quite useful but uncommon in general-purpose
programming languages. (Some dialects of BASIC allow substrings to be used
as lvalues like this, but I know of few other examples.) Because Common
Lisp has such a powerful macro facilty, it can provide this capability in
setf, and you (the programmer) can extend that capability as you add new
potential setf targets.
Note that setf here must examine the text, rather than value, of its
fitst argument in order to know how to do the assignment. Because of this,
you can't write setf as a lisp function.
A final example of #1 is (and). Suppose the language had no and function,
but you wanted to write expressions like this:
(if (and sky-blue death taxes)
(print "world normal")
(print "world awry!"))
You could define (and) in terms of if with a macro that would expand like
this:
(and a b) -> (if (not a)
#f
(if (not b)
#f
#t))
The key thing here is that you have maintained two common and important
properties of (and):
1) The arguments are evaluated in order from left to right.
2) The (and) will "short-circuit" and stop evaluating arguments
as soon as it evaluates an argument as false.
You get the first property by setting up your macro carefully. You get the
second property becuase the (if) special form guarantees it. (In Scheme
code; I assume most lisp dialects agree on this point.)
You can't write (and) as a function and maintain these critical properties.
Moving on to macro capability #2 cited above, macros can look to the
compilation environment to determine how to generate code. A simple
example is optimization. A macro to multiply two numbers, like
(times x y)
might examine its arguments and emit better code in cases like
(times x 2) expands to (left-shift x 2)
(times x 0) expands to 0
(times x 1) expands to x
(times x 5) expands to (+ x (left-shift x 2))
(times 11 7) expands to 77
and so forth. As you (Marnix) point out, the compiler ought to do this
kind of optimization for you, and you can help it out by giving it hints
(e.g., by labeling a given expression as guaranteed to be 16-bit
integral).
But what about when you're implementing your own language -- perhaps a
mini-language within your large lisp-based system, or maybe a simple
compiler to another target? Macros allow you to do this kind of simple
strength reduction and constant folding in code generation trivially. This
means that you can write a compiler for a language with lisp-like syntax
very easily; for example, you could implement a powerful VM-based IF system
within Common Lisp in a fraction of the time it would take to code the same
in C. (Of course there are disadvantages to doing this for an IF system
that you plan on letting hundreds of people use in their own homes. But
say you're a game company, and the only users you need to support are your
own in-house programmers? You can save yourself months of work with this
approach and win big.)
Another example of using the compilation environment is conditional
compilation. This is what the C macro facility is all about. But with
lisp macros you can do much fancier things, and without deviating from the
usual syntax of the language.
Consider a localization task. You're writing a word processor that must
support a particular OS in many different languages, with different writing
systems. Knowing that the Chinese text primitives don't exist on an Arabic
system, you need to compile out references to the Chinese calls so the
dynamic linker won't complain about missing libraries when a Saudi Arabian
user runs the program. (Alternatively, you may find it a bit rude to weigh
done the Arabian users with a meg of Chinese language object code, and vice
versa.)
You can do this very nastily with #ifdefs in C. In lisp you can make it
much nicer, because you can make arbitrarily sophisticated macros that
examine the compile-time localization values to generate the right code for
each primitive -- in this case, "display character string", "alphabetize",
"find word boundary", "re-fill paragraph", etc.
Once again, you can't do this without macros.
There are other, more esoteric uses of macros where functions won't
suffice. In _On Lisp_, Graham shows how to implement Scheme's
continuations in Common Lisp using macros.
>If I ever design an IF language (or rather, a general-purpose language
>well-suited to IF) this will most definitely be in it.
You raise a good point inside the parens. I used to believe that IF
demanded special language designs appropriate only to is limited domain.
But now I see the folly in that. Almost everything that TADS and Inform
provide in their designs that is specific to IF would be better off in
libraries. The only exceptions, in my opinion, are syntactic sugars like
TADS'
"You are here.";
printing statement shorthand. And, indeed, you can do most such sugaring
with macros.
It is a sign of weakness that (for example) TADS and Inform can't be
implemented in themselves, when so little is gained in return.
David Baggett
>Oh wow, are you hypothesizing different backends for the same front-end
>Inform compiler? That is, the same source language compiling into Zcode or
>TADS code or some other virtual machine [such as Java.. dunno if that would
>make any sense at all]?
It wouldn't make sense for Inform (and this is part of my point), because
Inform's design is intimately tied to weird Z-Machine restrictions.
A better choice would have been to chuck the Z-Machine and design a new
virtual machine. That's what Mike Roberts did, and it does show when you
compare the design of the two languages. Hindsight is 20/20, of course.
>As I told David in e-mail, it sounds to me like Inform isn't the language
>for him. I mean, it seems to me that the whole reason for the existance of
>Inform is to compile *into the existing Zmachine*.
Well, I guess you're right: I don't use Inform, and never will as long as
it looks anything remotely like Inform 5 or 6.
But the point of the whole tirade wasn't to show how bad a choice it would
be for me, but to dispute claims about the wonderfulness of Inform's design
and implementation (which are more frequent, and less often challenged now
that Inform is the undisputed king of the IF hill).
Inform fans (including, rarely, Graham himeslf) have not been claiming that
their favorite langauge is superb "given that it's crippled and at times
bizarre so as to support the Z-Machine and old hardware" -- there are never
any such qualifications. And I firmly believe that targeting the old and
creaky Z-Machine sent Inform down a language design rathole which we could
escape with a new VM and an old and creaky but very highly evolved language
(lisp).
But again, that doesn't mean Inform and TADS aren't worth using. They're
the best things out there (modulo Hugo and Alan, which I haven't written
any code in, and can't can't practically compare). And there's no doubt
that you can write high-quality games in TADS and Inform, because there are
examples to prove it.
Norman Ramsey
In article <59cimp$2...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
>[it should be Ok to criticize tools as well as games]
Agreed. Let's have at it :-)
>I've spent a great deal of time reading about [programming-language
>design and implementation] over the past few
>years, and it's quite clear to me that there are serious problems with
>*all* the existing IF development systems, and that none of them deserves
>anything like a "professional-quality compiler" label.
>
>One very basic requirement for a "professional quality compiler" is that it
>perform nontrivial optimizations like strength reduction; do any of these
>compilers do that?
I think you're assuming that the goals for an IF language or compiler
should be the same as the goals for a compiler for a general-purpose
programming language, e.g., the generated code should run fast.
What evidence have you got in favor of this position?
My pet peeve at the moment is that existing tools seem to offer little
in the way of static type checking. A language like Inform leaves a
lot of checking for run time. For example, according to the language,
every property is meaningful on every object. This rule offers
tremendous flexibility, but it also leads to heavy overloading of
properties like `general'. On the other hand, the obvious way of using
a fully static type system like that for C++, Java, or Modula-3 would
make Inform programming significantly more awkward than it is today.
Reconciling these competing goals would make a good master's project :-)
It's easy to write long lists of desiderata for these languages and
tools. What's on other people's lists?
N
--
Norman Ramsey
http://www.cs.virginia.edu/~nr
Norman Ramsey
In article <59k5a6$5...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
>In article <ant221443d07M+4%@gnelson.demon.co.uk>,
>Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>
>>I wonder if you appreciate how poorly the parsers produced by
>>tools such as "lex" and "yacc" perform? They generally work
>>(provided the language design makes compromises so as to be
>>expressible to "lex" and "yacc" -- which would worsen Inform
>>in my view) but impose speed penalties of up to a factor of 2.
>
>The idea that it's reasonable to use a tremendously error-prone method to
>solve a problem for which trivial tools exists, simply to save time on
>lexical analysis -- a small proportion of the entire compilation task -- is
>totally misguided, in my opinion.
>
>Suppose that the best machine-generated lexical analyzer *were* twice as
>slow as your hand-coded one. How much longer should it take to compile
>code? Fractionally longer, unless your compiler's doing basically no work
>to generate and optimize code.
Actually, measurements show that in many compilers, lexical analyis is
the single most time-consuming phase, primarily because it is the only
one in which each input character is touched. In a compiler like
Inform, in which global optimization is (probably) unnecessary, there
is little static semantic checking, and the machine target is
essentially quads, I find it unsurprising that the cost of lexical
analysis is significant.
Hanson and Fraser's lcc compiler is twice as fast as gcc in part
becausae of clever lexical analysis. People writing new code should
look into the re2c tool (described in LOPLAS around 1994, I think),
which embodies the work of a very clever person who figured out how to
apply Hanson and Fraser's tricks automatically. I've got to look up
the name, beause I keep recommending the work, and the people involved
should get credit. Waite's paper in SP&E entitled `The Cost of
Lexical Analysis' is also a good read, adn I think there are a couple
of SP&E papers on parsing as well.
It's my opinion that *compilation* speed (as opposed to speed of the
generated code) doesn't get enough attention from the
programming-language community.
N
P.S. LOPLAS --> ACM Letters on Programming Languages and Systems
SP&E --> Software---Practice & Experience
David Baggett
In article <59uhn6$c...@mamba.cs.Virginia.EDU>,
Norman Ramsey <n...@mamba.cs.Virginia.EDU> wrote:
>I think you're assuming that the goals for an IF language or compiler
>should be the same as the goals for a compiler for a general-purpose
>programming language, e.g., the generated code should run fast.
>What evidence have you got in favor of this position?
First of all, I didn't mean to imply that raw performance is at the top of
my list of IF system requirements, because it really isn't. My point was
mainly that I don't think it's reasonable to call any of these compilers
professional-quality. There's nothing *wrong* with an IF compiler that
doesn't do fancy optimizations; I just wouldn't call it
"professional-quality".
However, it's worth looking at the other part of your question, which is
why should an IF language be domain-specific rather than general-purpose.
The traditional analysis (with which I have historically agreed) has been
that limiting the set of problems one is intended to solve with a language
makes it more focused, and therefore [much hand-waving] "simpler, better,
easier to learn, etc."
The problem with this analysis is that if one takes a step back (as I've
done, since I haven't written a stitch of code in TADS or Inform in quite
some time), one sees that these languages have gone more the way of PL/I
and C++ -- they have become "kitchen sink" languages with feature upon
feature grafted onto the language's syntax and semantics. They are
certainly not simple anymore, and I'd question claims that they're easy to
learn as well.
Now when I look at TADS and Inform I ask myself why the parser is *part of
the language*. Why things like Z-Machine "properties" are welded into the
fabric of Inform. For Inform it's because (I assume) Graham has always
viewed Inform's symbiotic relationship with the Z-Machine as inviolable.
So why not weave Z-Machine features/quirks/limitations into the language?
Frankly, I'm pretty sure we'd be doing just as well with a simple dialect
of an established general-purpose object-oriented langauge (say, Smalltalk,
to name yet another one), extended with lots of library routines. Library
routines to, for example, parse input commands. So I pass the baton back
to you: what would be *wrong* with this? How would this be worse than TADS
or Inform, given equivalently powerful libraries?
>It's easy to write long lists of desiderata for these languages and
>tools.
Given that there's a clear understanding that the libraries are not part of
the language design, my list of stuff to remove is much bigger than my list
of stuff to add.
Roger Plowman
n...@mamba.cs.Virginia.EDU (Norman Ramsey) wrote:
>It's easy to write long lists of desiderata for these languages and
>tools. What's on other people's lists?
>
>N
>--
>Norman Ramsey
>http://www.cs.virginia.edu/~nr
I've always liked the minimalist approach when creating programs--and
this would apply to languages as well. I've waded through just about
everything in the if-archive (that's in english, at least) looking for
the best programming language.
Alas, they're all deficient in some respect. Right now I'm using TADS
and WorldClass, because they have the power I need (especially the
Sensor class) but there's definitely a lack of elegance in WorldClass.
Dave talks about putting everything in libraries, but this I think
misses the point. Libraries *ARE* part of the language, the IF
writer/programmer has to learn the library in order to use the
functionality it provides. So, in effect, putting all the goodies in
the library (as opposed to the language itself) is more a packaging
issue than a practical difference. At least to the writer/programmer
who has to use the language.
My list starts and ends with elegance in design. Elegance (for me)
simply means the ability to write clear, simple, *short* code. It
means the creation of code is (after a small learning curve)
intuitive. It means many common tasks should *already* be done for me,
in such a way that I can get at them easily, and not have to write a
lot of code.
Take senses, for instance. IF started out using the sense of sight,
and much of the text handling abilities we've come to love in our IF
tools revolve around the sense of sight.
In Thief's Quest I want to implement all the other senses, sound,
touch, taste, and smell. This should be a simple thing. Yet the
WorldClass library offers over two dozen functions that implement the
various senses. There are function *sets* for each sense. There are
methods and properties to enable the senses, others to record the text
associated with them, and yet others to verify objects are detectable
to the various senses.
ARGH!!!!!!
WorldClass (and Inform and Hugo and many others) remind me of computer
versions of mechanized Victoriana. They are intricate, beautiful,
mesmerizing in their complexity.
And too hard to use. Alan is a noble effort to go in the opposite
direction. Unfortunately it goes too far, putting a strait-jacket on
the ability to do what I want the *way* I want.
In my opinion (and this is only my opinion) the next-generation IF
langauges need to strike a better balance between power and
complexity. Today's computer systems are powerful enough to compile
complex (but intuitive) syntax in reasonable time.
We need to break away from awkward (but easily parsed) syntax like C
based lanagues to more syntactically complex languages that either A)
more closely resemble English (Spanish, German, French....) OR B)
restrict themselves to the IF domain more naturally.
Object orientation is a good first step, but by itself it isn't
enough. Libraries are also good, but in and of themselves don't offer
a solution to object proliferation. What we need are not cleverly
coded functions and optimizing compilers, but rather cleverly
constructed syntaxes that either match the writer's language or the
problem being solved.
The creators of our current day tools have certainly given us more
than we've ever had. But the next generation of tools, like present
day automobiles, need to be easier to use and maintain than their
predecesors.
Respectfully,
Wolf
Norman Ramsey
In article <59vlb3$8...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
>However, it's worth looking at the other part of your question, which is
>why should an IF language be domain-specific rather than general-purpose.
>The traditional analysis (with which I have historically agreed) has been
>that limiting the set of problems one is intended to solve with a language
>makes it more focused, and therefore [much hand-waving] "simpler, better,
>easier to learn, etc."
>
>The problem with this analysis is that if one takes a step back (as I've
>done, since I haven't written a stitch of code in TADS or Inform in quite
>some time), one sees that these languages have gone more the way of PL/I
>and C++ -- they have become "kitchen sink" languages with feature upon
>feature grafted onto the language's syntax and semantics. They are
>certainly not simple anymore, and I'd question claims that they're easy to
>learn as well.
Just like Common Lisp :-)
I've never really bought the simplicity argument. Successful
languages tend to be big, and often messy. The only `simple'
exception I can think of is Scheme. This fact doesn't depress me as
much as it once did. I must be getting old.
>Now when I look at TADS and Inform I ask myself why the parser is *part of
>the language*.
I think the special-purpose parser-definition language is worthwhile
for the same reasons yacc is worthwhile---building parsers by hand is
a pain in the butt when the vocabulary to be recognized changes
constantly. I find the parser sublanguage the most intriguing part of
Inform, especially the ability to modify an existing parser (e.g., the
library parser) without touching the code.
If I find a flaw in the parser sublanguage, it's that it's not
comprehensive enough; one sometimes has to write routines
that go grubbing around in individual words. One way to correct that
flaw might be to support more than one parser in a game---a
distinguished, general-purpose, `main' parser for user commands, and
other, special-purpose parsers so that
look up mumble in book
doesn't have to be so damn hard to program. It's a nontrivial design
problem, but one worth tackling IMO.
>Why things like Z-Machine "properties" are welded into the
>fabric of Inform.
Are `properties' anything more or less than fields whose values are
statically known to be booleans? I would imagine that it's useful to
distinguish the booleans, and I imagine that
give x light
x has light
x hasnt light
are very helpful to novices. (But I think `give x ~light' is a
syntactic disaster.) It's annoying that properties are always
initialized (i.e., you can't catch a programming error in which you
fail to say whether an object has p or ~p), but this behavior enables
complex library behavior without requiring the programmer to do any
thinking. I might search for another linguistic mechanism to support
libraries, but I might not find one :-)
>Frankly, I'm pretty sure we'd be doing just as well with a simple dialect
>of an established general-purpose object-oriented langauge (say, Smalltalk,
>to name yet another one), extended with lots of library routines. Library
>routines to, for example, parse input commands. So I pass the baton back
>to you: what would be *wrong* with this? How would this be worse than TADS
>or Inform, given equivalently powerful libraries?
Setting aside the question of the parser, I think we're on the same
page here. I'm not a big fan of Smalltalk and Scheme because I'm not
a big fan of dynamic type disciplines, but again my reading suggests
that novices find static typing more difficult to learn than dynamic
typing, and I would hope that one goal of an IF language would be to
help people who have never before written a program. Again I like the
Inform properties because of the semblance of static typing.
Also, isn't Inform pretty much a pastiche of existing features of
dynamically typed, `mostly-object-oriented' languages, bundled with a
very effective library? I don't find it a bad effort, in the spirit
of Tony Hoare's `hints on language design'. The dynamically typed O-O
model fits IF better than it fits anything I've seen since the Lisp
machine window system.
>Given that there's a clear understanding that the libraries are not part of
>the language design, my list of stuff to remove is much bigger than my list
>of stuff to add.
Why pay too much attention to the language when the library is really
where the action is? If asked why I thought Inform was good, I would
canswer:
- rich library with solid documentation
- language lets you exploit the library without much verbiage
- syntax and semantics seem accessible to novices
- decently fast compiler targets widely available abstract machine
There might be gains to moving to a general-purpose language, but if
the easy exploitation of the library is lost, I don't think they would
be worth it. And I'm skeptical that a general-purpose language would
make things simpler. (If the language is Scheme, one has to contend
with heap-allocated closures and first-class continuations in the
implementation. Novices have to swallow the parentheses.) It seems
that the primary benefit would be that you might have your choice of
compiler. But if you wanted the portability, I bet you'd want to be
compiling to an abstract machine pretty soon, and existing compilers
probably wouldn't help much.
What do you see as the benefits of using standard general-purpose
languages to write IF?
Marnix Klooster
n...@mamba.cs.Virginia.EDU (Norman Ramsey) wrote:
> My pet peeve at the moment is that existing tools seem to offer little
> in the way of static type checking. A language like Inform leaves a
> lot of checking for run time. For example, according to the language,
> every property is meaningful on every object. This rule offers
> tremendous flexibility, but it also leads to heavy overloading of
> properties like `general'. On the other hand, the obvious way of using
> a fully static type system like that for C++, Java, or Modula-3 would
> make Inform programming significantly more awkward than it is today.
> Reconciling these competing goals would make a good master's project :-)
How would e.g. Inform programming be more complicated when static
typing is added? If the problem is that the programmer must
write down the declarations explicitly, a good solution is to
have automatic type inference, and optional type declarations --
if the inferred type does not match the declared type a
compile-time error is signalled. This is standard in languages
such as Haskell and ML.
> It's easy to write long lists of desiderata for these languages and
> tools. What's on other people's lists?
I'd like to have a language with a simple semantics, a readable
syntax, together with powerful libraries. _Simple_ means no
limits (no upper bound on numbers or string lenghts), elegant
arithmetic (as in Scheme), and a few orthogonal constructs with
which a lot can be achieved. _Readable_ means not having to use
too many words (e.g., block structure can be indicated by
indentation instead of delimiters), and generally being
consistent. Since a library is essentially a language extension,
these criteria hold for them too.
> Norman Ramsey
Marnix Klooster
n...@mamba.cs.Virginia.EDU (Norman Ramsey) wrote:
> In article <59vlb3$8...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
[about TADS and Inform]
> > they have become "kitchen sink" languages with feature upon
> >feature grafted onto the language's syntax and semantics. They are
> >certainly not simple anymore, and I'd question claims that they're easy to
> >learn as well.
>
> Just like Common Lisp :-)
>
> I've never really bought the simplicity argument. Successful
> languages tend to be big, and often messy. The only `simple'
> exception I can think of is Scheme. This fact doesn't depress me as
> much as it once did. I must be getting old.
There are two sides to simplicity, really. One is that the
syntax and semantics of a language should have a few, powerful,
orthogonal features. Once this simplicity is lost there is no
way to get it back.
The other side is that a successful language should offer a lot
of `prefab functionality' to the programmer in the simplest way
possible. This is where `standard libraries' come in. It is
essential that every standard library is carefully designed, just
as the language itself, because a library is basically just a
language extension. I believe that this can be done without
sacrificing simplicity, but it takes design. (A good module
system is indispensable for this.)
To be honest, the coin has a third side: efficiency. But that is
really not part of language design, but of language
implementation. Making a language more complex to make its
implementation simpler or more efficient is generally a bad
thing, I think. Design and implementation should be separated as
far as possible.
> >Now when I look at TADS and Inform I ask myself why the parser is *part of
> >the language*.
>
> I think the special-purpose parser-definition language is worthwhile
[snipped...]
I agree with you, Norman -- but why should this mini-language be
part of the language per se? The alternative is to create a
parser library which can be used when necessary and ignored if
not. If there is a means of extending the language's syntax, as
in Scheme or Dylan, this alternative is at least as readable, and
much more flexible, than the current Inform approach.
> >Why things like Z-Machine "properties" are welded into the
> >fabric of Inform.
Because the raison d'etre of Inform is to create Z-machine files.
The Z-machine is too weird to efficiently compile a
general-purpose language to. (Or so I think. I'd love to be
proven wrong, however.)
> Also, isn't Inform pretty much a pastiche of existing features of
> dynamically typed, `mostly-object-oriented' languages, bundled with a
> very effective library? I don't find it a bad effort, in the spirit
> of Tony Hoare's `hints on language design'. The dynamically typed O-O
> model fits IF better than it fits anything I've seen since the Lisp
> machine window system.
Inform is definitely _not_ a bad effort. I consider it to be at
about the same language level as C++: high-level object-oriented
assembler. (Flames by private e-mail, please.) Sure, there are
a lot of things in it that I would have done differently. But
then again, I probably wouldn't have done it at all.
(What `hints on language design' did Hoare give? Do you have a
specific reference in mind?)
Just out of curiosity: Why should an i-f language be dynamically
typed? (Would Modula-X be a bad i-f language?) Why should it be
object-oriented? (Would Scheme be a bad i-f language?)
> >Given that there's a clear understanding that the libraries are not part of
> >the language design, my list of stuff to remove is much bigger than my list
> >of stuff to add.
>
> Why pay too much attention to the language when the library is really
> where the action is?
That is exactly the point. As I argued before, it is important
that the language itself should be as simple, elegant, and
powerful as possible. With Inform (and TADS), however, much of
the action is in the language: the parser, the distinction
between dictionary words and other strings, syntax such as (x ==
5 or 6 or 7), action names in before/after routines, Nearby
declarations, Lowstring declarations, and so on. I believe that
those are the features that make Inform complicated. With a
sufficiently general and simple language all of these could be
moved to libraries, where they belong. And this also opens up
the possibility of writing alternative libraries, if the standard
ones are not good enough for your purposes.
> If asked why I thought Inform was good, I would
> canswer:
> - syntax and semantics seem accessible to novices
Still they are way too complicated, IMnsHO. I count this a
disadvantage of Inform. A programming novice shouldn't be
messing around with some C clone, whatever the problem domain is.
> There might be gains to moving to a general-purpose language, but if
> the easy exploitation of the library is lost, I don't think they would
> be worth it. And I'm skeptical that a general-purpose language would
> make things simpler. (If the language is Scheme, one has to contend
> with heap-allocated closures and first-class continuations in the
> implementation. Novices have to swallow the parentheses.) It seems
> that the primary benefit would be that you might have your choice of
> compiler. But if you wanted the portability, I bet you'd want to be
> compiling to an abstract machine pretty soon, and existing compilers
> probably wouldn't help much.
Generally, a general-purpose language makes for a more complex
implementation. But the simplicity should be in the language and
its libraries, not necessarily in the language implementation.
One way to achieve portability is to have a standard library
containing functionality that is efficiently supported by the
chosen abstract machine. These can then be used by a generic
compiler, but a special-purpose compiler can implement calls to
this library by a couple of abstract machine instructions. I
have been thinking about doing this for the Z-machine and a
language design I am tinkering with.
David Baggett
In article <32c42118...@news.one.net>, Roger Plowman <wo...@one.net> wrote:
>n...@mamba.cs.Virginia.EDU (Norman Ramsey) wrote:
>Right now I'm using TADS and WorldClass, because they have the power I need
>(especially the Sensor class) but there's definitely a lack of elegance in
>WorldClass.
>
>[...] I want to implement all the other senses, sound, touch, taste, and
>smell. This should be a simple thing. Yet the WorldClass library offers
>over two dozen functions that implement the various senses. There are
>function *sets* for each sense. There are methods and properties to enable
>the senses, others to record the text associated with them, and yet others
>to verify objects are detectable to the various senses.
I thorougly agree with your assessment. The main reason that WorldClass is
so complicated is that it's the first try at doing many new things like
first-class senses. In my experience, you need to write a new program at
least several times from scratch before you can hope to not only get it all
right but make it simple and clear as well. I never really wanted to
release WorldClass, but Adam Thornton basically convinced me that it
couldn't hurt to do so.
I think the sense-reach strategy is basically the right one. But there do
not need to be eighty-zillion methods for this, as you point out. Things
like canputinto and canspeakto are ugly band-aids that should be replaced
by something more elegant.
Not to sound like a broken record, but I think part of the problem, though,
is the lack of first-class functions in TADS. And here we come
full-circle, because it was my struggle to write WorldClass and TADS that
prompted me to look at how Scheme and other functional languages would work
for IF.
A language that lacks first-class functions tends to make the programmer
name *everything*. Hence the absurd number of important names in
WorldClass.
Another problem with WorldClass is that it is slow, particular in tracking
what every NPC and PC knows about in the world. Since this is not a
particularly exotic thing to do, and since the WorldClass way of doing it
is not terribly inefficient, it seems to me that 1) the TADS VM interpreter
could use some speedups, 2) the TADS compiler needs to optimize code, or 3)
the very idea of compiling to a VM machine binary is rather limiting.
I don't even want to *think* about implementing Prolog-style backtracking
searches in TADS VM or Z-Machine code!
There are alternatives to straight VM binaries like Just-in Time
compilation. Some Java interpreters use JIT now, but it's a lot of work to
get JIT working and debugged.
>Dave talks about putting everything in libraries, but this I think
>misses the point. Libraries *ARE* part of the language, the IF
>writer/programmer has to learn the library in order to use the
>functionality it provides. So, in effect, putting all the goodies in
>the library (as opposed to the language itself) is more a packaging
>issue than a practical difference.
There is a key difference. Library code is written entirely in the syntax
and semantics of the host language. Therefore, if you know the syntax and
semantics of the language, you are certain to be able to read any library
code you come across. (This assumes that library code is available. I
think that for IF systems that's a pretty safe bet.)
It seems to me that there are three basic places you can put functionality
in an IF system:
1) In the target virtual machine
2) In the language
3) In a library
Here are examples of each, from TADS:
In the VM:
random number generator, input tokenization, arithmetic primitives,
status line display, file selector dialog box, daemons (notify),
caps(), outhide(), length(), preparse()
In the language:
verDoX, VerIoX, doX, ioX methods required to interface to parser;
Special syntax for parser interface:
verb = 'in' 'go in' 'enter'
doAction = 'Enter'
doSynonym = 'In'
compoundWord 'on' 'to' 'onto';
article = 'the' 'a' 'an'
formatstring 'you' fmtYou;
specialWords
StringObj
NumberObj
"This outputs a string";
"This outputs the value <<value>>.";
In a library:
Standard classes like PC, NPC, door, key, food, etc.
Sense-reach checking, etc.
Now consider the pros and cons of putting features in each of the three
places:
In the VM:
PROS: - Highest performance (native machine code speed)
CONS: - Becomes set in stone once VM implementations are in use and
games use the features. Therefore, nearly impossible for
anyone, including the system author, to change.
- One can only understand the feature fully by reading the
VM interpreter source code. Where there is confusion,
different VM implementations may vary, causing problems in
games that depend on one particular interpretation.
In the language:
PROS: - Special syntax can call users' attention to critical
features.
- Special syntax may enable a more compact representation.
CONS: - One can only fully understand the feature by reading
the compiler source code (an even worse situation than
for VM features).
- The "my source looks like line noise" problem: Nifty syntax
often conveys little intuition to any but language experts.
Novices may use syntax without fully understanding it.
- Special syntax must be fully mastered before one can
read programs in the language.
- Even less modifiable after the fact than VM features,
since existing source code will break.
In the library:
PROS: - Reading, understanding, and modifying the feature requires
the same knowledge of the language as writing and reading
one's own game source code (ignoring algorithm complexity,
of course).
- New, related, features can be derived simply by modifying the
source code.
- Bug-fixes can be posted to the net and applied locally;
no need to update the compiler or (oh no!) chase down and update
every user's copy of the VM interpreter.
CONS: - In the absence of fancy JIT techniques, code runs much slower
than native code "stored" in the VM.
Clearly some features need to go in more than one place.
For most features, it's pretty clear which pros and cons you care about.
And I would say that the obvious conclusion is that you want to put as
little as possible in the VM and compiler, and as much as possible in
libraries.
>In my opinion (and this is only my opinion) the next-generation IF
>langauges need to strike a better balance between power and complexity.
The only way I know of to make complex things comprehensible is to put
*abstraction* to work. We use abstraction every time we use algebra to
reduce an expression -- you don't have to any intuition about why an
algebraic operation preserves equality; you just apply the operation
mechanically. This lets you worry about the high-level goal you're
trying to reach.
The same principle applies to computer programming. A good language
encourages you to vigorously exploit abstraction. It asks you to take code
that's common to two or more places in your program and to make it into a
separate black-box tool that only needs to be debugged once.
Lexical analyzer generators (to use a recent example) abstract the problem
of tokenizing, so you can write something like
integer -> [0-9]+
identifier -> [a-z_][a-z_0-9]*
and represent, in two lines, what you have to write tons of C code to do.
This makes it easy to understand, debug, and extend the lexical analysis
phase of your program. You do not need to understand or even think about
the complicated mechanisms that turn your two lines into a correct and
equivalent lexical analyzer.
How likely are you to have a bug in your two lines? And now how likely are
you to have bugs in your many lines of C code?
Abstraction, plain and simple.
>Today's computer systems are powerful enough to compile complex (but
>intuitive) syntax in reasonable time.
It's a matter of taste, but I don't think that more complex syntax will
help; I think it will make it worse. Have you ever read an APL program?
Even if you are a veteran programmer, unless you are specifically an *APL*
programmer, APL programs look like line noise.
Is my special syntax above significantly better than this:
(integer (+ 0 9))
(identifier (- a z _) (* (- a z _ 0 9)))
Perhaps if you're not at all familiar with lisp syntax it is. But if
you've spent a couple hours learning to read lisp code (there are very few
rules), you can read the lisp version easily. And the minimalist lisp
syntax can reasonably naturally express all the things you'll invent
special syntax to do. Once you know the lisp rules, you can read any lisp
expression. There's never a new operator to learn, an ambiguity you can't
mentally resolve, or operator precedences to internalize.
>We need to break away from awkward (but easily parsed) syntax like C based
>lanagues to more syntactically complex languages that either A) more
>closely resemble English (Spanish, German, French....)
They tried that. It's called COBOL. (OK, cheap shot...)
>OR B) restrict themselves to the IF domain more naturally.
I still do not see any concrete evidence that this would help anything.
Can you give examples of what you think would be a better syntax (either
domain-specific, or "closer to English")?
Graham Nelson
>
> In article <59obcq$t...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
> >(On the other hand, I mentioned the Atari 800 flippantly. It's a salient
> >point, though, that one of Inform's inviolable implicit goals is to compile
> >binaries that will run on Atari 800's and Apple ]['s. This is a cool
> >thing, but once again I don't think it's worth making such great
> >compromises for. In other words, the Z-Machine as target architecture is
> >both the coolest and the worst choice Graham made for Inform. It makes the
> >language design much ickier than it might otherwise be.)
I don't think it necessarily does make the language design
"ickier", but it has resulted in some historical accidents,
and I think I probably would prefer run-time data typing
and a couple of other tweaks. Otherwise, I continue to
think the Z-machine is an excellent design, and the recent
proliferation of Z-machine games (which are being played
on machines where other design systems have never reached:
people _do_ play on hand-held computers, for instance)
bears this out.
Have any Inform authors had to seriously compromise their
games because of restrictions brought on by the Z-machine?
I haven't, except when working some years ago for restricted
subsets of the Z-machine.
> Oh wow, are you hypothesizing different backends for the same front-end
> Inform compiler? That is, the same source language compiling into Zcode or
> TADS code or some other virtual machine [such as Java.. dunno if that would
> make any sense at all]?
It already compiles to six different virtual machines, V3 to
V8, (but that's just my little joke). I have very occasionally
wondered if an option for "output as ANSI C" would be worth the
trouble. But I don't think it would add any new portability
(quite the reverse, actually).
As for Java, surely better to wait for the completion of the
Java Z-machine interpreter?
> As I told David in e-mail, it sounds to me like Inform isn't the language
> for him. I mean, it seems to me that the whole reason for the existance of
> Inform is to compile *into the existing Zmachine*. Graham may state that
> I'm wrong.
Ermm... well, I like to think that the purpose of Inform is to
make easier the creation of decent-quality games which are as
portable as humanly possible. Given the latter requirement,
some kind of virtual machine has to be used. I continue to
think that the Z-machine is a good choice, even if I did get it
"off the peg" rather than tailor-make it.
The aim is certainly not to worship the Z-machine!
> I don't even program in Inform, but with people talking about
> the inability to create objects at runtime and other "arbitrary" limitations,
> it seems to me that the reason people "put up with" this sort of stuff is
> because they *want* their game as absolutely portable as possible. Otherwise
> they would use some other more modern game development system.
Inform is fairly modern. Only Hugo, which is (I think it's fair
to say) strongly influenced by Inform, post-dates it as a serious
design system. And actually you can create objects at runtime.
To get back to what Dave was saying, I'm interested by his
full post (on automatically-generated lexical scanners). I shall
bear that in mind should I write a compiler again. I continue to
distrust automatically generated code as potentially unsafe (how
sure am I that it will work?) and potentially awkward to maintain,
but Dave's performance statistics suggest that there's no longer
a grave handicap in using them.
As far as I know, the lexical scanning phase of Inform 6 has
never gone wrong. (And there are several good reasons not to
use a standard lexical scanner on Inform: it would slow down
the syntax analyser marginally, for instance.)
On small computers vs the sort Dave has in his office, well now,
a pretty large number of Acorn users are running Inform on
A3000 series Archimedes: 1M or 2M of RAM and a processor which
runs at about 1/60th the speed of the one in my own Acorn. And
why shouldn't they? It may be fair enough to expect commercial
users of a compiler to go and buy the latest model computer
every other year, but Inform isn't only for that kind of people.
Graham Nelson
In article <59sbav$5...@life.ai.mit.edu>, David Baggett
<URL:mailto:d...@lf.ai.mit.edu> wrote:
>
> In article <59qffk$e...@news.spies.com>, Matt Ackeret <mat...@area.com> wrote:
>
> >Oh wow, are you hypothesizing different backends for the same front-end
> >Inform compiler? That is, the same source language compiling into Zcode or
> >TADS code or some other virtual machine [such as Java.. dunno if that would
> >make any sense at all]?
>
> Inform's design is intimately tied to weird Z-Machine restrictions.
I dispute this, and certainly the implication that Inform
is in some way overwhelmingly handicapped. Z-machine quirks
are responsible for a number of oddities in the marginalia of
Inform, yes.
> A better choice would have been to chuck the Z-Machine and design a new
> virtual machine. That's what Mike Roberts did, and it does show when you
> compare the design of the two languages. Hindsight is 20/20, of course.
And opinions vary (although in some respects I agree with
yours: I rather like TADS as an exercise in computer science,
though I have less enthusiasm for its standard library).
> >As I told David in e-mail, it sounds to me like Inform isn't the language
> >for him. I mean, it seems to me that the whole reason for the existance of
> >Inform is to compile *into the existing Zmachine*.
>
> Well, I guess you're right: I don't use Inform, and never will as long as
> it looks anything remotely like Inform 5 or 6.
>
> But the point of the whole tirade wasn't to show how bad a choice it would
> be for me, but to dispute claims about the wonderfulness of Inform's design
> and implementation (which are more frequent, and less often challenged now
> that Inform is the undisputed king of the IF hill).
May I say once more that critical appraisal is an accolade,
not an attack, and (not that my opinion on the subject should
matter) I welcome it.
> Inform fans (including, rarely, Graham himeslf) have not been claiming that
> their favorite langauge is superb "given that it's crippled and at times
> bizarre so as to support the Z-Machine and old hardware" -- there are never
> any such qualifications. And I firmly believe that targeting the old and
> creaky Z-Machine sent Inform down a language design rathole which we could
> escape with a new VM and an old and creaky but very highly evolved language
> (lisp).
Firstly: I disagree as to Inform's disfigurement and bizarreness.
For a cripple, it does get about.
Secondly, the implication that a LISP-like language is incompatible
with the Z-machine is wrong. Infocom's own language, ZIL, was
essentially LISP (and some Z-machine features reflect that: for
instance the order in which opcodes are processed is designed to
make a LISP syntax analyser's job easier). And I have to say, the
bits of ZIL I've seen... have, well, let's call it "charm" if we're
going to avoid accusations of bizarreness. The most frequent
criticism of Inform has been that it has a steep learning curve.
To someone who's never programmed before, ZIL (or LISP) would be
a hard furrow to plough.
Marnix Klooster
Marnix Klooster
n...@mamba.cs.Virginia.EDU (Norman Ramsey) wrote:
> In article <59vlb3$8...@life.ai.mit.edu>, David Baggett <d...@ai.mit.edu> wrote:
[about TADS and Inform]
> > they have become "kitchen sink" languages with feature upon
> >feature grafted onto the language's syntax and semantics. They are
> >certainly not simple anymore, and I'd question claims that they're easy to
> >learn as well.
>
> Just like Common Lisp :-)
>
> I've never really bought the simplicity argument. Successful
> languages tend to be big, and often messy. The only `simple'
> exception I can think of is Scheme. This fact doesn't depress me as
> much as it once did. I must be getting old.
There are two sides to simplicity, really. One is that the
syntax and semantics of a language should have a few, powerful,
orthogonal features. Once this simplicity is lost there is no
way to get it back.
The other side is that a successful language should offer a lot
of `prefab functionality' to the programmer in the simplest way
possible. This is where `standard libraries' come in. It is
essential that every standard library is carefully designed, just
as the language itself, because a library is basically just a
language extension. I believe that this can be done without
sacrificing simplicity, but it takes design. (A good module
system is indispensable for this.)
To be honest, the coin has a third side: efficiency. But that is
really not part of language design, but of language
implementation. Making a language more complex to make its
implementation simpler or more efficient is generally a bad
thing, I think. Design and implementation should be separated as
far as possible.
> >Now when I look at TADS and Inform I ask myself why the parser is *part of
> >the language*.
>
> I think the special-purpose parser-definition language is worthwhile
[snipped...]
I agree with you, Norman -- but why should this mini-language be
part of the language per se? The alternative is to create a
parser library which can be used when necessary and ignored if
not. If there is a means of extending the language's syntax, as
in Scheme or Dylan, this alternative is at least as readable, and
much more flexible, than the current Inform approach.
> >Why things like Z-Machine "properties" are welded into the
> >fabric of Inform.
Because the raison d'etre of Inform is to create Z-machine files.
The Z-machine is too weird to efficiently compile a
general-purpose language to. (Or so I think. I'd love to be
proven wrong, however.)
> Also, isn't Inform pretty much a pastiche of existing features of
> dynamically typed, `mostly-object-oriented' languages, bundled with a
> very effective library? I don't find it a bad effort, in the spirit
> of Tony Hoare's `hints on language design'. The dynamically typed O-O
> model fits IF better than it fits anything I've seen since the Lisp
> machine window system.
Inform is definitely _not_ a bad effort. I consider it to be at
about the same language level as C++: high-level object-oriented
assembler. (Flames by private e-mail, please.) Sure, there are
a lot of things in it that I would have done differently. But
then again, I probably wouldn't have done it at all.
(What `hints on language design' did Hoare give? Do you have a
specific reference in mind?)
Just out of curiosity: Why should an i-f language be dynamically
typed? (Would Modula-X be a bad i-f language?) Why should it be
object-oriented? (Would Scheme be a bad i-f language?)
> >Given that there's a clear understanding that the libraries are not part of
> >the language design, my list of stuff to remove is much bigger than my list
> >of stuff to add.
>
> Why pay too much attention to the language when the library is really
> where the action is?
That is exactly the point. As I argued before, it is important
that the language itself should be as simple, elegant, and
powerful as possible. With Inform (and TADS), however, much of
the action is in the language: the parser, the distinction
between dictionary words and other strings, syntax such as (x ==
5 or 6 or 7), action names in before/after routines, Nearby
declarations, Lowstring declarations, and so on. I believe that
those are the features that make Inform complicated. With a
sufficiently general and simple language all of these could be
moved to libraries, where they belong. And this also opens up
the possibility of writing alternative libraries, if the standard
ones are not good enough for your purposes.
> If asked why I thought Inform was good, I would
> canswer:
> - syntax and semantics seem accessible to novices
Still they are way too complicated, IMnsHO. I count this a
disadvantage of Inform. A programming novice shouldn't be
messing around with some C clone, whatever the problem domain is.
> There might be gains to moving to a general-purpose language, but if
> the easy exploitation of the library is lost, I don't think they would
> be worth it. And I'm skeptical that a general-purpose language would
> make things simpler. (If the language is Scheme, one has to contend
> with heap-allocated closures and first-class continuations in the
> implementation. Novices have to swallow the parentheses.) It seems
> that the primary benefit would be that you might have your choice of
> compiler. But if you wanted the portability, I bet you'd want to be
> compiling to an abstract machine pretty soon, and existing compilers
> probably wouldn't help much.
Generally, a general-purpose language makes for a more complex
implementation. But the simplicity should be in the language and
its libraries, not necessarily in the language implementation.
One way to achieve portability is to have a standard library
containing functionality that is efficiently supported by the
chosen abstract machine. These can then be used by a generic
compiler, but a special-purpose compiler can implement calls to
this library by a couple of abstract machine instructions. I
have been thinking about doing this for the Z-machine and a
language design I am tinkering with.
> Norman Ramsey
David Baggett
Evan Day
In article <ant221433b49M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>In article <59eu68$6...@news.multiverse.com>, Matthew Russotto
><URL:mailto:russ...@ariel.ct.picker.com> wrote:
>> Ignorant criticism, however, is useless. There's been plenty of criticism
>> of TADS (including a certain nameless library), Inform (including the
>> hanging-else bug), AGT (nevermind), etc.
>
>Just to recap: there is no hanging-else bug in Inform.
>It is a late bug. It has ceased to be. Bereft of life,
>it rests in peace. It has shuffled off this mortal coil
>and joined the choir invisible.
>
>This is an ex-bug.
Are you sure it isn't just pining for the fjords?
--
i have no .sig - wait, i guess i do
Erik Max Francis
Graham Nelson wrote:
> I have very occasionally
> wondered if an option for "output as ANSI C" would be worth the
> trouble. But I don't think it would add any new portability
> (quite the reverse, actually).
This sounds like a great idea. Not only would it be powerful, but it would
also be fairly straightforward.
> As for Java, surely better to wait for the completion of the
> Java Z-machine interpreter?
I've already seen at least one: Zplet.
--
Erik Max Francis | m...@alcyone.com
Alcyone Systems | http://www.alcyone.com/max/
San Jose, California | 37 20 07 N 121 53 38 W
&tSftDotIotE | R^4: the 4th R is respect
"You must surely know if man made heaven | Then man made hell"
Roger Plowman
d...@lf.ai.mit.edu (David Baggett) wrote:
>I thorougly agree with your assessment. The main reason that WorldClass is
>so complicated is that it's the first try at doing many new things like
>first-class senses. In my experience, you need to write a new program at
>least several times from scratch before you can hope to not only get it all
>right but make it simple and clear as well. I never really wanted to
>release WorldClass, but Adam Thornton basically convinced me that it
>couldn't hurt to do so.
First make it work, then make it simple? :) I can see that.
>I think the sense-reach strategy is basically the right one.
Well, you could be right. You may also be indulging in massive
overkill, however. :)
Consider, there are 4 basic scenarios.
1) An object is making a loud and absolutely overwhelming noise, for
example a radio blaring at full volume. This isn't something the
player's likely to overlook, so you can simply include it in the
object's description. If the noise is loud enough you might even check
for the object's sound in surrounding locations. Here there's little
need for sensory paths. Just an object sound description.
2) An object is making a subtle noise, for example the fan on a
computer. Unless the player specifically thinks to listen the sound
won't intrude on his consciousness. Again, there's little need for a
sense path.
3) The player's *location* is making an overwhelming noise. For
example, when he's standing by a waterfall. Right now, as far as I can
tell, WorldClass doesn't handle location noises. Of course, you could
include the sound in a waterfall object (which you'd probably need
anyway to handle stupidities like "Get Waterfall"), but it would be
simpler to put a simple sound description in the location itself.
4) The player's location is making a subtle noise (for example, wind
rustling thru the leaves in a forest).
Instead of the "cansee/smell/hear/touch/taste" functionality, what
about sensory thresholds coupled with simple descriptions? For
example, say the actor has a sound threshold of 60 normally. Any sound
of 60 or greater automatically lists itself, any sound of 59 or less
won't be apparent until the actor actively lowers his threshold with a
"listen" or "listen to" command.
You could also refine this, so that if a player is constantly using
the "listen" command his threshold automatically starts to lower. A
daemon could automatically begin to raise sensory thresholds once a
player stopped using the listen/sniff/taste/touch commands. IOW, as he
relaxes his senses start to dull...
Sensory paths between objects would also be a little more natural.
Each container could have a sensory damping level, for example a
thermos might have a sound damping level of 10, but a steel vault
might have a sound damping of 100. Likewise, you could have a class
that automatically damps all senses within it (or just a particular
sense) or one that doesn't (like a transparent container doesn't limit
sight).
>A language that lacks first-class functions tends to make the programmer
>name *everything*. Hence the absurd number of important names in
>WorldClass.
I'm unfamiliar with the concept of a first-class function. Could you
explain? I'm not sure I see how any function that's nameless could be
useful. I'm not familiar with Scheme.
>Another problem with WorldClass is that it is slow, particular in tracking
>what every NPC and PC knows about in the world. Since this is not a
>particularly exotic thing to do, and since the WorldClass way of doing it
>is not terribly inefficient, it seems to me that 1) the TADS VM interpreter
>could use some speedups, 2) the TADS compiler needs to optimize code, or 3)
>the very idea of compiling to a VM machine binary is rather limiting.
I'm not sure I follow your argument here. Of course (being a
programmer by trade) I'm *never* going to pass up speed enhancements
in an interpreter, compiler, VM, or computer, but perhaps WorldClass
itself needs some optimizing in these areas?
>There are alternatives to straight VM binaries like Just-in Time
>compilation. Some Java interpreters use JIT now, but it's a lot of work to
>get JIT working and debugged.
I'm not familiar with Java (yet, <groan>) but JIT sounds like cached
tokenizing to me. How does it differ?
>>Dave talks about putting everything in libraries, but this I think
>>misses the point. Libraries *ARE* part of the language, the IF
>>writer/programmer has to learn the library in order to use the
>>functionality it provides. So, in effect, putting all the goodies in
>>the library (as opposed to the language itself) is more a packaging
>>issue than a practical difference.
>
>There is a key difference. Library code is written entirely in the syntax
>and semantics of the host language. Therefore, if you know the syntax and
>semantics of the language, you are certain to be able to read any library
>code you come across. (This assumes that library code is available. I
>think that for IF systems that's a pretty safe bet.)
I think we're talking from different points of view. As a programmer I
don't care if a particular function is part of the library or a native
part of the compiler. What I care about is A) I have to learn to use
the function and B) how much hassle the function saves me.
For example, as far as I'm concerned the P() function (for instance)
is part of the TADS programming language. The fact that it's part of
the library and I can get to it if I need to is nice, but the point
is, as a programmer, I don't *want* to get to it. It's a nice black
box, it does what I want.
Making a library that's chock full of functions and classes is all
very well, but if those functions and classes and prebuilt objects are
complex, poorly documented, and/or a pain to use I'm not *going* to
use them. (And no, :) I'm *not* talking about WorldClass here!)
C and C++ are two of the worse offenders of the "put everything in the
library" school, while (for instance) PowerBuilder and Ada err in the
other direction. Both fall prey to the "information overload"
syndrome, albeit in opposite directions.
>For most features, it's pretty clear which pros and cons you care about.
>And I would say that the obvious conclusion is that you want to put as
>little as possible in the VM and compiler, and as much as possible in
>libraries.
I think I agree with you, as long as you can avoid the general Unix/C
philosophy of "widgets, widgets, everywhere. Can't have too many
widgets!"
>The only way I know of to make complex things comprehensible is to put
>*abstraction* to work...The same principle applies to computer programming. A good language
>encourages you to vigorously exploit abstraction...separate black-box tool that
> only needs to be debugged once.
>
>Abstraction, plain and simple.
Absolutely. You'll get no argument from me that abstraction is the
best defense against sheer code inundation. Howesomever, I propose we
take abstraction and meld it with a much more "human" style of
writing.
>>Today's computer systems are powerful enough to compile complex (but
>>intuitive) syntax in reasonable time.
>
>It's a matter of taste, but I don't think that more complex syntax will
>help; I think it will make it worse. Have you ever read an APL program?
>Even if you are a veteran programmer, unless you are specifically an *APL*
>programmer, APL programs look like line noise.
Ah, but I'm not talking about making the syntax more complex (in
terms of number of distinct symbols (as in APL)) I'm talking about
making the syntax more difficult for a *compiler* to decipher. In
other words, to remove much of the regimentation that eliminates
ambiguity.
Or, in other words, making syntax and context work together, just as
they do in human lanagues. Is such a compiler harder to write?
Abso-damn-lutely! Would it be easier to program in? You betcha!
> And the minimalist lisp
>syntax can reasonably naturally express all the things you'll invent
>special syntax to do. Once you know the lisp rules, you can read any lisp
>expression. There's never a new operator to learn, an ambiguity you can't
>mentally resolve, or operator precedences to internalize.
ACK! No, no, no, no!!! While I agree that lisp syntax is (in terms of
numbers of symbols) much easier than (for instance) C, the way lisp
expresses everything in terms of expressions and especially the prefix
notation drives me (and others I suspect) absolutely bug-eyed.
I programmed about 40% of TQ in ADVSYS back in 1983 when I first
discovered it. This included creating a library (since ADVSYS didn't
have one) so I'm quite familiar with "The land of infinite
parentheses".
I gave up eventually. Don't get me wrong, ADVSYS as a language has
many strong points. But ADVSYS (and TADS, to a lesser degree) share a
syntax that favors ease of compilation over readability. Lisp
languages (just like APL) share the dreaded "write-only" syndrome.
It's easy to *write* a program, but heaven help you if you have to
*read* it!
I mean, how intuitive is:
(if (not (= a b)) (+ a 1) (abort))
to the average IF writer? Remember, writing IF isn't supposed to be
about programming, it's supposed to be about writing.
Here's a more intuitive Basic version of the same line
IF a<>b THEN a=a+1 ELSE abort
Or, in TADS
if (a<>b) a++; else abort;
>>We need to break away from awkward (but easily parsed) syntax like C based
>>lanagues to more syntactically complex languages that either A) more
>>closely resemble English (Spanish, German, French....)
>
>They tried that. It's called COBOL. (OK, cheap shot...)
Hey, I had to learn COBOL back in college. Never used it since...
(Thank God!)
>>OR B) restrict themselves to the IF domain more naturally.
>
>I still do not see any concrete evidence that this would help anything.
>Can you give examples of what you think would be a better syntax (either
>domain-specific, or "closer to English")?
OK, let's take some TADS examples that I think are wonderfully
intuitive (and here you thought I was a TADS-basher!) :)
First, TADS handling of lists is marvelous. Adding an item to a list,
for instance:
list += obj;
is good. although (from a readability standpoint)
list := list + obj;
is better. And then
list -= obj;
to take an item out of a list. This is good, simple, elegent, the
syntax is the same as appending a string. It's *simple*, not just
concise.
Likewise, I love TADS "dot" operator, and the fact that it's infinitly
repeatable. For example
Me.location
is very obvious. And it's natural to extend it to:
Me.Location.lookaround(Me)
Because extending the dot operator is what a person using the language
would *expect*. It's intuitive.
I also love the ability to store ANYTHING in a property. You can store
code, an integer, true, false, whatever. This seamlessness is very
natural.
The object oriented nature of TADS in general is good, this is more
approach than syntax but the syntax springing from it is standardized
and very pervasive (and thus intuitive).
-------------------------------
Now, for some syntactic mistakes (in my opinion)
1) (TADS) The semi-colon on every line. This is compiler-sugar, it's
very annoying to have to put it there every time, and watch hundreds
of cascading errors if I forget one.
2) (TADS) Ending a definition of an object with a semi-colon (see
above). The compiler should understand the beginning of a new object
(or function or whatever) ends the previous one.
3) (Lisp et al) The fact you have to use parentheses for EVERYTHING!
<growl, snarl, jump-up-and-down>
4) (TADS) the use of curly braces as block markers. While concise,
proper white-space usage pretty much requires the curly brace appear
on a line by itself. This isn' t horrible, but can get just as messy
as Lisp style languages if deep nesting occurs.
5) (WorldClass) The fact that many functions (preinit() for instance),
are stream-coded. It makes them very hard to understand, especially
since TADS syntax is fairly difficult to *read* (as opposed to
decipher). It would have been easier to understand if (for instance)
each of the list building pieces of code had been encapsulated in
their own functions.
6) (TADS) The use of := instead of the more natural = for assignment.
Even using the C+ pragma and having to use == instead of = for
equality.
7) (TADS) The if/elseif combination is almost unreadable when
repeatedly extended. if/else should be limited to *1* if and else, any
more than 1 and a switch should be used instead.
8) (TADS) the FOR loop syntax is less than optimal, BASIC's FOR loop
structure is better.
----------------------------------------
Now, how would I design a language syntax assuming I had the skills to
write a compiler?
1) Absolutely keep data types as fluid as possible. TADS properties
are a wonderful example of this. ADVSYS has similar capabilities
(despite the fact everything was stored internally with 2 byte
integers).
2) No limits on sizes of internal lists.
3) No line delimiters (such as a semi-colon). The ending of a
function, object, statement or whatever is indicated by the beginning
of the next one or the end of the file. Basic and dBase follow this
idea.
4) Lessening the distinction between displayed text and program. TADS
format strings and << >> operators are examples of this. So are the
\n and \b codes.
5) Follow PowerBuilder's example of making "visual" objects. For those
who don't know PB, PB stores everything in a library, in ascii, but
the programmer seldom deals with the (incredibly convoluted) syntax
directly. Instead visual "editors" are used to manipulate the source
code. The ultimate abstraction!
6) Keep the number of basic syntax elements to a bare minimum. For
example, in ALAN you have lots of required clauses when creating an
object, and they must be in a specific sequence. This is bad, where
ever possible syntax should not require a specific order of arguments.
PB and Visual FoxPro's use of Named Arguments is a good example of
this. (Basically a named argument lets you pass only the absolute
minimum number of arguments to a function. You pass the *name* of the
argument as well as the value of the argument. This is handy when a
function might have 20 or 30 arguments!)
7) Inclusion of an editor/IDE that lets you selectively collapse your
code so that you're only looking at object/function names instead of
scrolling thru hundreds of pages of code. In other words, allow a way
to easily view the "big picture" so you don't have to juggle so much
code in your head at once.
8) (Aimed specifically at WorldClass) Create a library with the
minimum number of classes that fulfill the needs of most games, keep
the object interactions simple, and carefully document the interface
elements of the library in such a way that what can and can't be done
is obvious. Documentation should explain *why* to use a library
element as well as *what* it does and *how* to use it.
9) Documentation that avoids the need of sending a (presumably)
non-programmer scrambling through library source code to try and
figure out how to use the library.
-------------------------------
A long post! :) But to summarize let me say that I'm not all that
unhappy with TADS. The semi-colons have to go, the curly braces should
have some alternate block delimiters defined (begin/end maybe?). But
all in all *TADS* isn't the problem, so much as WorldClass/Adv.t.'s
complexities.
Respectfully,
Wolf
David Baggett
In article <ant282255313M+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>Secondly, the implication that a LISP-like language is incompatible
>with the Z-machine is wrong. Infocom's own language, ZIL, was
>essentially LISP [...]
I didn't actually mean to imply that. And for that matter, Andrew Plotkin
has recently given us rather compelling evidence that the Z-Machine is
compatible with lisp-like languages.
>[...] (and some Z-machine features reflect that: for instance the order in
>which opcodes are processed is designed to make a LISP syntax analyser's
>job easier). And I have to say, the bits of ZIL I've seen... have, well,
>let's call it "charm" if we're going to avoid accusations of bizarreness.
I think you're almost making my point for me here. You point out that the
Z-Machine is tailored to lisp-like languages (at least a little; Z-Machine
"properties" are certainly lisp-influenced) yet you wrote a compiler for a
decidedly un-lipsy language with the Z-Machine as target.
Then you speak of Zil's charm. Don't you think the same "charm" carries
over to Inform via the Z-Machine?
>The most frequent criticism of Inform has been that it has a steep learning
>curve. To someone who's never programmed before, ZIL (or LISP) would be a
>hard furrow to plough.
I'm not going to harp on this much more, because it's clear that some
people will agree with me and some people never will. But I think it's
important to make a distinction between the way in which Inform has a steep
learning curve and the way in which lisp has a steep learning curve.
Inform has a steep learning curve because the syntax and semantics are
non-orthogonal (i.e., fraughty with exceptions), needlessly complicated,
and in some cases confusing or unclear, particular when language primitives
are combined.
Lisp has a steep learning curve because the syntax is very minimalist (so
you have to learn how to read and write everything fully parenthesized).
It's also hard to learn for many people because it encourages a different
kind of programming idiom (extensive use of recursion, functional style, an
emphasis on abstraction, and "fancy" primitives like lambda, call/cc,
force/delay, catch/throw, map, etc.
All the things you've said in defense of Inform's langauge design could
equally well be said of TeX. (I hope we can at least agree that TeX is
pretty well near the bottom of the barrel when it comes to language
design.)
Lots of code is written in TeX, and most of it even works right. But that
doesn't mean that TeX is actually *good*. People are simply struggling
through its oddities, and consulting wizards for help as needed.
So that I'm not just unproductively grousing, here's an uncomprehensive
list of some things that I think are wrong with Inform, from a language
design standpoint. I will try to leave aside the design of the library,
even though Inform's design makes it hard, in some cases, to separate the
library from the language.
These are roughly in the order that the manual reveals them:
- 16-bit math only
- print is part of the language instead of a library routine, so
it has different syntax than a normal function call. Ditto for
quit, new_line, spaces, inversions, and others. Why not
print(...), quit(), new_line(), spaces(20), etc.?
- Unnecessarily "new" almost-C syntax: ^ for newline, : to separate
expressions in for loop, etc. At least C's \<char> is somewhat
general. If you are going to derive from C so heavily, why change
a few things here and there for no good reason? This will help
no one but will confuse the C programmers.
- (Unless I'm misreading this one:) Whitespace-dependence (variables
declared on first *line* of function)
- 32-character maximum on identifier names
- Silent defaulting of missing function args to zero is an evil
"convenience" that will surely lead to bugs.
- Operator insanity; example: "or", as in
if (x ~= 1 or 2 or 3) return;
Inform has *36* different operators. Only C++ goes further overboard.
- [ and ] along with { and }. Why? (Your defense of this is not
convincing.)
- No local variables within { and }; therefore scoping is limited
to a single routine. (No functions declared in functions, either.)
- More ad-hoc syntax: use of "to" to denote ranges in switch statements;
label names (targets of jumps) preceded by dot.
- Magic numbers: @@64 to get the "@" character instead of something
symbolic like "@at". Again, why are there *numerous* mechanisms
for the same task (escaping characters)?
- More magic numbers: string variables that must be accessed by
number (@00 to get string 0) and set with another special
reserved word: string 0 "string";
- rtrue reserved word: more pointless special syntax! Does it kill
you Inform wizards to type a handful of characters?!
- "..."; implicitly returns. This means that the more adorned
version print "..."; counter-intuitively does less than the
shorthand version.
- Printing rules like (char), (address), etc. Again, an entirely new
notation for representing what function call notation should handle.
- More unobvious syntax: --> vs -> in array declaration. Doubly bad
because it forces the programmer to keep track of something the
compiler outght to: the size of the elements in the array being
accessed. This means that changing an array from one type to
another requires the programmer to track down every instance
of (say) --> and replace it with ->.
- Length byte/word in a string/table is treated like every other
array entry, even though its meaning is totally different. (E.g.,
you can change it and screw up everything without warning.) It
is not obvious when you see "a-->0" in the source whether or
not that means "length of a" or just "0th element of a" unless
you know how a is defined. What's wrong with length(a), which
says what it means?
- More array nastiness:
Array Doubtful --> 50 10 -20 56;
is ambiguous, as the DM points out.
- More superfluous notation: object statements like move <object> to
<object> use new notation for what could equally well be written as
move(obj1, obj2).
- The containment hierarchy and the inheritance DAG are intertwined.
- object loop complicates the syntax further still by allowing
a condition inside the parens, as in
objectloop(x in Mailbox) print (name) x, "^";
This is a bad approximation of first-class functions, as in:
(objectloop (lambda (x)
(when (in? x Mailbox)
(print (name x) #\newline))))
The difference is that the Scheme version can apply any function
expressible in the language, whereas the Inform objectloop
can apply only a limited subset (the exact nature of which is
not at all obvious).
Furthermore, the programmer can define functions like objectloop
himself in Scheme. In Inform one is stuck with the hard-wired
version only.
The Inform restrictions lead to a preponderance of special
condition words like "provides," where Scheme subsumes this
within the normal, nothing-new-to-learn syntax.
- From the manual, about object properties which are arrays:
"This must be accessed using two special operators, .& and .#.
magpie.&name
means "the array which is held in magpie's name property", so that
the actual name values are in the entries
magpie.&name-->0
magpie.&name-->1
...
magpie.&name-->4
The size of this array can be discovered with
magpie.#name
which evaluates to the twice the number of entries, in this case,
to 10."
The sheer evil of this speaks for itself. Then, soon after, we
find:
"(... The rule here is anomalous and goes back to the misty origins of
Inform 1.) If you prefer a consistent style, using single quotes:
Object magpie "black-striped bird"
with name 'magpie' 'bird' 'black-striped' 'black' 'striped',
wingspan 5, worms_eaten;
works equally well (except that single-character names like "X" then
have to be written #n$X)."
Wait, was that #n$X, or did my modem just get a burst of line noise?
Say it ain't so!
- Why are object attributes given special status? Why can't this be
done with a general mechanism?
- A nasty complication thanks to the Z-Machine:
"The properties used in the chapter above are all examples of
'individual' properties. These are properties which any given object
might provide, or might not.
A small number of properties can be declared as "common"
properties, using the directive
Property <name>;
which declares that this name will always be a common property. Under
Inform 5.5 and earlier, these were the only properties available, so
that the Property directive is seen fairly frequently in older example
source code.
The only point in making such a declaration now is that common
properties are slightly faster in use and marginally cheaper in memory
terms than individual ones. So the library's properties are still
declared as common properties. There are about 30 common properties
left free for the use of programmers after the library has taken its
share."
So the language has two separate notions of "property" (the existence
of which is already a source of pointless non-orthogonality), one
with an ad hoc magic-number limit.
- Lots of random and only elusively documented limitations; e.g.,
only 236 global variables are allowed. This is not a hopeless limit,
but why is there a limit at all?
- "Causing an action and then returning true (i.e., causing a new
action and killing the old one) is so useful that it has an abbreviation,
putting the action in double angle-brackets. For example,
<Look>; <<ThrowAt smooth_stone spider>>;
will behave as if the player has asked to look around and to throw the
stone at the spider, and will then return true."
Oh no, *new* syntax! But wait:
"Its possible values can be referred to in the program using the ##
notation: for example
if (action == ##Look) ...
tests to see if the current action is a Look."
Ah, a new, unnecessary primitive and *three* new syntaxes for dealing
with said primitive. Aiieee! Graham defends himself thus:
"Why have ## at all, why not just write Look? Partly because this way
the reader can see at a glance that an action type is being referred to,
but also because the name might be wanted for something else. For
instance there's a variable called score (holding the current game
score), quite different from the action type ##Score."
Again I ask, why must actions be a totally separate concept, with
its own operators and mandatory lexical adornment? I have no trouble
representing this concept in Scheme, Smalltalk, ML, even C. Why
should it be assigned special status, such that one needs to read
another wordy manual chapter to understand what ##Look is supposed to
mean?
As a consequence of Inform's design, the Designer's Manual reads a lot like
the TeXbook -- there are so many exceptions, and the complexity of the
semantics is so mind-boggling, that one gets the feeling one is reading
about the mythology of some ancient people rather than a language
specification.
I do not want another vast lore to learn in order to program in a language.
I want a brief manual telling me what the primitives are, and then a
library of source code (hopefully adequately documented).
The Revised Report on Scheme describes the language down to the level of
formal BNF syntax and denotational semantics in *55 pages*, yet it provides
considerably more powerful primitives than Inform. Why is the Scheme
report so short? Because Scheme's design emphasizes orthogonality; i.e.,
most things apply generally, rather than with hundreds of unobvious
exceptions. This is good langauge design!
Inform has evolved into an incredibly complex language that provides only
simple mechanisms to solve problems. Contrast that with Scheme, which is
an incredibly simple language that provides powerful problem-solving tools.
Do you see why I am critical of Inform?
You can try to write it all off as personal preference, but I claim that
lots of special operators and syntax, reserved object semantics, and many
ad hoc restrictions and semantic variations make a language hard to learn
and hard to use.
Marnix Klooster
wo...@one.net (Roger Plowman) wrote:
> d...@lf.ai.mit.edu (David Baggett) wrote:
[snipped]
> >A language that lacks first-class functions tends to make the programmer
> >name *everything*. Hence the absurd number of important names in
> >WorldClass.
>
> I'm unfamiliar with the concept of a first-class function. Could you
> explain? I'm not sure I see how any function that's nameless could be
> useful. I'm not familiar with Scheme.
The key thing is that it is possible to pass functions as
arguments, and give functions as return values. This makes it
possible to create new functions by `glueing together' a number
of standard functions, thereby creating the desired
functionality.
Let me use Haskell as an example language, which is hopefully not
too difficult to understand. (In Haskell a function never has a
side effect.) Suppose you have a list of numbers, say [1,2,3].
It is not difficult to define a function that adds the numbers in
a list:
sum [] = 0 -- the sum of the empty list is 0
sum (x:xs) = x + sum xs -- the sum of x followed by list xs
-- is x plus the sum of xs
Then sum [1,2,3] evaluates to 6. Now assume that we want to
compute the product of a list. This can similarly be defined as
prod [] = 1
prod (x:xs) = x * prod xs
Notice the similarity? Both functions use the same recursion
pattern. This motivates the following utility function (never
mind its name):
foldr f z [] = z
foldr f z (x:xs) = x `f` foldr f z xs
(Here `f` converts the function f to an infix operator.) We can
now define sum and prod as follows:
sum xs = foldr (+) 0 xs
prod xs = foldr (*) 1 xs
(Here (+) converts the infix operator + to a function.) So, the
ability to pass a function to another function allows very
concise definitions. Essentially, it gives the programmer the
power to create her own control structures.
> I think we're talking from different points of view. As a programmer I
> don't care if a particular function is part of the library or a native
> part of the compiler. What I care about is A) I have to learn to use
> the function and B) how much hassle the function saves me.
>
> For example, as far as I'm concerned the P() function (for instance)
> is part of the TADS programming language. The fact that it's part of
> the library and I can get to it if I need to is nice, but the point
> is, as a programmer, I don't *want* to get to it. It's a nice black
> box, it does what I want.
But there inevitably comes a day when you, or someone else,
_will_ be concerned, since you want it to do somethiing else.
For example, what if you want to have P() print a line of dashes
to separate paragraphs? If P() was built into the language, this
wouldn't be possible. With libraries, this could be replaced.
As we've seen from Freefall, Robots, and Lists of Lists, there
are always people who try to push to the limits. Having a simple
language with all complexity in the libraries makes this
possible.
You can't separate you-the-programmer from you-the-library-
(re)designer. Inevitably you will have to modify or extend
existing functionality. Having all special features in libraries
certainly helps here.
> Making a library that's chock full of functions and classes is all
> very well, but if those functions and classes and prebuilt objects are
> complex, poorly documented, and/or a pain to use I'm not *going* to
> use them. (And no, :) I'm *not* talking about WorldClass here!)
Of course, designing a library is basically designing a language
extension. This means that the same criteria hold: a library
should be simple (as much as possible), well-documented, and easy
to use.
[on abstraction:]
> Absolutely. You'll get no argument from me that abstraction is the
> best defense against sheer code inundation. Howesomever, I propose we
> take abstraction and meld it with a much more "human" style of
> writing.
[snip]
> Or, in other words, making syntax and context work together, just as
> they do in human lanagues. Is such a compiler harder to write?
> Abso-damn-lutely! Would it be easier to program in? You betcha!
What would you consider `more human'? In my experience the
difficult thing in programming is learning to abstract, and
learning to be precise. Some people are good at this, others
aren't. Syntax helps, but making it too `human' makes people
assume the language (or its implementation) is more intelligent
than it really is.
> > And the minimalist lisp
> >syntax can reasonably naturally express all the things you'll invent
> >special syntax to do. Once you know the lisp rules, you can read any lisp
> >expression. There's never a new operator to learn, an ambiguity you can't
> >mentally resolve, or operator precedences to internalize.
>
> ACK! No, no, no, no!!! While I agree that lisp syntax is (in terms of
> numbers of symbols) much easier than (for instance) C, the way lisp
> expresses everything in terms of expressions and especially the prefix
> notation drives me (and others I suspect) absolutely bug-eyed.
I have to agree that Scheme's syntax, while consistent, is not
optimal for human use. Minimalist is not always best, especially
since we're talking about inexperienced programmers here. Humans
can adjust to almost any environment, I know -- but that doesn't
mean I'd want to. There are alternatives: allowing infix
operators, using indentation to indicate block structure, etc.
Have a look at the syntax of, e.g., Haskell
(http://carol.fwi.uva.nl/~jon/func.html), ABC (http://www.cwi.nl
under Research Projects), and Python (http://www.python.org).
[on syntax mistakes:]
> 6) (TADS) The use of := instead of the more natural = for assignment.
> Even using the C+ pragma and having to use == instead of = for
> equality.
Depends strongly on the background you come from. I certainly
find = confusing, even though := or <- is one more character to
type. Especially for people with a mathematical background,
x=x+1 looks like nonsense. Thus = is definitely not `more
natural.'
> 7) (TADS) The if/elseif combination is almost unreadable when
> repeatedly extended. if/else should be limited to *1* if and else, any
> more than 1 and a switch should be used instead.
Not true. Suppose I want to separate between the cases
(x=0,y=0), (x/=0,y=0), (x=0,y/=0), (x/=0,y/=0). How would you do
that readably with a switch? An if/elseif is much more general.
And why is this almost unreadable?
if (...) {
...
} elseif (...) {
...
} else {
...
}
(If TADS memory serves.)
> Now, how would I design a language syntax assuming I had the skills to
> write a compiler?
>
> 1) Absolutely keep data types as fluid as possible. TADS properties
> are a wonderful example of this. ADVSYS has similar capabilities
> (despite the fact everything was stored internally with 2 byte
> integers).
I'd be very grateful if you'd still manage to add in some
compile-time type checking. My experience is that it is easier
to program in a language which do almost all typechecking at
compile-time, because 80% of my programming errors are small
errors which are immediately detected by type checking.
> 2) No limits on sizes of internal lists.
Ditto for numbers and strings. Especially the former is _very_
non-intuitive for non-programmers.
> 3) No line delimiters (such as a semi-colon). The ending of a
> function, object, statement or whatever is indicated by the beginning
> of the next one or the end of the file. Basic and dBase follow this
> idea.
Look at ABC, Python, and Haskell which have indentation-based
block structure, which removes the need for line delimiters.
> 6) Keep the number of basic syntax elements to a bare minimum.
[snipped]
That's exactly what Lisp/Scheme does, and yet you don't seem to
like it! :-)
> Respectfully,
>
> Wolf
Magnus Olsson
In article <32c7979c...@news.worldonline.nl>,
Marnix Klooster <mar...@worldonline.nl> wrote:
>wo...@one.net (Roger Plowman) wrote:
>
>> d...@lf.ai.mit.edu (David Baggett) wrote:
>[snipped]
>> >A language that lacks first-class functions tends to make the programmer
>> >name *everything*. Hence the absurd number of important names in
>> >WorldClass.
>>
>> I'm unfamiliar with the concept of a first-class function. Could you
>> explain? I'm not sure I see how any function that's nameless could be
>> useful. I'm not familiar with Scheme.
>
>The key thing is that it is possible to pass functions as
>arguments, and give functions as return values.
Passing functions as arguments can be done in languages without
first-class functions, such as C. It can be quite cumbersome, though.
As for the usefulness of nameless functions (for clarity, I think we
should separate the concept of nameless functions from that of
first-class functions; they are not necessarilty the same): sometimes
they are useful, sometimes not. Consider an analogy with classes. TADS
has what you could call "nameless classes", since when you declare an
object, you can override inherited members and add new ones. You can
even inherit from the object, as if it were a class. In C++, you can't
do that: you must first create a new class, and then declare the object
as being of that class.
BTW, is a first-class function the same thing as a lambda form, or is
there some difference?
>[on syntax mistakes:]
>> 6) (TADS) The use of := instead of the more natural = for assignment.
>> Even using the C+ pragma and having to use == instead of = for
>> equality.
>
>Depends strongly on the background you come from. I certainly
>find = confusing, even though := or <- is one more character to
>type. Especially for people with a mathematical background,
>x=x+1 looks like nonsense. Thus = is definitely not `more
>natural.'
Agreed. If your background is in Pascal, you'll find TADS much
more "natural" than C. However, TADS has a big problem, and that is
that it mixes syntactic elements from C and Pascal. It's confusing to
have to use := for assignments when the language is so very much like C
in other aspects.
Also, remember that there is a reason to use different operators for
assignment and comparisons, viz. to make statements like a = b == c
unambiguous.
>> 7) (TADS) The if/elseif combination is almost unreadable when
>> repeatedly extended. if/else should be limited to *1* if and else, any
>> more than 1 and a switch should be used instead.
>
>Not true. Suppose I want to separate between the cases
>(x=0,y=0), (x/=0,y=0), (x=0,y/=0), (x/=0,y/=0). How would you do
>that readably with a switch? An if/elseif is much more general.
>
>And why is this almost unreadable?
>
> if (...) {
> ...
> } elseif (...) {
> ...
> } else {
> ...
> }
Shouldn't there be a space between "else" and "if"?
Also, how on earth would you desing a language so that the above
construction would be illegal? Remember, an if statement is a
statement like any other, so it is allowed to put an if after an
else...
IMNSHO, it's a hopeless task to make a language design that will make
it impossible to write unreadable code. The best we can hope for is a
language that allows us always to write readable code (far from all
existing languages do). But it's ultimately always up to the
programmer to exert the self-discipline needed to produce correct and
readable code. Which means: if you prefer switches to multiple if's,
then it's up to you to use switches.
>> Now, how would I design a language syntax assuming I had the skills to
>> write a compiler?
The following is probably going to sound very arrogant (So sue
me. I've already been branded a "snotty elitist") but, judging by your
remarks above, I'd strongly suggest that you (Roger, not Marnix) study
the theory and praxis of computer languages a little more in depth
before you even try to design one.
--
Magnus Olsson (m...@df.lth.se)
Graham Nelson
I am going to respond to Dave's post point-by-point, but there's a
danger that the result will look like a tug-of-war match, or for
that matter traditional Christmas pantomime. So here's my general
response to his views, first:
(a) Basically I don't agree with you, but I certainly don't
find your views in any way offensive or untenable.
(b) Inform is a large language, and in an ideal world I would
like to remove some of the peripheral syntaxes (anybody
fancy an update called Inform-- ?). This is not an excuse
for poor performance. But it might be remembered that
I am not free to redesign the language: large quantities
of source code must continue to work. As it is, some of
the clutter around the edges consists of features still
supported for the sake of old code, but no longer
recommended.
(c) I concede that the Z-machine specification imposes a number
of minor restrictions: I merely think the gains outweigh
the losses.
(d) I do not accept that a "large" language is necessarily
simplistic, nor that Inform is necessarily simplistic.
I do accept that a large language is usually less elegant
than a small one in computing. But Inform is designed
for IF, not for general computing. The complexity of
Inform language+library is quite high, but this is because
it provides solutions to a very complex problem. In
particular, I do not think you have proved the claim that
Inform is "an incredibly complex language that provides only
simple mechanisms to solve problems". I would say that
Inform is a large system aimed at the pragmatic and
difficult problem of modelling a physical world through
text. For instance, the Inform parser is much more complex
than the TADS one in terms of how it can be programmed.
But this is why it's better than the TADS one, in my view.
[Please, nobody take this as a sweeping claim that Inform
is better than TADS!]
(e) Something like half of the syntaxes which you deplore
are felt by others (well, me, anyway) to be elegant
and convenient. (Of the others, I concede below that
a few are plain wrong; most of the rest are justifiable
and harmless.) My mail folders are full of requests to
add new ones (especially new operators, incidentally).
(f) The comparison of Inform with TeX is, I think, apt.
Your comments on the manifest badness of TeX are more
questionable. Yes, TeX is a wretched programming language
aesthetically, but it is a tremendously useful tool in
practice, and has benefited a whole generation of
scientists. (I don't think Inform is anything like as
difficult to reach the bottom of, by the way.) TeX
is a tool for typesetting mathematics, not a programming
language for AI research. Inform is a tool for
typesetting interactive fiction, not a programming
language for AI research.
Well. Here goes, then! I omit the discussion about LISP-like
languages versus C-like ones, as I think David and I have each
given our views already.
In article <5a748r$i...@life.ai.mit.edu>, David Baggett
<URL:mailto:d...@lf.ai.mit.edu> wrote:
> So that I'm not just unproductively grousing, here's an uncomprehensive
> list of some things that I think are wrong with Inform, from a language
> design standpoint. I will try to leave aside the design of the library,
> even though Inform's design makes it hard, in some cases, to separate the
> library from the language.
Fair enough. (The closeness of library with language is intentional,
and reflects the extent to which Inform is aimed at one and only one
task: interactive fiction. It would be inappropriate if Inform were
being advanced as a general programming language.)
> These are roughly in the order that the manual reveals them:
>
> - 16-bit math only
Indeed. It's a shame, but this is one of the Z-machine restrictions.
Ideally I would prefer a 32-bit word size used as in the SmallTalk
byte machine: i.e., to hold numbers or object identifiers. It's seldom
a problem with IF, and one can usually get around it: "Jigsaw"
calculates inverse tangents of floating-point numbers in one of
its puzzles.
> - print is part of the language instead of a library routine, so
> it has different syntax than a normal function call. Ditto for
> quit, new_line, spaces, inversions, and others. Why not
> print(...), quit(), new_line(), spaces(20), etc.?
"print" is far more powerful than it could be with a function
call syntax (because of, for instance, printing rules), and it's
important to evaluate printees (is there such a word?) in
sequence. Besides, it's used incessantly in a text-based milieu.
Brackets are an extra redundancy to type.
"quit", "new_line" and "spaces" all ought to be functions, yes,
or better yet removed altogether. But they're easy enough to
remember if one wants to, and it doesn't matter if one doesn't
remember them. Nobody needs to use "quit" at all. (There are
about six statements I'd remove given a free hand to do so.)
> - Unnecessarily "new" almost-C syntax: ^ for newline, : to separate
> expressions in for loop, etc. At least C's \<char> is somewhat
> general. If you are going to derive from C so heavily, why change
> a few things here and there for no good reason? This will help
> no one but will confuse the C programmers.
Actually, Inform allows ; dividers in "for" loops as an
alternative to : ones. (The essential reason behind the choice
of : is that I didn't like a syntax which allowed the ; character
to occur, unquoted, inside a statement and yet not mark the end
of that statement.) But I can see this has annoyed a few people,
and for that I'm sorry.
I disagree that ^ and ~ are a bad idea. They have the virtue of
being quick and easy to use, and take only one character (usefully
when laying out tables of text). They are needed exceptionally
frequently. "\"Hello\"" is, I think, less clear than "~Hello~".
In the Inform version, you can at least see where the string starts
and ends.
Relatively few Inform users seem to be habitual C programmers,
incidentally, if my mailbag is anything to go by.
> - (Unless I'm misreading this one:) Whitespace-dependence (variables
> declared on first *line* of function)
You're misreading this one. White space is always contracted, as in
almost all languages. (I did once see a language in which unnecessary
white space indicated "the rest of this line is a comment"...)
> - 32-character maximum on identifier names
As in ANSI C and many, many other languages. There are obvious,
if minor, benefits in terms of efficiency and robustness of the
lexical analysis code in the compiler and linker. Until now, nobody
has ever complained to me that 32 is too little. When someone
plausibly does, perhaps I'll up it to 64.
> - Silent defaulting of missing function args to zero is an evil
> "convenience" that will surely lead to bugs.
In my experience, it has seldom done so in the past. But I concede
that this convenience is double-edged and that the language is
not ideally helpful in making programmers aware of the potential
for problems.
> - Operator insanity; example: "or", as in
>
> if (x ~= 1 or 2 or 3) return;
"or" is one of the features I am most proud of, actually. IF code
is absolutely full of selections and comparisons, along the lines of
if (location == Y2_Rock_Room or Hall_Of_Mists or Soft_Room)
...
Do we really think that
if (location == Y2_Rock_Room
|| location == Hall_Of_Mists
|| location == Soft_Room)
...
is intrinsically saner? I've written code with something like 20
alternatives before... Besides which, what about
if (MoveDwarfTo()
== Y2_Rock_Room or Hall_Of_Mists or Soft_Room)
...
where the alternative would be
x = MoveDwarfTo();
if (x == Y2_Rock_Room || x == Hall_Of_Mists || x == Soft_Room) ...
a quite unnecessary use of a variable. "or" is one of the best
shorthand forms in Inform, though I agree that some people would
prefer to abolish shorthands altogether.
> Inform has *36* different operators. Only C++ goes further overboard.
(Java and other C-like languages are similar.) Which would you
like withdrawn? The bitwise arithmetic operators, perhaps? The
textual ones, such as "has" or "ofclass"?
> - [ and ] along with { and }. Why? (Your defense of this is not
> convincing.)
The literal answer to "Why?" is that it's a historical accident,
and therefore indefensible. On the other hand, it does no especial
harm (in my view) and makes brace mismatch errors slightly easier
to recover from. Still, I concede this one.
> - No local variables within { and }; therefore scoping is limited
> to a single routine. (No functions declared in functions, either.)
True. I repeat that Inform is not a general-purpose programming
language.
> - More ad-hoc syntax: use of "to" to denote ranges in switch statements;
> label names (targets of jumps) preceded by dot.
In some sense all invented syntax is ad-hoc. "to" denoting ranges
may be found in Ada, for example, though I somehow imagine you
wouldn't be a fan of Ada. Label names are often preceded by dots
in assembly languages.
> - Magic numbers: @@64 to get the "@" character instead of something
> symbolic like "@at". Again, why are there *numerous* mechanisms
> for the same task (escaping characters)?
The magic trick in question is better known as ASCII, and I fear
its Eleusian mysteries may have got out by now. Yes, there are
four characters best written as @@ plus a numerical code: they
aren't terribly often needed (_unlike_ newline or double-quote)
but can be found in charts of how to type accented and other
oddball characters.
"@at" is quite a nice idea, but then one would want things like
"@backslash" -- or maybe "@ba" -- or "@bs" -- or... and so on.
So, tempted as I am...
As to *numerous* mechanisms, the *number* in question is something
like 4, and most users never need to use 2 of those. (Java also
has 4, by my count.)
> - More magic numbers: string variables that must be accessed by
> number (@00 to get string 0) and set with another special
> reserved word: string 0 "string";
This allows access to a rather recondite feature of the Z-machine,
which one practically never needs access to. In that sense, perhaps
it should be deleted from the language. But I think it does no
harm and in a very few cases it does a lot of good. It's a feature
that is barely mentioned in the manuals.
> - rtrue reserved word: more pointless special syntax! Does it kill
> you Inform wizards to type a handful of characters?!
...over, and over, and over again... Shorthand forms make Inform
usefully concise, and you don't have to use them if you don't want to.
> - "..."; implicitly returns. This means that the more adorned
> version print "..."; counter-intuitively does less than the
> shorthand version.
This is an unusual feature of Inform and is one of the few counter-
intuitive things that newcomers have to get to grips with. To help
them, the compiler tries hard to spot code which has forgotten about
the returning.
Why have it? Again, it's a shorthand form, but it's a very useful
shorthand form. It enables "before" rules for objects to take
convenient forms like
before
[; Eat: "Your stomach turns at the prospect.";
Take: "It's too slimy to get a grip on.";
];
A fuller syntax would explicate that what's happening here is that
a message is being received and replied to, but the above is quicker
to write, easier to remember and easier to read.
> - Printing rules like (char), (address), etc. Again, an entirely new
> notation for representing what function call notation should handle.
Not quite true: neither "(char)" nor "(address)" cause function calls,
as it happens. However I accept the point that this is an alternative
form of function call in many cases. My defence, predictably, is that
it's useful and easy to understand. As ever, you don't need to use
it if you don't want to, but many people do find
if (still_befuddled)
"The ", (Spell) noun, " misfires badly!";
more convenient than
if (still_befuddled)
{ print "The "; Spell(noun); " misfires badly!"; }
> - More unobvious syntax: --> vs -> in array declaration. Doubly bad
> because it forces the programmer to keep track of something the
> compiler outght to: the size of the elements in the array being
> accessed. This means that changing an array from one type to
> another requires the programmer to track down every instance
> of (say) --> and replace it with ->.
Yes, I sympathise with this view. However, in a typeless language
which needs both char and int arrays, there is little alternative.
(Actually, in some involved cases it's useful to access an array
using both operators.) In practice (as the manual stresses) ->
arrays are used only when the entries are single characters,
and it is very rarely that one needs to change an existing array
from one to the other.
> - Length byte/word in a string/table is treated like every other
> array entry, even though its meaning is totally different. (E.g.,
> you can change it and screw up everything without warning.) It
> is not obvious when you see "a-->0" in the source whether or
> not that means "length of a" or just "0th element of a" unless
> you know how a is defined. What's wrong with length(a), which
> says what it means?
This is a Z-machine quirk. I agree that it's not ideal. Having a
"length" function is quite a good idea, though I don't want to have
to go compiling inefficient code to adjust array indices for such
arrays and, once again, since the language is typeless it would be
difficult to syntax-check usage of "length".
> - More array nastiness:
>
> Array Doubtful --> 50 10 -20 56;
>
> is ambiguous, as the DM points out.
Yes, this was a mistake on my part, which I have entirely owned up
to. The compiler issues warnings in all ambiguous cases. In the
mean time, the absence of commas makes arrays pleasingly concise
to set up, which is some benefit.
> - More superfluous notation: object statements like move <object> to
> <object> use new notation for what could equally well be written as
> move(obj1, obj2).
Once again, I happen to think
move lantern to Y2_Rock_Room;
is a useful syntax, especially for beginners. I concede that several
less-used statements might better be built-in functions (certainly not
called functions: that would be inefficient) but not this one.
> - The containment hierarchy and the inheritance DAG are intertwined.
Inheritance is relevant to classes, which do not belong to the
containment hierarchy. (Well, their class-objects do, but that's
an implementation issue.) I can't see there is an issue here.
> - object loop complicates the syntax further still by allowing
> a condition inside the parens, as in
>
> objectloop(x in Mailbox) print (name) x, "^";
>
> This is a bad approximation of first-class functions, as in:
>
> (objectloop (lambda (x)
> (when (in? x Mailbox)
> (print (name x) #\newline))))
I wonder which I'd rather teach to a group of newcomers to
programming? "So you want to print the contents of the mailbox...
well, OK, so first a little lambda-calculus..."
Cheap shot, though, since as you rightly say, the point about
Scheme is that once one is over the first high hurdles, the going
is much easier than first appears. Nevertheless, the Inform
"objectloop" construct is handy and legible:
objectloop (x) (all objects)
objectloop (x in Mailbox)
objectloop (x ofclass Coin)
objectloop (x has door && x hasnt open)
If you want a condition which isn't so straightforward, you can
always use something like
objectloop (x && MyWierdDecisionProcess(x))
or for that matter
objectloop (x)
if (... anything you like...)
...
> The difference is that the Scheme version can apply any function
> expressible in the language, whereas the Inform objectloop
> can apply only a limited subset (the exact nature of which is
> not at all obvious).
As demonstrated above, this is not true. I agree that Inform does
not support lambda-calculus. I think looping over the contents of
a mailbox is more what the average IF designer has in mind.
> Furthermore, the programmer can define functions like objectloop
> himself in Scheme. In Inform one is stuck with the hard-wired
> version only.
Yes, I agree. Here Scheme has the advantage.
> The Inform restrictions lead to a preponderance of special
> condition words like "provides," where Scheme subsumes this
> within the normal, nothing-new-to-learn syntax.
There are 6 such conditions, yes. They all test fundamental
states of affairs, intrinsic to the language. They would have
to be built into Inform even if it were Scheme-like. For the record,
they are
has hasnt in notin ofclass provides
and although it could be argued that "hasnt" and "notin" aren't
necessary, once again they're good shorthands.
> - From the manual, about object properties which are arrays:
>
> "This must be accessed using two special operators, .& and .#.
>
> magpie.&name
>
> means "the array which is held in magpie's name property", so that
> the actual name values are in the entries
>
> magpie.&name-->0
> magpie.&name-->1
> ...
> magpie.&name-->4
>
> The size of this array can be discovered with
>
> magpie.#name
>
> which evaluates to the twice the number of entries, in this case,
> to 10."
>
> The sheer evil of this speaks for itself.
Yes, it does, doesn't it? Fortunately few people use arrays as
property values. (There are Z-machine reasons.)
> Then, soon after, we
> find:
>
> "(... The rule here is anomalous and goes back to the misty origins of
> Inform 1.) If you prefer a consistent style, using single quotes:
>
> Object magpie "black-striped bird"
> with name 'magpie' 'bird' 'black-striped' 'black' 'striped',
> wingspan 5, worms_eaten;
>
> works equally well (except that single-character names like "X" then
> have to be written #n$X)."
>
> Wait, was that #n$X, or did my modem just get a burst of line noise?
> Say it ain't so!
Now you're really prosecutin'. I consider this much the worst state
of affairs in the Inform language, and deserve blame for it. I would
dearly like to reform it, but as ever the presence of old code is
inhibiting.
> - Why are object attributes given special status? Why can't this be
> done with a general mechanism?
It's quick, easy, convenient and rapidly implemented. On the whole
if I were designing a "mini-Inform language" I might well take out
attributes and then reintroduce them as boolean properties, yes.
(In practice, in a quite sneaky way, attributes tend to be used as
if class inheritance were being shuffled about at run-time.)
> - A nasty complication thanks to the Z-Machine:
>
> "The properties used in the chapter above are all examples of
> 'individual' properties. These are properties which any given object
> might provide, or might not.
>
> A small number of properties can be declared as "common"
> properties, using the directive
>
> Property <name>;
>
> which declares that this name will always be a common property. Under
> Inform 5.5 and earlier, these were the only properties available, so
> that the Property directive is seen fairly frequently in older example
> source code.
>
> The only point in making such a declaration now is that common
> properties are slightly faster in use and marginally cheaper in memory
> terms than individual ones. So the library's properties are still
> declared as common properties. There are about 30 common properties
> left free for the use of programmers after the library has taken its
> share."
>
> So the language has two separate notions of "property" (the existence
> of which is already a source of pointless non-orthogonality), one
> with an ad hoc magic-number limit.
No, I really am not going to beat my breast over this one. It's an
implementation matter, really. You just don't need to use "Property":
it's hardly mentioned in the manuals any more. I think the parallel
is with C, where some variables can be flagged as "register" to ask
the compiler to compile code using them more efficiently. Of course,
there is necessarily a magic-number limit to the number of registers
in the machine. In Inform 6, "Property" is a directive used by the
library to improve the efficiency of code, that's all.
> - Lots of random and only elusively documented limitations; e.g.,
> only 236 global variables are allowed. This is not a hopeless limit,
> but why is there a limit at all?
"Lots", and "elusively documented": hmm. There is a chapter on "limits"
in the Designer's Manual, which some might think the obvious place to
look.
They're not wholly random, and as you say not in practice constraining,
and I would say there are "a few" rather than "lots", but I agree that
in an ideal world everything would be unlimited subject to (say) the
size of the output game file. (I can think of, oh, I think five
such magic limits, none ever reached in practice.)
> - "Causing an action and then returning true (i.e., causing a new
> action and killing the old one) is so useful that it has an abbreviation,
> putting the action in double angle-brackets. For example,
>
> <Look>; <<ThrowAt smooth_stone spider>>;
>
> will behave as if the player has asked to look around and to throw the
> stone at the spider, and will then return true."
>
> Oh no, *new* syntax!
Oh no, *extra* functionality!
> But wait:
>
> "Its possible values can be referred to in the program using the ##
> notation: for example
>
> if (action == ##Look) ...
>
> tests to see if the current action is a Look."
>
> Ah, a new, unnecessary primitive and *three* new syntaxes for dealing
> with said primitive. Aiieee! Graham defends himself thus:
>
> "Why have ## at all, why not just write Look? Partly because this way
> the reader can see at a glance that an action type is being referred to,
> but also because the name might be wanted for something else. For
> instance there's a variable called score (holding the current game
> score), quite different from the action type ##Score."
>
> Again I ask, why must actions be a totally separate concept, with
> its own operators and mandatory lexical adornment? I have no trouble
> representing this concept in Scheme, Smalltalk, ML, even C. Why
> should it be assigned special status, such that one needs to read
> another wordy manual chapter to understand what ##Look is supposed to
> mean?
It is not a priori necessary for actions to have a different name-space
to other symbols. I have an open mind on whether the language is
better that way or not. However, the < > and << >> notations are
(as I keep saying) convenient and legible.
> As a consequence of Inform's design, the Designer's Manual reads a lot like
> the TeXbook -- there are so many exceptions, and the complexity of the
> semantics is so mind-boggling, that one gets the feeling one is reading
> about the mythology of some ancient people rather than a language
> specification.
The DM is in some ways modelled on the TeXbook. In particular, it
is fastidious to include everything you could _ever_ want to know,
much of which is tucked away in smaller type and marked-off passages.
Some find it prolix and annoying, others find it to the point and
annoying. (Actually, a few people like it.) The vast bulk of the
book is given over to features of the library and to examples
(which make up, oh, 20% of the book at least). The language itself
is described in a section of similar length to that of the Revised
Report on Scheme, aimed at total newcomers to computer programming,
which I somehow doubt the Revised Report on Scheme is.
Anyway, by all means dislike the manual too, but it isn't the same
as the language!
> Why is the Scheme
> report so short? Because Scheme's design emphasizes orthogonality; i.e.,
> most things apply generally, rather than with hundreds of unobvious
> exceptions. This is good language design!
I do not say that Scheme is a bad language, of course. I say
only that there are horses for courses, and that in the Interactive
Fiction Handicap, Inform might get rather better odds than Scheme.
Perhaps I might conclude by pointing out that the much-reviled
Z-machine does offer a safe and dependable memory environment.
I am politely skeptical that a Scheme-like system can assure
good-quality garbage collection across a variety of platforms,
and can therefore be relied on as a robust environment.
Matthew T. Russotto
In article <32C6D619...@alcyone.com>,
Erik Max Francis <m...@alcyone.com> wrote:
}Graham Nelson wrote:
}
}> I have very occasionally
}> wondered if an option for "output as ANSI C" would be worth the
}> trouble. But I don't think it would add any new portability
}> (quite the reverse, actually).
}
}This sounds like a great idea. Not only would it be powerful, but it would
}also be fairly straightforward.
}
}> As for Java, surely better to wait for the completion of the
}> Java Z-machine interpreter?
}
}I've already seen at least one: Zplet.
It's a bit buggy and not the greatest performing interpreter in the
world (mainly because I've been neglecting it). And of course it
doesn't save and restore (one of these days I'll get around to it).
The performance issue probably requires some Java VM help --
Metrowerks Java on the Mac actually runs it at acceptable speeds,
whereas the Sun VM does not.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Dan Shiovitz
In article <32c6d623...@news.one.net>,
Roger Plowman <wo...@one.net> wrote:
>d...@lf.ai.mit.edu (David Baggett) wrote:
[..]
>>I think the sense-reach strategy is basically the right one.
>
>Well, you could be right. You may also be indulging in massive
>overkill, however. :)
>
>Consider, there are 4 basic scenarios.
>
>1) An object is making a loud and absolutely overwhelming noise, for
>example a radio blaring at full volume. This isn't something the
>2) An object is making a subtle noise, for example the fan on a
>3) The player's *location* is making an overwhelming noise. For
>4) The player's location is making a subtle noise (for example, wind
>Instead of the "cansee/smell/hear/touch/taste" functionality, what
>about sensory thresholds coupled with simple descriptions? For
>example, say the actor has a sound threshold of 60 normally. Any sound
>of 60 or greater automatically lists itself, any sound of 59 or less
>won't be apparent until the actor actively lowers his threshold with a
>"listen" or "listen to" command.
These are easy scenarios to handle, agreed, but I think you're missing the
point. How would a simple threshold system like what you're proposing
handle the case of a blaring radio inside an open box in the middle of
the room? You're always going to have to chart sense paths, as far as
I can tell. I don't know if WC does it the best way, but I think it's
doing it the right way.
[..]
>>A language that lacks first-class functions tends to make the programmer
>>name *everything*. Hence the absurd number of important names in
>>WorldClass.
>
>I'm unfamiliar with the concept of a first-class function. Could you
>explain? I'm not sure I see how any function that's nameless could be
>useful. I'm not familiar with Scheme.
The way I always had it explained was that a language with first-class
functions lets them be used anywhere any other sort of variable can be
used. The reason why nameless functions are useful is the same reason
why being able to use a '3' in a function without declaring it at the
start is useful. You just want something with the value 3, you don't
want to refer to it later, you need it to do its job and then vanish.
Nameless functions do this exactly.
>Wolf
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more
sensible people ... remember to speak up for freedom because no one else
will do it for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Roger Plowman
m...@bartlet.df.lth.se (Magnus Olsson) wrote:
>BTW, is a first-class function the same thing as a lambda form, or is
>there some difference?
You got me. :)
>Agreed. If your background is in Pascal, you'll find TADS much
>more "natural" than C. However, TADS has a big problem, and that is
>that it mixes syntactic elements from C and Pascal. It's confusing to
>have to use := for assignments when the language is so very much like C
>in other aspects.
Several people have made this point, however I'm more concerned that
there are two separate syntatic elements for assignment and equality
testing than I am what those syntaxes are.
Most people (like it or hate it) start with some variety of Basic, and
since Basic makes no distinction between assignment and equality
operators it's my opinion an IF language (generally intended for
non-programmers) shouldn't either.
>Also, remember that there is a reason to use different operators for
>assignment and comparisons, viz. to make statements like a = b == c
>unambiguous.
In a language like xBase or Basic you can achieve the same effect
with:
a = (b = c)
although using such an expression is somewhat cryptic anyway, you're
basically storing a true/false value in a variable, probably for use
in several tests later. This might be done for speed optimization, but
I'd bet the majority of people using such constructs are writing speed
critical pieces of an OS or maybe a compiler. IF programmers don't
generally need to cram every CPU cycle, and I'd argue that
readability, not CPU cycle conservation is more important.
Which brings up a general point. In languages that use the same
operator for assignment and equality, generally the context of usage
makes the difference between them clear. Assignments happen on their
own line, equality checking is generally done only for IF tests, loop
tests, and the like.
In languages like C, where the freedom exists to put an assignment
into an equality test (which always struck me as confusing code) you
really do need different operators.
However, this argument has been brought to bear on nearly every aspect
of programming, such as naming standards for variables, naming
standards for sub-routines, etc, etc.
There has always been a holy war between the readibility folk and the
code-brevity folk, and probably always will be. Just picture an APL
programmer locked in the same room as a COBOL programmer...
>IMNSHO, it's a hopeless task to make a language design that will make
>it impossible to write unreadable code. The best we can hope for is a
>language that allows us always to write readable code (far from all
>existing languages do). But it's ultimately always up to the
>programmer to exert the self-discipline needed to produce correct and
>readable code. Which means: if you prefer switches to multiple if's,
>then it's up to you to use switches.
Ok, I'll give you that. :) On the subject of switches, there are a
number of ways to design switches (or CHOOSE or SELECT CASE or
whatever).
The C-style switch has its uses but it's fairly cumbersome because you
have to break after every case, even though that's normally what you
want to have happen anyway.
xBase's version is nice, you can put a different test on every case if
you want, and the cases don't require a break after each one.
>The following is probably going to sound very arrogant (So sue
>me. I've already been branded a "snotty elitist") but, judging by your
>remarks above, I'd strongly suggest that you (Roger, not Marnix) study
>the theory and praxis of computer languages a little more in depth
>before you even try to design one.
You're right, it does. :)
Designing compilers is a discipline all its own, just as writing
operating systems, or CAD systems, or whatever. But having learned
over 50 or more languages in the course of my career, ranging from
FORTRAN (my first) to Basic, to RPG II, COBOL, C, Pascal, xBase, Basic
dialects (two dozen at least!), Lisp, Pilot, and a bunch dreamed up by
IBM mini-computer wanna-be's, I think I've grasped the fundamentals of
what works in a language and what doesn't.
Designing a *language* (as opposed to a compiler) is a whole 'nother
kettle of fish. That requires a feel for what works and what doesn't.
That, at least, I do know. :)
Of course, like any programmer, I've developed strong preferences for
certain programming styles, and learned to loathe others. (Personally
I prefer sequential programming with functions named in plain language
to act as language extentions, hiding all the nasty looping and
testing details.)
Guess you can spot I'm from the readability school, hmm? :)
Respectfully,
Wolf
Magnus Olsson
wo...@one.net wrote:
>m...@bartlet.df.lth.se (Magnus Olsson) wrote:
>>Agreed. If your background is in Pascal, you'll find TADS much
>>more "natural" than C. However, TADS has a big problem, and that is
>>that it mixes syntactic elements from C and Pascal. It's confusing to
>>have to use := for assignments when the language is so very much like C
>>in other aspects.
>
>Several people have made this point, however I'm more concerned that
>there are two separate syntatic elements for assignment and equality
>testing than I am what those syntaxes are.
But the fact is that in a C-like language, it is *necessary* to have
two different operators. See below.
>Most people (like it or hate it) start with some variety of Basic,
I'm not quite sure of that anymore. But I really have no idea of what
is the most common beginner's language nowadays.
>since Basic makes no distinction between assignment and equality
>operators it's my opinion an IF language (generally intended for
>non-programmers) shouldn't either.
There's no reason an IF language should be modelled on Basic either,
especially if it's aimed at non-programmers who may have no experience
of Basic or any other language.
One of the greatest shortcomings of TADS, BTW, is that it requires
some prior knowledge of C. The Inform language is almost as C-like,
but at least the Inform manual tries to explain the basic constructs
to the beginner.
>>Also, remember that there is a reason to use different operators for
>>assignment and comparisons, viz. to make statements like a = b == c
>>unambiguous.
>
>In a language like xBase or Basic you can achieve the same effect
>with:
>
>a = (b = c)
>
>although using such an expression is somewhat cryptic anyway, you're
>basically storing a true/false value in a variable, probably for use
>in several tests later. This might be done for speed optimization, but
>I'd bet the majority of people using such constructs are writing speed
>critical pieces of an OS or maybe a compiler. IF programmers don't
>generally need to cram every CPU cycle, and I'd argue that
>readability, not CPU cycle conservation is more important.
Storing logical values in variables has *nothing whatsoever* to do
with optimization. A common situation in IF programming is that you
have flags that tell whether a certain object has some property or
whether it hasn't. For a combination lock, for example, we may have a
logical (Boolean) property called "open" which is true if you gave the
right combination and false if you gave the wrong combination. If I
were to write an adventure in Basic, it would be extremely natural for
me to have some code like
INPUT "Enter the combination: ", comb
open = (comb = correct_comb)
Of course, I could replace the assignment with an if statement. I know
that many people prefer that style; to me, however, it seems slightly
strange - after all, we don't write
IF a = 0 THEN
b = 1
ELSIF a = 1 THEN
b = 2
ELSIF a = 2 THEN
b = 3
ELSIF...
when a simple
b = a + 1
would suffice, do we? :-)
Actually, I suspects it's a matter of what a comparison "really is".
To many programmers, a comparison is something you put inside an if
statement (Inform was like that until recently). There is also the
more "mathematical" view that a comparison operator is an operator
that returns a Boolean value (true or false), and that Boolean values
can be manipulated, stored in variables, returned from functions, etc.
In C, there is no fundamental difference between the == and +
operators, for example.
>Which brings up a general point. In languages that use the same
>operator for assignment and equality, generally the context of usage
>makes the difference between them clear. Assignments happen on their
>own line, equality checking is generally done only for IF tests, loop
>tests, and the like.
Actually, it's not so much a matter of usage as a matter of the
semantics of the assignment operator. See below.
>In languages like C, where the freedom exists to put an assignment
>into an equality test (which always struck me as confusing code) you
>really do need different operators.
It's not just that you're free to put an assignment inside an equality
test, it's that in C, and in Algol (but not in Pascal, for some
reason), the assignment operator actually has a return value. So
you're allowed to write things like
a = ((a == b) > (a != b) + 1);
(not that it's very useful).
For the benefit of those who haven't seen the reason for having two
different operators in C,
a = b = c;
means the same thing as
b = c; a = b;
which is something very different from
a = b == c;
which is the same thing as
if (b == c) a = 1; else a = 0;
and there is no way of distinguishing those two statements unless the
= and == operators have different names.
Of course, you might question whether it's a good idea to have the
assignment operator return a value; obviously Wirth doesn't think so,
since the feature is missing from Pascal. IIRC, TADS has it, though,
which makes it necessary to have two different operators.
>However, this argument has been brought to bear on nearly every aspect
>of programming, such as naming standards for variables, naming
>standards for sub-routines, etc, etc.
>
>There has always been a holy war between the readibility folk and the
>code-brevity folk, and probably always will be. Just picture an APL
>programmer locked in the same room as a COBOL programmer...
An important point that is often missed is that there are other issues
at stake as well: power of expression, flexibility, extensibility,
orthogonality... People tend to get all worked up on the issue of C's
brevity and/or unreadability, missing the more important questions.
>>The following is probably going to sound very arrogant (So sue
>>me. I've already been branded a "snotty elitist") but, judging by your
>>remarks above, I'd strongly suggest that you (Roger, not Marnix) study
>>the theory and praxis of computer languages a little more in depth
>>before you even try to design one.
>
>You're right, it does. :)
I'm sorry for being so rude. I don't really know what got into me.
>Designing compilers is a discipline all its own, just as writing
>operating systems, or CAD systems, or whatever. But having learned
>over 50 or more languages in the course of my career, ranging from
>FORTRAN (my first) to Basic, to RPG II, COBOL, C, Pascal, xBase, Basic
>dialects (two dozen at least!), Lisp, Pilot, and a bunch dreamed up by
>IBM mini-computer wanna-be's, I think I've grasped the fundamentals of
>what works in a language and what doesn't.
I've no doubt you have. I retract my remark about the practice of
computer languages.
>Designing a *language* (as opposed to a compiler) is a whole 'nother
>kettle of fish. That requires a feel for what works and what doesn't.
>That, at least, I do know. :)
That is certainly a requirement, and you've convinced me that you do
know that.
But, as David Baggett has already pointed out, designing a good
language also requires good knowledge of how a compiler works, and
what it can do and can't do efficiently. That doesn't mean that all
language desingers should be able to write a professional-class
compiler, but I think they should at least have the knowledge to write
a working implementation of the language.
A theoretical background is also necessary. Theory provides the
framework that makes the language work as a coherent whole; the
_vision_ behind the language, if you like. A language without
theoretical foundations is likely to become a hodgepodge of features.
And who'd have thought of adding, say, anonymous first-class functions
to a language without the input from the _extremely_ theoretical
branch of mathematical logic known as lambda calculus?
>Guess you can spot I'm from the readability school, hmm? :)
So am I, actually; I think the ability to write readable code in any
language is one thing that distinguishes good programmers from bad
ones (of course, that doesn't stop good programmers from producing
unreadable code). To me, readability is partly a matter of style
(consistent indentation, whitespace, naming conventions) but as much a
matter of clarity and economy of thought. I've seen code that follows
all the style guides to the letter, yet is unreadable, because the
underlying thoughts are muddled.
--
Magnus Olsson (m...@df.lth.se)
Erik Max Francis
Magnus Olsson wrote:
> >In languages like C, where the freedom exists to put an assignment
> >into an equality test (which always struck me as confusing code) you
> >really do need different operators.
>
> It's not just that you're free to put an assignment inside an equality
> test, it's that in C, and in Algol (but not in Pascal, for some
> reason), the assignment operator actually has a return value. So
> you're allowed to write things like
> a = ((a == b) > (a != b) + 1);
> (not that it's very useful).
>
> For the benefit of those who haven't seen the reason for having two
> different operators in C,
...
> and there is no way of distinguishing those two statements unless the
> = and == operators have different names.
Right. When you have a language in which all expressions implicitly return
a value, then assignment and equality must be distinct. That's why in LISP
you have setq (and its variants) vs. = (and its variants); they must be
distinguishable, especially in the case of LISP, because there's no
surrounding context of what you might be trying to do with the return value.
Magnus Olsson
In article <32C98314...@alcyone.com>,
>a value, then assignment and equality must be distinct.
To return to the original claim that having the operator = perform both
assignment _and_ test for equality is more "natural" than having distinct
operators, I'd like to sharpen my critique a bit, and state a counterclaim:
Assignment and test for equality are really two quite distinct and
different operations. Having the same operator for both is actaully
both "unnatural" and counter-intuitive, and the *only* reason many
people find it "natural" is that they've been conditioned by using
languages such as Basic.
A general principle when progamming in C++ and other languages where
you can overload identifiers (for example, you can have several
functions called foo() that are only distingusihed by the types of
their arguments, say void foo(int) and void foo(double)), is only to
overload if the overloaded functions perform the same (or at least
closely related) operations. Having two functions or operators with the
same name perform totally unrelated operations can be very confusing.
And it's not only mathematicians that cringe at things like "a = a + 1".
Why else does every book that tries to teach Basic spend a lot of time
explaining that the = operator has two different functions that aren't
the same, and that the = in an assignment statement really isn't
an equal sign at all?
--
Magnus Olsson (m...@df.lth.se)
Erik Max Francis
Magnus Olsson wrote:
> Assignment and test for equality are really two quite distinct and
> different operations. Having the same operator for both is actaully
> both "unnatural" and counter-intuitive, and the *only* reason many
> people find it "natural" is that they've been conditioned by using
> languages such as Basic.
Indeed.
> A general principle when progamming in C++ and other languages where
> you can overload identifiers (for example, you can have several
> functions called foo() that are only distingusihed by the types of
> their arguments, say void foo(int) and void foo(double)), is only to
> overload if the overloaded functions perform the same (or at least
> closely related) operations. Having two functions or operators with the
> same name perform totally unrelated operations can be very confusing.
Particle when your compiler/interpreter has fundamentally no way of
disambiguating the overloaded forms to figure out what you really mean!
> And it's not only mathematicians that cringe at things like "a = a + 1".
> Why else does every book that tries to teach Basic spend a lot of time
> explaining that the = operator has two different functions that aren't
> the same, and that the = in an assignment statement really isn't
> an equal sign at all?
Indeed; this is why, after all, most forms of BASIC have a more formal form
of the assignment statement, namely LET A = A + 1 -- here the use of the =
sign is just part of the LET statement. Because it is not necessary (for
purposes of disambiguation, at any rate), the LET is usually dropped and
this just reads A = A + 1.
Andrew Plotkin
Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> > >In other words, the Z-Machine as target architecture is
> > >both the coolest and the worst choice Graham made for Inform. It makes the
> > >language design much ickier than it might otherwise be.)
> I don't think it necessarily does make the language design
> "ickier", but it has resulted in some historical accidents,
> and I think I probably would prefer run-time data typing
> and a couple of other tweaks. Otherwise, I continue to
> think the Z-machine is an excellent design, and the recent
> proliferation of Z-machine games (which are being played
> on machines where other design systems have never reached:
> people _do_ play on hand-held computers, for instance)
> bears this out.
> Have any Inform authors had to seriously compromise their
> games because of restrictions brought on by the Z-machine?
> I haven't, except when working some years ago for restricted
> subsets of the Z-machine.
_So Far_ uses over 60% of the V8 Z-machine for what is really a
medium-small game. If I had written _Jigsaw_, it would have gone past 512K
in size. (And past _Avalon_ in release date, I'm sure.)
_Lists_ uses about 10K of RAM for its symbol and cons-pair heaps. For the
toy domain of seven programming exercises, you still use up quite a bit of
that -- enough that it garbage-collects more than once. I have no idea how
big an Scheme IF system would be, but if it's only ten times as large, it
will run headlong into the Z-machine's 64K RAM space limit.
Therefore, anyone who wants to use that kind of dynamic programming, via
my library or another, is probably fatally compromised right from the
start. I wanted to create the core of a serious IF tool for the
Z-machine, but I don't think I succeeded.
> > Oh wow, are you hypothesizing different backends for the same front-end
> > Inform compiler? That is, the same source language compiling into Zcode or
> > TADS code or some other virtual machine [such as Java.. dunno if that would
> > make any sense at all]?
I hypothesize this, sure. I want to do it. Preferably before the
increasing desire for more memory, more flexibility -- even more graphics
and sound -- produces yet another slightly hacked Z-machine version.
The Java VM seems like a fine virtual machine, and I don't have to write
the interpreters for it. (It won't run on TRS-80's, but any game that
will fit on a TRS-80 should be compiled to Z-code anyway, not Java, since
it *won't* be straining the Z-machine's capacity.)
> As for Java, surely better to wait for the completion of the
> Java Z-machine interpreter?
No, no. I want to add a lot of features which the Z-machine doesn't
support at all, but are entirely orthogonal to Inform as a language --
they would be available as new opcodes, or rather as a library of
functions which are implemented using new "opcodes" (actually toolbox
traps for the IF runtime system, which is written in Java -- never mind,
this paragraph has gotten way off-track. The point is, Inform as a
language is not limited to 64K of writable memory, or its current inadequate
set of file operations, or any number of other Z-machine limitations that
I have notes on How To Do Better As Soon As I Have Time. Java VM output
coupled with an IF runtime class solves all of that, with no change to
existing Inform source code.)
> The aim is certainly not to worship the Z-machine!
Oops, gotta run. The incense burners are getting low.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Matthew T. Russotto
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
}set of file operations, or any number of other Z-machine limitations that
}I have notes on How To Do Better As Soon As I Have Time. Java VM output
}coupled with an IF runtime class solves all of that, with no change to
}existing Inform source code.)
How do you handle Inform's typelessness? The JVM insists on a
rigid distinction between object references and integers. Inform
emphatically does not.
Andrew Plotkin
Matthew T. Russotto (russ...@wanda.vf.pond.com) wrote:
> In article <erkyrathE...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> }set of file operations, or any number of other Z-machine limitations that
> }I have notes on How To Do Better As Soon As I Have Time. Java VM output
> }coupled with an IF runtime class solves all of that, with no change to
> }existing Inform source code.)
> How do you handle Inform's typelessness? The JVM insists on a
> rigid distinction between object references and integers. Inform
> emphatically does not.
Reply hazy. Ask again later. I Don't Have Time.
(I have an answer, yes.)
Marnix Klooster
erky...@netcom.com (Andrew Plotkin) wrote:
> Graham Nelson (gra...@gnelson.demon.co.uk) wrote:
> > > Oh wow, are you hypothesizing different backends for the same front-end
> > > Inform compiler? That is, the same source language compiling into Zcode or
> > > TADS code or some other virtual machine [such as Java.. dunno if that would
> > > make any sense at all]?
>
> I hypothesize this, sure. I want to do it. Preferably before the
> increasing desire for more memory, more flexibility -- even more graphics
> and sound -- produces yet another slightly hacked Z-machine version.
>
> The Java VM seems like a fine virtual machine, and I don't have to write
> the interpreters for it. (It won't run on TRS-80's, but any game that
> will fit on a TRS-80 should be compiled to Z-code anyway, not Java, since
> it *won't* be straining the Z-machine's capacity.)
I have recently browsed to the Java VM specification, and as
far as I can see the VM itself does not do I/O. I think this is
left to standard libraries in one way or another -- can a
Java-informed person fill me in on this?
> > As for Java, surely better to wait for the completion of the
> > Java Z-machine interpreter?
>
> No, no. I want to add a lot of features which the Z-machine doesn't
> support at all, but are entirely orthogonal to Inform as a language --
> they would be available as new opcodes, or rather as a library of
> functions which are implemented using new "opcodes" (actually toolbox
> traps for the IF runtime system, which is written in Java -- never mind,
> this paragraph has gotten way off-track. The point is, Inform as a
> language is not limited to 64K of writable memory, or its current inadequate
> set of file operations, or any number of other Z-machine limitations that
> I have notes on How To Do Better As Soon As I Have Time. Java VM output
> coupled with an IF runtime class solves all of that, with no change to
> existing Inform source code.)
If you really want to use Java for IF, I suggest to write
directly in Java, rather than write an Java backend for Inform.
For this the following are needed:
- a Java IF library;
- a Java Inform-compatility library;
- an Inform-to-Java translator.
And the latter two are only needed if you want re-use your old
Inform source. I think developing these is much easier than
trying to fit the Z-machine-specific Inform quirks onto the Java
VM. Also, getting to understand the Java VM and compiling
efficient code for it may be a master's thesis worth of work on
its own. Better use an existing Java compiler.
The down-side is, of course, that people would need to learn
Java. (Is that really so difficult compared to Inform? I don't
know (yet).) So to help beginners it could be useful to create
an extension of the Java language, say Jiffy*, and create a
Jiffy-to-Java translator. (If anyone creates such an extension,
I'm available for beta-testing the language design.)
Another disadvantage is that a Java implementation must be
available to authors -- are there any usable and reliable ones
out there?
-----
* That's Java Interactive Fiction For You.
> --Z
Magnus Olsson
In article <32cb6e17...@news.worldonline.nl>,
Marnix Klooster <mar...@worldonline.nl> wrote:
> If you really want to use Java for IF, I suggest to write
>directly in Java, rather than write an Java backend for Inform.
But the point of the entire discussion was that people wanted to
continue using Inform, just replacing the Z machine with a less limited
virtual machine, wasn't it?
>For this the following are needed:
>
> - a Java IF library;
> - a Java Inform-compatility library;
> - an Inform-to-Java translator.
>
>And the latter two are only needed if you want re-use your old
>Inform source. I think developing these is much easier than
>trying to fit the Z-machine-specific Inform quirks onto the Java
>VM. Also, getting to understand the Java VM and compiling
>efficient code for it may be a master's thesis worth of work on
>its own. Better use an existing Java compiler.
If you really are right about the problems of getting Inform to generate
Java bytecode, then I'd suggest going for the Inform-to-Java translator,
not just for converting old games, but as the main development platform.
That is, continue writing in Inform (which, after all, is designed to
make IF writing as simple as possible), but generate Java bytecode using
the Java compiler as a back-end.
> Another disadvantage is that a Java implementation must be
>available to authors -- are there any usable and reliable ones
>out there?
...and are there Java compilers for all the platforms that can run
the Inform compiler?
--
Magnus Olsson (m...@df.lth.se)
Graham Nelson
In article <5agpdg$8...@bartlet.df.lth.se>, Magnus Olsson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
> ....and are there Java compilers for all the platforms that can run
> the Inform compiler?
To my annoyance (though possibly through my incompetence in
finding the right place to look), I have been unable to find
even a Java interpreter for RISC OS, let alone a Java compiler.
My Web browser is the nearest to an "official Acorn-approved
browser", having been licensed by them for their NC set-top
boxes, but it certainly doesn't run applets.
There are times when owning an Acorn is like driving the best
car in the world, but which requires a special sort of petrol
only available in Cambridge. You wouldn't go round the world
in it.
Werner Punz
> I have recently browsed to the Java VM specification, and as
>far as I can see the VM itself does not do I/O. I think this is
>left to standard libraries in one way or another -- can a
>Java-informed person fill me in on this?
Don't have the specs but it AFAIK the VM doesn't handle IO, the native
methods do the job.
> If you really want to use Java for IF, I suggest to write
>directly in Java, rather than write an Java backend for Inform.
>For this the following are needed:
>
> - a Java IF library;
> - a Java Inform-compatility library;
> - an Inform-to-Java translator.
>
>And the latter two are only needed if you want re-use your old
>Inform source. I think developing these is much easier than
>trying to fit the Z-machine-specific Inform quirks onto the Java
>VM. Also, getting to understand the Java VM and compiling
>efficient code for it may be a master's thesis worth of work on
>its own. Better use an existing Java compiler.
>
> The down-side is, of course, that people would need to learn
>Java. (Is that really so difficult compared to Inform? I don't
>know (yet).) So to help beginners it could be useful to create
>an extension of the Java language, say Jiffy*, and create a
>Jiffy-to-Java translator. (If anyone creates such an extension,
>I'm available for beta-testing the language design.)
Somebody is porting an inform V3-V8 interpreter to java anyway and
what I saw from the beta the thing is pretty fast so the problem
shouldn't be that important anymore.
One problem about using java is that the characters are in unicode. So
that the text might take twice the space normal ascii text does. I
don't know if the JDK1.1 jar libraries can handle compression on text
streams and persistent objects. If they do you might achieve better
compression results than with inform, if not.....
BTW. does anybody know of an IF class library written in Java/C++ or
any other OOP language (better would be if it would be documented with
some design method).
Werner
mailto://we...@inflab.uni-linz.ac.at
http://witiko.ifs.uni-linz.ac.at/~werpu/
----------------------------------------------
Check out ftp://ftp.gmd.de/if-archive/ for something
which has been forgotten years ago.
Bill Hoggett
On 02-Jan-97 Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>...and are there Java compilers for all the platforms that can run
>the Inform compiler?
Not by a long chalk! And it's unlekely there will ever be as long as
Java stays proprietary.
Bill Hoggett (aka BeeJay) <mas.su...@easynet.co.uk>
IF GOD IS LIFE'S SERVICE PROVIDER WHY HAVEN'T I GOT HIS I.P. NUMBER ?
Julian Arnold
In article <ant022101d07M+4%@gnelson.demon.co.uk>, Graham Nelson
<URL:mailto:gra...@gnelson.demon.co.uk> wrote:
>
> In article <5agpdg$8...@bartlet.df.lth.se>, Magnus Olsson
> <URL:mailto:m...@bartlet.df.lth.se> wrote:
> > the Inform compiler?
>
> finding the right place to look), I have been unable to find
> even a Java interpreter for RISC OS, let alone a Java compiler.
> My Web browser is the nearest to an "official Acorn-approved
> browser", having been licensed by them for their NC set-top
> boxes, but it certainly doesn't run applets.
I have heard mumblings from ANT (who are the nice people responsible for
the browser which Graham and I use, Fresco) that they are working on a
Java-capable version of Fresco for the NC. OTOH, ANT have also
effectively told me that they are not working on, have not worked on,
and have no plans to work on such a beast.
So I am almost completely certain that Graham is not incompetent in this
matter.
> There are times when owning an Acorn is like driving the best
> car in the world, but which requires a special sort of petrol
> only available in Cambridge. You wouldn't go round the world
> in it.
Ain't that the truth. Vroom vroom! Splutter!
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me
from ever completing anything." -- Herman Melville, "Moby Dick"
Trevor Barrie
wo...@one.net (Roger Plowman) wrote:
>I think we're talking from different points of view. As a programmer I
>don't care if a particular function is part of the library or a native
>part of the compiler.
As a programmer, I don't care until the time comes that I feel I have to
rewrite it, which happens a lot.
>Ah, but I'm not talking about making the syntax more complex (in
>terms of number of distinct symbols (as in APL)) I'm talking about
>making the syntax more difficult for a *compiler* to decipher. In
>other words, to remove much of the regimentation that eliminates
>ambiguity.
>
>Or, in other words, making syntax and context work together, just as
>they do in human lanagues. Is such a compiler harder to write?
>Abso-damn-lutely! Would it be easier to program in? You betcha!
IMO, it wouldn't. Relying on context inevitably results in ambiguity,
whether you're talking about a human language or a programming language.
>I gave up eventually. Don't get me wrong, ADVSYS as a language has
>many strong points. But ADVSYS (and TADS, to a lesser degree) share a
>syntax that favors ease of compilation over readability. Lisp
>languages (just like APL) share the dreaded "write-only" syndrome.
Not IMO.
>I mean, how intuitive is:
>
>(if (not (= a b)) (+ a 1) (abort))
>
>to the average IF writer? Remember, writing IF isn't supposed to be
>about programming, it's supposed to be about writing.
If we're assuming no programming experience, then it's no more or less
intuitive than:
if (a != b) a+1 else abort;
Maybe slightly more, since with the LISP version you don't have to learn as
many rules before you can read it.
>Here's a more intuitive Basic version of the same line
>
>IF a<>b THEN a=a+1 ELSE abort
>
>Or, in TADS
>
>if (a<>b) a++; else abort;
How on earth are either of those supposed to be more intuitive than the LISP
example?
Roger Plowman
tba...@cycor.ca (Trevor Barrie) wrote:
>As a programmer, I don't care until the time comes that I feel I have to
>rewrite it, which happens a lot.
Agreed. But most of the time when I'm using a library (be it TADS or
PB or whatever) I don't want to *rewrite*, I want to *use*. For me,
library rewrites are one of the last things I want to do, I simply
don't have the time.
>>I mean, how intuitive is:
>>
>> (if (not (= a b)) (+ a 1) (abort))
>>
>>to the average IF writer? Remember, writing IF isn't supposed to be
>>about programming, it's supposed to be about writing.
>
>If we're assuming no programming experience, then it's no more or less
>intuitive than:
>
>if (a != b) a+1 else abort;
I have to disagree. The ADVSYS version isn't in English, it isn't even
close. It contradicts the user's expectations of the flow of the text.
>>IF a<>b THEN a=a+1 ELSE abort
>
>How on earth are either of those supposed to be more intuitive than the LISP
>example?
At least in the BASIC version the reader's eyes don't skitter over the
parentheses like a stone skipped across a lake. I mean, look at them
side by side.
(if (not (= a b)) (+ a 1) (abort))
IF a<>b THEN a=a+1 ELSE abort
In the ADVSYS version there are 3 words recognized by non-programmers
(if, not, abort).
In the BASIC version there are 4, (IF, THEN, ELSE, abort). But more
importantly, the basic form of (IF ___ THEN ____ ELSE _____ ) forms an
recognizable sentence, with recognizable signposts as to where each
clause ends. The ADVSYS version has no such signposts (the parentheses
don't coun't since one parenthesis looks pretty much like any other).
*That's* what I mean by intuitive. Basic is like a pidgin form of
English, the reader may not grasp everything on a quick scan of the
code, but at least they have the impression that this is something
they could understand if they looked at it carefully.
To the average non-programmer ADVSYS looks like line noise.
And this is one of the simplest examples. In ADVSYS/Lisp a half dozen
conditions on the test, coupled with multiple lines in both THEN and
ELSE clauses is going to make a murky mess.
Thus (IMO) to the average IF writer/game creator (as opposed to
programmer) BASIC is more intuitive than ADVSYS.
Respectfully,
Wolf
Norman Ramsey
In article <ant3021181cbM+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>[A spirited and interesting defense of Inform, including...]
>> So the language has two separate notions of "property" (the existence
>> of which is already a source of pointless non-orthogonality), one
>> with an ad hoc magic-number limit.
>
>No, I really am not going to beat my breast over this one. It's an
>implementation matter, really. You just don't need to use "Property":
>it's hardly mentioned in the manuals any more. I think the parallel
>is with C, where some variables can be flagged as "register" to ask
>the compiler to compile code using them more efficiently. Of course,
>there is necessarily a magic-number limit to the number of registers
>in the machine. In Inform 6, "Property" is a directive used by the
>library to improve the efficiency of code, that's all.
May I humbly suggest that a future version of the Inform compiler do
what good C compilers have long done, i.e., analyze the code to decide
which properties are best given this special representation? Even if
`Property' must be left in for backwards compatibility, it can be a
no-op.
--
Norman Ramsey
http://www.cs.virginia.edu/~nr
John Holder
Roger Plowman wrote:
: At least in the BASIC version the reader's eyes don't skitter over the
: parentheses like a stone skipped across a lake. I mean, look at them
: side by side.
: (if (not (= a b)) (+ a 1) (abort))
No self-respecting Lisp-style programmer would write this this way, it would
be written:
(if (not (=a b))
(+ a 1)
(abort))
Which is easily seen as three "parts", an if-condition, a then, and an else.
After 10 minutes of familiatiry with this concept, I have found Lisp just
as easy to read and program as C and C++ if not more so.
(After all, how obvious is:
while((*s++ = *t++) != '\0');
to copy string t to string s?)
I know we are talking about IF languages, but IMHO, Lisp has been far easier
for me to learn in the last 2 months than Inform has been in the last two
years, in terms of total effort expended. Must be the consistant syntax.
Anyway, I know this is a religious war (in a way), and I'll be the first
to tell you that C is a great language and I love it fine ... as Andrew
Plotkin pointed out, this only means that I share a kind of brain damage
for knowing as much about C as I do. However, I now find myself writing
code that is better suited to Lisp in Lisp. I haven't developed strong
opinions yet about what IF is best suited to.
Anyway, I'm late leaving, so I gotta get out of here.
Peace,
John
--
John Holder (jho...@frii.com) /\ http://www.frii.com/~jholder/
UNIX Specialist, Paranet Inc. <--> Raytracing|Fractals|Interactive Fiction
http://www.paranet.com/ \/ Homebrewing|Strange Attractors
ct
In article <ant03223...@arnod.demon.co.uk>,
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
> Graham Nelson wrote
>>
>> To my annoyance (though possibly through my incompetence in
>> finding the right place to look), I have been unable to find
>> even a Java interpreter for RISC OS,
>
>Java-capable version of Fresco for the NC. OTOH, ANT have also
>effectively told me that they are not working on, have not worked on,
>and have no plans to work on such a beast.
>
>So I am almost completely certain that Graham is not incompetent in this
>matter.
Well, he's not trying terribly hard either. I heard first-hand reports
that he was wandering around AW'96, where there was a version of
Fresco running on the ART stand happily running Java applets. Perhaps
you should both try again at BETT'97 this week!
regards, ct
Matt Ackeret
In article <59uhn6$c...@mamba.cs.Virginia.EDU>,
Norman Ramsey <n...@mamba.cs.Virginia.EDU> wrote:
>I think you're assuming that the goals for an IF language or compiler
>should be the same as the goals for a compiler for a general-purpose
>programming language, e.g., the generated code should run fast.
>What evidence have you got in favor of this position?
Well, this one seems simple. Especially since many people (including myself)
are playing these games on what many people consider "obsolete" (as in older
and slower) hardware, making the code that needs to be emulated as small
and fast as possible just helps in general.. Also it helps lessen the
requirements of optimizing the *emulators*.
--
mat...@apple.com
Andrew Plotkin
Any program gets pushed to the limits. This will continue to be true,
especially in experimental (and future mainstream :-) IF programs. Look
at WorldClass. Look at Lists -- the Lisp engine is perceptibly slow to
start up on my 68040 machine.
Obviously there's such a thing as "fast enough"; there's a point where
the compiler writer stops optimizing and uploads the software already.
But equally obviously, "fast" *is* a goal. A slower system will lose
favor versus a faster one. It's a factor that users notice. Q.E.D.
Bill Hoggett
On 05-Jan-97 John Holder <jho...@frii.com> wrote:
>(After all, how obvious is:
>while((*s++ = *t++) != '\0');
>to copy string t to string s?)
That's not really fair! Why use C "shorthand" as an example when all
C programmers know that you can make C seem totally "rune-like" if you
really try.
I wouldn't argue with the fact that LISP is learnable, just that it's
not intuitive to anyone who finds (= a b) a little alien.
John Holder
Bill Hoggett (mas.su...@easynet.co.uk) wrote:
: On 05-Jan-97 John Holder <jho...@frii.com> wrote:
: >(After all, how obvious is:
: >while((*s++ = *t++) != '\0');
: >to copy string t to string s?)
: That's not really fair! Why use C "shorthand" as an example when all
: C programmers know that you can make C seem totally "rune-like" if you
: really try.
Okay, that _was_ a bit overboard...
: I wouldn't argue with the fact that LISP is learnable, just that it's
: not intuitive to anyone who finds (= a b) a little alien.
Have you used an RPN calculator? I personally find them very intuitive.
They happen to be postfix notation, were you to write expressions out, ie:
(note that postfix is essentially identical to thinking of using stacks)
5 3 * 6 +
or
((5 3 *) 6 +)
evaluates to 21.
I'm not argueing that LISP is a little alien at first - so is C. But just
like learning an RPN calculator, it doesn't really take all that long for the
alien to become familiar.
Anyway, my "Real Opinion" is that programmers should use languages that do
what they need for a tasks the languages are suited to, and that a programmer
should feel comfortable using the language. (not that I do not specify what
languages IF is best suited to - I'm still working that out for myself. But
I'm looking real hard at Scheme + SCOOPS + Schelog, which is OO Scheme with
native Prolog)
This may or may not exclude Lisp/Scheme/Whatever from your usable language
list, I feel that every programmer owes it to him or her self to learn at
least one major language in each of the four programming paradigms.
As far as I can tell, the "most" major languages in the functional area
have to be Lisp and Scheme.
I've been writing Scheme for 2-3 weeks now, and just install Common Lisp
on my Linux box last nite... Yes, I did learn a tiny bit about these languages
in my degree program for Computer Science, however not really enough to
judge the languages in a realistic fashion compared to the amount of time I
have invested in C and C++ (among others). I have been prompted to learn
as much as I can about these languages largely because of Dave Bagget's
strong opinions for these languages, and to be honest, I'm afraid I'm becoming
a convert...
John "Learning Lisp, Scheme and Prolog because he owes it to himself" Holder
Matt Ackeret
In article <561.6945...@easynet.co.uk>,
Bill Hoggett <mas.su...@easynet.co.uk> wrote:
>On 05-Jan-97 John Holder <jho...@frii.com> wrote:
>>(After all, how obvious is:
>>while((*s++ = *t++) != '\0');
>>to copy string t to string s?)
>
>That's not really fair! Why use C "shorthand" as an example when all
>C programmers know that you can make C seem totally "rune-like" if you
>really try.
Besides, the above isn't even optimal C. It's doing an extra comparison.
while((*s++ = *t++));
is more compact and (possibly) faster.
--
mat...@apple.com
Graham Nelson
Yes, I was at AW 96, anxiously folding an inaccurate "Games Editor"
badge into my lapel. (Strange people, like an Acorn salesman
wearing blue pyjamas and looking like an escapee from the ski
show next door, kept giving me their business cards.) Warm
Silence Software were, very pleasingly, selling Lost Treasures
of Infocom I and II, but the rest of the show was a non-event
for games.
I quite missed the Java-capable "Fresco". It is amusing to mount
a language designed to make memory collapses and destructive bugs
impossible onto a browser which, at the moment, is... well...
let's just say "Walls of Jericho" would be an alternative title.
Marvellous program in many ways (but for lack of frames), but
a 10M top-of-the-range Risc PC is just not big enough for it.
(Actually the newsreader, Marcel, is a much worse miscreant.)
But yes, I'm basically a contented ANT Internet Suite user.
They're much better at support than software, which is nice
change from the other way round.
Erik Max Francis
Trevor Barrie wrote:
> How on earth are either of those supposed to be more intuitive than the
> LISP example?
I would say it's undeniably true that to people unfamiliar with computing,
LISP is far more hard to learn than a more English-like language like BASIC.
I wouldn't call it a matter of intuitiveness; it's just that BASIC (and even
Pascal or C) are more easily readable to people than LISP, particularly
without any prior experience with programming languages.
FReDRiK RaMSBeRG (WILdcARD)
drg...@aol.com (DrGong1) writes:
>A perfect language for a Newbee would be in BASIC. have the paser as a
>libary file
>(So more advanced Programers can modify it) While the novince would just
>program the game and not suffer thru the paser.
I agree that it is possible to make pretty good IF games in Basic. Basic
has the advantage that a lot of people already know it and have access to
it. However, if they have been able to learn Basic, I don't think they will
have too much trouble learning Inform either.
When I first read the Inform manual, it struck me again and again that
Inform does what I had tried to do for several years, in Basic as well as
more odd languages. I always found a solution, but it was a lot of hard
work and I often ended up with a not-at-all-pretty program, because Basic
and other "simple" languages lack a lot of very useful mechanisms.
For instance, if I make a boat in Inform, I call it Boat. In Basic I would
have called it 17 or something. If I want to add a synonym to the boat,
like "dingy", I just add it in the object definition, where all other
aspects of the boat are gathered. In Basic...well, you don't want to know.
It's ugly, I can tell you that much.
If you use an IF authoring system that comes with a complete set of library
routines, such as Inform, you will spend a lot less time programming
general gaming mechanisms and get more time and energy for the game itself.
As a little bonus, the game is fully portable to almost any computer (OK,
there are still a few calculator wristwatches that can't play
Inform-games...).
And don't forget to have a look at the smaller systems either. They give
you pretty much the same advantages, but with less possibility to program
special game mechanisms and exceptions to the general behaviour. This is
the price you pay for getting something less complex to learn.
/Fredrik
--
Fredrik Ramsberg, Comp Sci student, Linkoeping, SWEDEN
d91f...@und.ida.liu.se, http://www-und.ida.liu.se/~d91frera
----------------------------------------------------------------------------
Proud winner of the 1996 Humility World Championships!!!
Admiral Jota
d91f...@ida.liu.se (FReDRiK RaMSBeRG (WILdcARD)) writes:
[snip]
>As a little bonus, the game is fully portable to almost any computer (OK,
>there are still a few calculator wristwatches that can't play
>Inform-games...).
This reminds me... is there a Z Machine interpreter for the HP48GX
graphical calculators?
--
/<-= -=-=- -= Admiral Jota =- -=-=- =->\
__/><-=- http://www.tiac.net/users/jota/ =-><\__
\><-= jo...@mv.mv.com -- Finger for PGP =-></
\<-=- -= -=- -= -==- =- -=- =- -=->/