I7: Why is it so hard to do simple stuff?
Jim Aikin
work as well as it used to. Or maybe I just like being whiny in public. But
... why am I struggling, grappling, and floundering over the syntax with
which to attach a simple numerical variable to an object? Isn't this
supposed to be, like, something that we all learned to do in programming
101?
Does anybody but me feel that Inform 7 is trying very hard to reinvent the
wheel? "Let's not call them spokes, let's call them radials. It's not a hub,
it's a center. It's not a tire, it's a rubber round. It's not an axle, it's
a rotator."
Man, if I could have this IDE with I6, I would fly to England and kiss
Graham's feet. Of course, there's no guarantee he'd be pleased at the
prospect. Maybe I should promise _not_ to....
Never has my occasional signature line (see below) seemed more apropos.
--Jim Aikin
*******************************
"Those instances of it which lack
the quality referred to as 'swing'
are meaningless." --Duke Ellington
*******************************
Emily Short
Jim Aikin wrote:
> Maybe it's just me. Maybe it's because I'm getting old and my brain doesn't
> work as well as it used to. Or maybe I just like being whiny in public. But
> ... why am I struggling, grappling, and floundering over the syntax with
> which to attach a simple numerical variable to an object? Isn't this
> supposed to be, like, something that we all learned to do in programming
> 101?
I realize that you're not actually asking for help, here, but if in
fact you still want the answer, see section 4.7, "new value properties".
Arnel Legaspi
> Man, if I could have this IDE with I6, I would fly to England and kiss
> Graham's feet.
I couldn't agree more, except the kissing Graham's feet part. :)
This is more for historical curiosity: why was an I6 IDE like what I7
has now never been made? Was it something related to the internal
structure of I6? I recall Dave mentioning something called Visual
Inform, but it's unfinished.
Thanks in advance to anyone who replies.
--Arnel
Jim Aikin
> fact you still want the answer, see section 4.7, "new value properties".
Thanks. And first, my apologies for being whiny. That's the Bad Jim, who
pops up from time to time when my frustration level exceeds a certain
threshold.
I did eventually figure out how to set up a local variable. I forced myself
to do it before I looked at the newsgroup this morning, so that I could
document the process of grappling with it. The code and comments I came up
with are at the end of this message, and it's possible you might find them
useful. I've observed in my professional life (I write magazine reviews of
complex pieces of music software) that people who know a system extremely
well sometimes unconsciously assume that something will be obvious to a
newcomer, when in fact it's anything but obvious.
The larger question, though, is not whining, or at least not entirely: Why
reinvent the wheel?
In the course of my research (if you want to dignify it with that term) this
morning, I found a syntax that worked at a particular spot: "change the
times-eaten of the biscuit to the times-eaten of the biscuit plus 1." I then
tried, just for kicks, replacing this with "biscuit's times-eaten += 1."
This syntax, though much easier to read, type, and spot errors in, wasn't
understood by the compiler.
To put the question another way, why compel the experienced programmer to
learn an entirely new (and rather convoluted) syntax, when the genuinely new
features of I7 could perhaps have been grafted with less effort onto the
familiar (and more concise) syntax of I6?
I want, if possible, to ask that question without disrespecting the ENORMOUS
intellectual accomplishment of Inform 7. You and Graham are a lot smarter
than me, and you've clearly worked harder on this than I've ever worked on
anything, and the conceptual framework you've developed may prove to have
far-reaching implications that are well beyond my ability to envision.
I've completed and released only one game (which people did seem to like).
I'm only a very occasional participant in the IF community. I may be missing
the point entirely. But I kind of feel that my perspective and experiences
as a moderately knowledgeable hobbyist programmer who is willing to put a
week or two into exploring a new IF language may be valid or useful. (Aside:
Last winter I tried to tackle TADS 3, and had a similar reaction, though for
diametrically opposed reasons. I found myself crying, "Classes and templates
and macros, oh my!" TADS 3 is an unabashedly expert system, whereas it seems
clear that you want I7 to be readily approachable by novices.)
My tentative observation is that "natural language programming" offers no
advantages that I can see to anyone who has even minimal programming
experience, and because it isn't actually "natural language" is not likely
to be more accessible to the novice either.
Perhaps an analogy would be useful. I happen to have a friend who is a
professional mathematician. Suppose I went to him and said, "Hey, Rip -- how
about writing out equations in natural language? Instead of (5 * 7) + 9 = 11
* 4, we could write '5 stacked by 7 beside 9 equates to 11 stacked by 4.'
Instead of using all those confusing Greek letters, why not spell out the
names sigma and delta? You wouldn't need to use Mathematica anymore -- you
could use a word processor!" My friend would think, with some justification,
that I had gone mad. Why? Because the symbolic language of mathematics is
exactly and concisely suited to expressing the concepts of mathematics.
It could be argued that the same is true of computer programming languages:
They have the highly symbolic form that they have because that form is
exactly and concisely suited to expressing the concepts and structure of a
computer program.
I could be entirely wrong about this. In any historical sense, we're still
in the VERY early days of programming. I'd love to be able to come back in
500 years and find out how the art of programming has evolved. But it does
seem to me that it's a question that can legitimately be raised, even (or
perhaps especially) by somebody who occasionally gets whiny when frustrated.
Thanks for listening.
--Jim Aikin
<begin code block with embedded comments>
"The Transcendental Biscuit"
[Note: I had originally called the room the Transcendental Biscuit
Company -- but it turns out that if I do that, I can't have a thing called a
biscuit. The code won't compile. This may be user error; perhaps a different
syntax would work. If so, I hope the syntax is explained somewhere. If it's
a genuine limitation, it forces the author to come up with substitute names
for things rather than using their natural, intuitive names, which would not
be good.]
The Transcendental Bakery is a room. "All around you stand the giant,
steaming, gleaming ovens of the Transcendental Bakery. Somewhere nearby, a
choir is singing."
The biscuit is a thing in the Bakery. The description is "Looks yummy!" The
biscuit is edible. The biscuit has a number called times-eaten. The
times-eaten of the biscuit is usually 0.
Instead of eating the biscuit:
say "Delicious -- and amazingly, as soon as you finish the biscuit, it
reappears!";
change the times-eaten of the biscuit to the times-eaten of the biscuit plus
1;
say "You have now eaten the biscuit [if times-eaten is 1]once[else if times
eaten is 2]twice[else][times-eaten] times."
[My goal is fairly simple: I want a biscuit that will keep track of how
often it has been eaten, and tell the reader about it. Here are some of the
attempts that don't work. First, the obvious, natural way to say what I want
to say:
The biscuit has a number called times-eaten. Initially times-eaten is 0.
The error message objects to the syntax of "Initially times-eaten is 0."
("this seems to say that a thing is a value, like saying 'the chair is
10'"). This leads me to believe that declaring a variable to be a number
doesn't make it one. It's ... something else. But in fact, I will soon learn
that the problem is not with the way the variable has been declared; the
problem is with the way I've attempted to assign it a value.
Next, based on chapter 13.6, we try creating a global variable that can be
used to track how often the biscuit has been eaten. This bit compiles:
Times-eaten is a kind of value. 1 specifies a times-eaten.
You'd think that would indicate that times-eaten is a numeric variable type.
(Well, actually, if you're paying close attention, you'd know that it
creates an entire class of numeric variables, when all we need is one
instance.) As an aside, in chapter 13.7 we learn this: "The essential
requirement is that the specification must be one that clearly specifies no
other kind. So '10 specifies a weight' will not be allowed." Hmm -- it did
compile, so either the manual is not up-to-date, there's a compiler bug, or
I've committed some other gaffe.
So how do I initialize a local variable? I try "Initially times-eaten equals
0." The compiler can't find a verb. And at last, success: "The times-eaten
of the biscuit is usually 0."
Another aside: By the time we get to page 13.9 we're deep in the land of how
to specify the parts of a number -- but we haven't yet learned how to attach
a local variable to an object, or how to declare it. Nor, in fact, have we
learned how to declare a global variable. We have only learned how to
declare KINDS of local variables (i.e., classes of variables). This
essential feature of any computing language is not discussed anywhere in
Chapter 13, "Units," as far as I can see. So I'm on my own....
Next challenge: Incrementing the variable. I try "add 1 to the times-eaten
of the biscuit". Again, natural language -- and again, it won't compile. I
have to use the far wordier "change the times-eaten of the biscuit to the
times-eaten of the biscuit plus 1."
Now we're ready to report to the player how often the biscuit has been
eaten. We begin with the natural syntax, which doesn't work:
say "You have now eaten the biscuit [if times-eaten is 1]once[else if times
eaten is 2]twice[else][times-eaten] times."
The compiler complains "I was expecting that 'times-eaten is 1' would be a
condition, but I couldn't make sense of it in any context." Well, it looks
like a condition to me. Changing 'is' to 'equals' doesn't help. The process
of introducing conditions into text printout is first mentioned, I think, in
3.14, but what's being tested on that page is an either/or condition, not
the value of a variable. Turning a variable into an either/or condition in
order to test it ... no, I don't even want to think about that. The same
topic is covered in 4.11, but again only either/or properties are being
tested.
So how DO you test the value of a variable while printing text (not to print
it but for some other reason)? Another page in the TOC that looks promising
is 4.8, "Text with substitutions." But those are just block substitutions,
not conditional branches. I haven't solved this little puzzle yet. The
manual doesn't seem to explain how to assemble the not very complicated text
message I've been trying to print out. At least, it doesn't do it on the
pages where the TOC would lead me to expect the information to be found.]
<end code with comments>
_Felix
> My tentative observation is that "natural language programming" offers no
> advantages that I can see to anyone who has even minimal programming
> experience, and because it isn't actually "natural language" is not likely
> to be more accessible to the novice either.
I'm inclined to agree. I was impressed by the natural language thing at
first, then it became apparent that the main thing provided by new
syntax is a collection of new ways in which the computer can
misunderstand me.
Writing in natural language feels amusingly similar to playing an
adventure game.
However, I have made a resolution to give it a fair trial and not bitch
about it for at least a month. I'm aware that I always hate every new
language I learn for being alien and icky and not behaving the way I
expect. It's possible that when I get used to it, it will be a really
good way to write adventure games (though questionable for any other
purpose).
The tricky part is learning all the idiosyncracies.
_Felix
say "You have now eaten the biscuit [if the times-eaten of the biscuit
is 1]once.[if the times-eaten of the biscuit is 2]twice.[otherwise][the
times-eaten of the biscuit] times."
I want to be able to tidy that up a bit by using a local variable name,
like this:
say "You have now eaten the biscuit [if the times-eaten of the biscuit
(called n) is 1]once.[if n is 2]twice.[otherwise][n] times."
But that doesn't work. Something a bit like that works in other
contexts. *shrug*
And global variables are on page 4.17:
The target is a number variable. The target is 23.
Emily Short
Jim Aikin wrote:
> The larger question, though, is not whining, or at least not entirely: Why
> reinvent the wheel?
Yes, I understand what you're asking; I asked something similar at the
outset. I wasn't involved with the project until after the NL aspect of
Inform was already rather developed. If you like, and you haven't
already, you can read Graham's white paper on the topic, which explains
better than I could.
My comment at the time was that I didn't see how such a syntax could
possibly be anything other than frustrating for an experienced user and
that I hoped we'd be allowed access to I6 to do the real work in. I've
since changed my mind, for the simple reason that I find I7 now much
faster to work in and also capable of pretty much anything I can throw
at it; but the argument from subjective experience is not so compelling
to someone who is on the frustrated end of the curve.
> In the course of my research (if you want to dignify it with that term) this
> morning, I found a syntax that worked at a particular spot: "change the
> times-eaten of the biscuit to the times-eaten of the biscuit plus 1." I then
> tried, just for kicks, replacing this with "biscuit's times-eaten += 1."
> This syntax, though much easier to read, type, and spot errors in, wasn't
> understood by the compiler.
No, I suppose not. But any of these would have been:
increase the times-eaten of the biscuit by 1; (still NL, but less
verbose and in this case less annoying, I feel)
change the times-eaten of the biscuit to times-eaten of the biscuit
+ 1;
as also formulations such as
say 12 + 2;
let n be 3 * 4 - 2;
and so on. It is not required that you write out most of these
mathematical symbols as words. (For that matter, += doesn't work in
Inform 6 either.)
I imagine that for really complex functions it may still make sense to
drop down to the symbolic language of Inform 6; this is also what one
needs to do when, for instance, manipulating the parse buffer
letter-by-letter, or writing other similarly surgical bits of code.
While it might in theory be possible to write a set of I7 syntax for
that purpose, it was felt that this would make things more painful
rather than less.
It might be pointed out that, in that case, I7 more or less guarantees
that this kind of manipulation can't be written from scratch by
novices; but this wasn't exactly novice work in Inform 6 *either*; and
we have tried to anticipate and provide for some of the major things a
novice might want to do in Inform 6 in the form of extensions.
> To put the question another way, why compel the experienced programmer to
> learn an entirely new (and rather convoluted) syntax, when the genuinely new
> features of I7 could perhaps have been grafted with less effort onto the
> familiar (and more concise) syntax of I6?
Well. There's a historical reason for this and a theoretical reason, I
suppose. The historical reason was that the idea of an NL Inform came
first and gave rise to many of the "genuinely new" features. The
theoretical reason is that a good deal of the really powerful content
of I7 -- relations, for instance -- would I think be quite hard to
graft onto Inform 6 in any way that made sense.
> My friend would think, with some justification,
> that I had gone mad. Why? Because the symbolic language of mathematics is
> exactly and concisely suited to expressing the concepts of mathematics.
No question about that; and I agree with you that where most of what we
want to do is arithmetical manipulation, the syntax of Inform 6 (or
many another more traditional programming language) is more concise.
But quite a lot of IF programming has, in fact, nothing conceptually to
do with arithmetic at all, though sometimes we wind up having to
express it in such terms because of the limitations of traditional
languages. Writing, for instance, a loop, or a mechanism to access an
array properly, involves counters and indices in the traditional form,
but I think we actually cut closer to the conceptual intention if
instead of writing something like (untested and probably wrong, because
it's been a while since I wrote I6 of this kind)
objectloop(x ofclass lady)
{
for(i=0:i<x.#admiration:i++)
{
if (x.&admiration-->i == 0) { x.&admiration-->i =
fluffy_dog; break; }
}
}
we write
now every woman likes the fluffy dog.
If we had to write out the symbols of the first version in I7 language
then that would be pretty insane; but as it happens the language
provides some leverage to present this idea easily: go through all the
women in the game and assign them to this relationship (which, in
Inform 6, would have to be expressed as an array property, requiring
indexed access).
There is more here deserving comment -- and I appreciate your commented
code block. I'm afraid I'm in the last stages this weekend of getting
ready for a six-week trip, which means that I'm a bit frazzled; if I
don't come back to this thread in more detail, that'll be why.
A couple of quick remarks:
> [Note: I had originally called the room the Transcendental Biscuit
> Company -- but it turns out that if I do that, I can't have a thing called a
> biscuit. The code won't compile. This may be user error; perhaps a different
> syntax would work. If so, I hope the syntax is explained somewhere. If it's
> a genuine limitation, it forces the author to come up with substitute names
> for things rather than using their natural, intuitive names, which would not
> be good.]
Right -- Laura, section 3.11, covers some ways around this.
> Another aside: By the time we get to page 13.9 we're deep in the land of how
> to specify the parts of a number -- but we haven't yet learned how to attach
> a local variable to an object, or how to declare it.
Mmyes, okay. This is covered back in chapter 4.
A tricky thing about the manual is that it is designed for sequential,
not random access -- it pretty much assumes that you will go through
the whole thing at least once from the beginning, and perhaps looked at
the one- and two-star examples by way of tutorial.
Now, I realize that many people, especially those coming to it from a
programming background who have some idea of what they want to do, will
not want to approach it that way, and will try to treat it as a
reference manual, and get Fairly Annoyed. Some of this we can alleviate
with better indexing and searching, as mentioned in earlier threads;
some of it, I hope, by putting a review of relevant topics at the
beginning of each chapter of the manual (perhaps in the form of an
example, the way Chapter 15 starts with a couple of examples reviewing
how to make new actions) and an overview of learned syntax at the end
of each. Which we're working on.
> say "You have now eaten the biscuit [if times-eaten is 1]once[else if times
> eaten is 2]twice[else][times-eaten] times."
>
> The compiler complains "I was expecting that 'times-eaten is 1' would be a
> condition, but I couldn't make sense of it in any context."
That's unhelpful, and deserves a bug report. The problem here is, in
fact, that you can't nest conditionals within a say statement.*
* There is a way to hack this to make it possible, which has been
documented by vaporware in another thread. But Inform 7 doesn't do it
on its own.
Ack, okay, anyway -- I have to run off and do some errands now; sorry
for the truncated response. But I am interested in your feedback.
ixnay
news:ZneDg.4819$%j7....@newssvr29.news.prodigy.net...
> Does anybody but me feel that Inform 7 is trying very hard to reinvent the
> wheel? "Let's not call them spokes, let's call them radials. It's not a
> hub, it's a center. It's not a tire, it's a rubber round. It's not an
> axle, it's a rotator."
I agree in some ways. Problem is it's the best choice you have really.
(Except maybe for Inform 6.) TADS 3 appears to be dead. (Web site's last
update says general release would happen in a couple months and that was
dated "29 August 2005.") The other systems just don't get the support that
Inform does. Inform is kind of like the Microsoft of IF: even if you're not
always thrilled with it, it's probably a good choice in terms of being the
most active. I think Inform 7 is really interesting in a lot of ways, but
saddled with too much baggage. Clearly opinions are gonna differ on that,
though. I'd like to see a non-NL version of Inform 7, but I'm guessing
that's not going to happen.
Jim Aikin
> programming background who have some idea of what they want to do, will
> not want to approach it that way, and will try to treat it as a
> reference manual, and get Fairly Annoyed. Some of this we can alleviate
> with better indexing and searching, as mentioned in earlier threads;
> some of it, I hope, by putting a review of relevant topics at the
> beginning of each chapter of the manual (perhaps in the form of an
> example, the way Chapter 15 starts with a couple of examples reviewing
> how to make new actions) and an overview of learned syntax at the end
> of each. Which we're working on.
Here's a concept: How about a whole chapter called "Inform 7 Quickstart
Guide for Experienced Programmers"? It could cover things like:
How to create something that operates like a function, and how to pass
values to it and get values back.
How to create and manipulate numeric variables.
How to test the value of a variable in various contexts.
How to start and stop a daemon.
How to assemble a highly variable room description, including calling a
separate function to print alternative stuff in the middle of a sentence.
I'm sure others can come up with topics I haven't thought of. Each section
of the chapter could be rather terse. Just give, perhaps, a block of code in
I6 and TADS 2 and then show the I7 equivalent.
--JA
Arnel Legaspi
> This is more for historical curiosity: why was an I6 IDE like what I7
> has now never been made? Was it something related to the internal
> structure of I6? I recall Dave mentioning something called Visual
> Inform, but it's unfinished.
I've just researched threads related to Visual Inform on Google Groups,
and I think it won't be for anyone's benefit to even bring it up.
Apologies for even mentioning this here.
Daryl McCullough
>My comment at the time was that I didn't see how such a syntax [natural
>language] could possibly be anything other than frustrating for an
>experienced user and that I hoped we'd be allowed access to I6 to do the
>real work in. I've since changed my mind, for the simple reason that
>I find I7 now much faster to work in and also capable of pretty much
>anything I can throw at it; but the argument from subjective experience
>is not so compelling to someone who is on the frustrated end of the curve.
I read Graham's essay about the power of natural language, but
I'm still not completely convinced. Basically, his argument amounts
to an argument for more powerful programming constructs
(for example, "now all nearby mice are frightened" instead
of something like "loop over objects o: if o ofclass Mouse and
location(o) = location(player) then give o frightened.") But
do these more powerful constructs have to be expressed in
natural language? I'm not convinced that it helps to do so.
The problem with using natural language is that it is *very*
difficult to know what is or is not going to be understood
by the compiler. Going from what you want to happen to how
to express that in the way the compiler understands can be
a frustrating experience. In contrast, with traditional
programming languages, you know that whatever you are trying
to do, it has to be one of a small number of things: a function
call, an assignment statement, a loop, etc.
--
Daryl McCullough
Ithaca, NY
_Felix
> The problem with using natural language is that it is *very*
> difficult to know what is or is not going to be understood
> by the compiler. Going from what you want to happen to how
> to express that in the way the compiler understands can be
> a frustrating experience. In contrast, with traditional
> programming languages, you know that whatever you are trying
> to do, it has to be one of a small number of things: a function
> call, an assignment statement, a loop, etc.
I think the number of constructs in Inform's natural language is
reasonably small. The problem is that they all look a great deal like
*real* human natural language, and the number of constructs in *that*
is huge.
So ... for instance, yesterday I tried to write "list the contents of
the room", and it took me a while to work out that I wasn't allowed to
use "the" between "list" and "contents". Possibly you're right, and it
would be better if the language looked a bit *less* natural,
particularly when it comes to phrases that are the equivalent of
keywords.
So it might be better to have an expression like "contents-list the
room". Using a keyword, I mean, which looks only *slightly* natural but
is still distinctly a keyword.
I also notice that syntax falls into different groups, for different
types of task, which have different chapters in the manual, but they
often use similar expressions (natural language tending to express
similar concepts in similar words) and it's easy to forget which subtle
variation of syntax is correct for a particular context.
So it might be better to have some kind of signal in the syntax to
indicate which context the phrases belong to ... I mean, rules,
activities, actions, whatever; to avoid cross-contamination.
Emily Short
Jim Aikin wrote:
> > Now, I realize that many people, especially those coming to it from a
> > programming background who have some idea of what they want to do, will
> > not want to approach it that way, and will try to treat it as a
> > reference manual, and get Fairly Annoyed. Some of this we can alleviate
> > with better indexing and searching, as mentioned in earlier threads;
> > some of it, I hope, by putting a review of relevant topics at the
> > beginning of each chapter of the manual (perhaps in the form of an
> > example, the way Chapter 15 starts with a couple of examples reviewing
> > how to make new actions) and an overview of learned syntax at the end
> > of each. Which we're working on.
>
> Here's a concept: How about a whole chapter called "Inform 7 Quickstart
> Guide for Experienced Programmers"? It could cover things like:
I've been kicking around a similar idea for a while, but at the same
time I've been reluctant to do this exactly because it means that
experienced programmers will learn how to do what they could already do
in other languages, and not necessarily anything more; whereas I7 is
most interesting precisely for the features that cannot be easily
mapped back to another language. "Here is how to phrase what you did
before" is useful, sometimes -- but what's even more useful (and yet
much harder to teach in the abstract) is "here is how to *think* in I7
terms, so that you're leveraging the language from the outset."
If I were writing *that* guide, I might start with object and relations
in the abstract, and work my way up from there. But it would be a
fairly abstract discussion and probably a bit frustrating too, for
people who want to start writing their game right away:* I'm reminded
of a very good but very challenging calculus textbook I used, which
didn't present the student with any instructions about how to take
derivatives until it had already walked him through a bunch of
underlying theory. For a long time it felt like I was making no headway
at all.
* Though I think it might be good for people who want to start
*designing* their game right away.
Anyway, in case you want an answer to these now, rather than later
when/if this hypothetical guide is written:
> How to create something that operates like a function, and how to pass
> values to it and get values back.
> How to create and manipulate numeric variables.
> How to test the value of a variable in various contexts.
Chapters 4, 7, and 10 deal with most of the relevant points.
> How to start and stop a daemon.
You don't: I7 originally had daemons, but they were removed. Every turn
rules now handle any behavior that you want to have happen on their
own.
> How to assemble a highly variable room description, including calling a
> separate function to print alternative stuff in the middle of a sentence.
Again, not all in one place, but see Chapter 4.8 on text with
substitutions (and its examples, which explain how to write your own
substitution code); also perhaps the example in 8.15, "Infiltration."
Emily Short
ixnay wrote:
> "Jim Aikin" <rai...@musicwords.net> wrote in message
> news:ZneDg.4819$%j7....@newssvr29.news.prodigy.net...
>
> > Does anybody but me feel that Inform 7 is trying very hard to reinvent the
> > wheel? "Let's not call them spokes, let's call them radials. It's not a
> > hub, it's a center. It's not a tire, it's a rubber round. It's not an
> > axle, it's a rotator."
>
> I agree in some ways. Problem is it's the best choice you have really.
> (Except maybe for Inform 6.) TADS 3 appears to be dead. (Web site's last
> update says general release would happen in a couple months and that was
> dated "29 August 2005.")
Good heavens, no! TADS 3 is not dead; it is (as a number of people have
demonstrated) a viable language to use for writing games, and is still
in very active development as well.
Emily Short
Arnel Legaspi wrote:
> Jim Aikin wrote:
> > Man, if I could have this IDE with I6, I would fly to England and kiss
> > Graham's feet.
>
> I couldn't agree more, except the kissing Graham's feet part. :)
The Mac IDE does work with I6, FWIW. (Yes, I realize this doesn't help
everyone.)
Reiko
because we're not doing the *right* simple stuff. Or, as Emily put it,
we need to learn how to think in I7 terms and not in terms of the
languages we already know. It doesn't help so much to talk about global
variables and daemons and things like that when I7 does these things
differently.
~Reiko
Daryl McCullough
>Daryl McCullough wrote:
>I think the number of constructs in Inform's natural language is
>reasonably small. The problem is that they all look a great deal like
>*real* human natural language, and the number of constructs in *that*
>is huge.
That's sort of what I meant. The natural language gives the *impression*
of being able to handle much more than it actually can (this is the
same sort of illusion that natural language gives in actual
interactive fiction, although in the latter case, some people would
argue that the illusion serves the gaming experience).
>So ... for instance, yesterday I tried to write "list the contents of
>the room", and it took me a while to work out that I wasn't allowed to
>use "the" between "list" and "contents". Possibly you're right, and it
>would be better if the language looked a bit *less* natural,
>particularly when it comes to phrases that are the equivalent of
>keywords.
I'm not sure, but I *think* that a lot of the benefits of I7 for
the *programmer* could be had with a not-very-natural-language
syntax.
Daphne Brinkerhoff
ixnay wrote:
> "Jim Aikin" <rai...@musicwords.net> wrote in message
> news:ZneDg.4819$%j7....@newssvr29.news.prodigy.net...
>
> > Does anybody but me feel that Inform 7 is trying very hard to reinvent the
> > wheel?
>
> (Except maybe for Inform 6.) TADS 3 appears to be dead.
Emily Short answered this re: TADS 3. And may I just quote the
estimable Adam Thornton (March 22, 2004):
"Kent Tessman cries!"
(That is, there's other choices besides TADS/Inform. And it seems like
Hugo is pretty capable of anything people want to throw at it.)
--
Daphne
Jim Aikin
I'm not sure I agree.
I'm pretty sure it's a good thing when a new programming language allows or
encourages the author to think in new ways. But I think it's probably _not_
a good thing when a new programming language discourages the author from
doing familiar things by interposing barriers or requiring the abandonment
of existing techniques.
If you're a sculptor and you have a block of marble, would you want to work
in a workshop where there weren't any chisels or mallets? Okay, they've got
a laser system for mineral vaporization that accomplishes the same thing and
gives you even more precise control (plus, the lasers have algorithmic
auto-guidance procedures). But the tactility of the process of sculpting is
such that if you know chisels and mallets, you'll naturally prefer to use
them where you can, and only fire up the laser system for those times when
chisels and mallets won't do the job.
I think that's not too bad an analogy, actually.
--JA
steve....@gmail.com
and I can say definitely that Bad Jim and Bad Steve are pretty close on
this.
Jim Aikin wrote:
> I think it's probably _not_
> a good thing when a new programming language discourages the author from
> doing familiar things by interposing barriers or requiring the abandonment
> of existing techniques.
I've been trying to figure out *why* a programming language would do
that, since it seems, well, asinine. The best I have been able to
figure out is that Graham wants a glossy coat of NL on everything I7.
Why? I don't think it's for practical reasons. There's something more
like dogmatism at play here, system design from odd-principle. Graham
is very good at concealing, but I think you can figure out a lot by
looking very closely at the "extensions" part of the I7 docs,
particularly the part where he wants everybody to write in NL.
Emily Short
Jim Aikin wrote:
> But I think it's probably _not_
> a good thing when a new programming language discourages the author from
> doing familiar things by interposing barriers or requiring the abandonment
> of existing techniques.
Well, to be fair, at least for the things you've cited so far, my sense
is that the barrier comes more from the manual failing to inform you
than from an actual lack of options in the language. (Not that we
shouldn't still find a way to address it.)
Andrew Plotkin
> Jim Aikin wrote:
> > Man, if I could have this IDE with I6, I would fly to England and kiss
> > Graham's feet.
>
> I couldn't agree more, except the kissing Graham's feet part. :)
>
> This is more for historical curiosity: why was an I6 IDE like what I7
> has now never been made? Was it something related to the internal
> structure of I6?
Truly, the answer is "nobody thought of it". Assuming you're talking
about the skein/replay/two-window model of the IDE.
"Advanced" IF IDEs have historically tended to go off into a mix of
map-drawing UI and filling out forms to define objects. Nobody was
concentrating on what could be built on top of the source-code-and-
compiler model.
As Emily implied, the I7 IDE *is* compatible with I6 in theory, and
this will eventually be fully supported on all platforms.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because you're innocent.
vaporware
> First, Jim, I agree with everything you have written on this thread,
> and I can say definitely that Bad Jim and Bad Steve are pretty close on
> this.
Are you really trying to relate this to obscure metal bands
(http://www.rockdetector.com/artist,838.sm) and old movies
(http://www.imdb.com/title/tt0099092/), or are you just trying on a
martyr suit?
vw
Arnel Legaspi
> Truly, the answer is "nobody thought of it". Assuming you're talking
> about the skein/replay/two-window model of the IDE.
Just the right guy to answer the question! Thank you, Andrew.
I *was* thinking something along the lines of the HTML TADS Debugger
where one could both compile and run the source file all in one go,
plus the advantages of being able to set watchpoints, etc.
It could probably be done with batch files or with the source editor
software, of course, but still...
> "Advanced" IF IDEs have historically tended to go off into a mix of
> map-drawing UI and filling out forms to define objects. Nobody was
> concentrating on what could be built on top of the source-code-and-
> compiler model.
That is what I've seen here in RAIF, at least since 2000-2001 when I
started browsing the newsgroup through Google. I thought at least one
or two people might have attempted to write something like what I
described above just to facilitate compiling and testing, but I guess
not.
> As Emily implied, the I7 IDE *is* compatible with I6 in theory, and
> this will eventually be fully supported on all platforms.
I7's IDE works out well with me. At this point I guess it's best to say
"let's see what happens next."
Thanks again.
--Arnel
sdball
> <end code with comments>
I don't understand. Almost all programming languages require learning
new syntax. If I were going from C++ to perl, then it wouldn't matter
how many times I write 'int counter=0;' in perl it just wouldn't work
and it wouldn't be worth my time to sit down and try to reason out any
permutation of syntax that would make it work. I'd have to look it up
in a reference somewhere to learn that perl's variables aren't strongly
typed (a new way of thinking), and the the syntax for that particular
declaration would be '$counter=0;'
Inform 7 is a new language with a very new method of writing programs.
It is less than ideal for traditional programming tasks, but I'm
finding that its more than ideal for its very specific task of creating
interactive fiction. To me, being a new way of thinking about
programming and a new language, it's to be expected that the syntax
will take a while to learn and will be more difficult for the
experienced programmer than for the novice to pick up.
Just because Inform 7 is natural language programming doesn't mean that
it's automatically intuitive, you still have to learn how it all works.
Jim Aikin
> is that the barrier comes more from the manual failing to inform you
> than from an actual lack of options in the language. (Not that we
> shouldn't still find a way to address it.)
I agree that the manual needs to be fleshed out. (I'll send you a private
email with the notes I've taken so far.) I think that will ease the learning
curve a great deal.
I'm sure there are lots of options in I7 for doing sophisticated things.
Since I'm pretty much a bang-it-with-the-ball-peen-hammer programmer, that
doesn't concern me a great deal at this stage. What does concern me (see the
title of this thread) is the gracefulness or elegance with which one can
implement basic things.
I don't want to come off as an I7-basher here. I think perhaps one factor
that's leading us into a wrangle is the fact that this entirely new language
is called Inform. "Inform" is the name of an existing, highly successful IF
language, with which, at the user level, this new language has almost
nothing in common. The fact that it's called Inform leads people like me to
expect or hope for certain things that we wouldn't expect (though we might
hope for them) if it were called Ocelot or Teacup.
To be specific, I don't think the analogy I made yesterday was fair. It's
perfectly swell to open up a sculptors' studio in which all of the
marble-carving is done with lasers, and no chisels or hammers are to be
found. We, the user community, mustn't expect that new software releases
will forever carry along the baggage of older releases. Backwards
compatibility can become a nightmare for the developer, and there IS a point
at which any developer has to say, "Let's wipe the slate clean and start
fresh."
So comparisons, invidious or otherwise, with I6 are not appropriate, though
comparisons with other IF languages **in general** are certainly
appropriate, and I6 happens to be one of them.
Briefly, then, here are a few tentative observations I've made about the
user interface of natural-language programming after a week or two poking
around with Ocelot/Teacup 1.0b. I may be wrong on any of these points. I
bring them up strictly as an invitation to further dialogue:
1) Natural-language programming requires more typing than code. For those of
us who have issues with wrist tendons and tingling fingertips, this is not
desirable.
2) Text-based code is difficult to read, for several reasons. (a) There are
seldom any indentations to guide the eye. (b) There is a shortage of the
sort of punctuation (for instance (), [], {}, ::, and ==) that would clarify
the structure. (c) The fact that properties, values, names, and other
constructs are all referred to in similar ways has a sort of flattening or
blurring effect.
3) This is a more subtle point, but probably worth mentioning: The process
of creating IF involves two activities (coding and writing the prose that
will be read by the player) that are quite different intra-psychically. They
may actually use different parts of the brain. They're different first
because coding requires a narrower form of syntactic specificity and second
because the writer of prose can readily refer to complexities that are not
coded, don't need to be, and perhaps could not be. A system that forces the
IF author to write English sentences while coding pushes the syntax of the
natural-language code into the mental space usually reserved for prose
writing. The danger is that the author's prose may begin to resemble
textcode. It may come to read, that is, like bad Hemingway: "Jared is a
large man. Jared stands in the doorway glowering at you. He is holding a
revolver." Do we really want IF to go in this direction?
As an aside, the young Hemingway studied writing with Gertrude Stein.
"Natural language" textcode often reads very much like Stein. Consider this
from Example 54: "The ordinary rock is a rock." That's pure Stein.
A system in which code is code and prose is prose allows the author to
switch gears mentally, which will encourage or at least not impede the use
of more expansive forms of verbal expression.
I think there may be ways in which these issues could be addressed without
changing the underlying strengths of I7. For instance, the IDE could provide
syntax coloring for reserved words like "instead." (The coloring should be
switchable on and off with a single keystroke; otherwise the textcode will
look like tutti-frutti ice cream.) Since the textcode is already being
passed through a parser, you could allow the programmer to use braces and
stuff in place of keywords, thus making the code easier to read and easier
to type (though less "natural").
I also think we'll be moving forward if we look at I7 as a 1.0 release, not
as a 7.0 release. I look at new music software all the time, and I seldom
see a 1.0 release that can't benefit from some refinements, large or small.
(I earn decent money, in fact, by suggesting where those refinements could
be made.) If this discussion is to be healthy rather than carping, it will
be because it generates a helpful wishlist for the 1.5 release.
Anyway, that's what my brain told me to say about it. I'll be curious to
read others' comments.
--Jim Aikin
Jeff Nyman
news:1155485887.4...@b28g2000cwb.googlegroups.com...
> Just because Inform 7 is natural language programming doesn't mean that
> it's automatically intuitive, you still have to learn how it all works.
I think that sounds good in theory but one thing I am wrestling with in
terms of I7 is that natural language often *is* supposed to be intuitive.
That is why natural language interfaces are often crafted onto applications.
I have written natural language interfaces in terms of software quality
assurance solutions and, in all cases, it was meant to allow the person to
write things in their natural language (and usually converted to automated
testing tool code logic). The biggest hurdle I faced was determining how
people intuitively *think* about testing and writing test cases and then
attempt to accomodate that in terms of the natural language interface.
I see I7 doing largely the same thing, but on a much different scale than my
paltry efforts.
All this said, I agree with your substantive point: every language, even
those based on a natural language "front end", as it were, do require
learning and perhaps the intuition part should not be as expected as it is.
And, yet, that is bound to happen. Natural language is intuitive to people:
that is why it is their *natural* language. So people will bring their
intuitions to a natural language and I have found that either the system has
to accomodate that or make the language constructs so clear that the
separation of "true" natural language from the "contrived" natural language
is patently obvious. In other words, you have to show where people's
intuition (which is an inevitable component they bring with them) should not
be relied on.
- Jeff
Errant Thoughts
guy has to stop lurking sometime, right?)
Jim Aikin wrote:
> If you're a sculptor and you have a block of marble, would you want to work
> in a workshop where there weren't any chisels or mallets? Okay, they've got
> a laser system for mineral vaporization that accomplishes the same thing and
> gives you even more precise control (plus, the lasers have algorithmic
> auto-guidance procedures). But the tactility of the process of sculpting is
> such that if you know chisels and mallets, you'll naturally prefer to use
> them where you can, and only fire up the laser system for those times when
> chisels and mallets won't do the job.
>
> I think that's not too bad an analogy, actually.
Well, your "chisels and mallets" is to "Inform 6" as "auto-guided
lasers" is to "Inform 7" analogy (I'm hoping I got the correspondences
correct there) is OK as far as it goes.
But how would you complete this analogy: "tactility" is to "the process
of sculpting" as "?????" is to "the process of creating interactive
fiction"? Is the only way to fill in the blank something like:
"defining functions, and assigning values to variables, and writing
conditional statements and loops"? I hope not, because I'm no great
shakes at that kind of programming.
I'm no good at sculpting, either--all the auto-guided lasers in the
world wouldn't turn me into a sculptor. And using Inform 7 probably
won't make me into a programmer, but it just might let me become an
interactive fiction author.
Will I be a worse author than someone that knows how to use the
"chisels and mallets of I6/TADS"? Will I be missing out on some kind of
tactile, visceral programming experience by using natural language to
describe my imaginary objects and their relationships? I hope not.
(Now I'm going to look pretty silly if I never do write any IF, so I'd
better get back to experimenting with I7.)
--Errant.
Paolo Maroncelli
>I'm not sure, but I *think* that a lot of the benefits of I7 for
>the *programmer* could be had with a not-very-natural-language
>syntax.
We could also talk about internationalization. I think that in its present form
I7 is impossible to localize. Sure, one could play with localized libraries and
do some weird mix-up to obtain something, but I am talking about a fully
localized natural language interface.
Using a traditional programming language, one has no need to get a localized
version of statements and constructs: while, switch, for -- these words are
universally accepted all over the world.
But if we get involved with natural language programming, the NL interface has
to be localized.
Most of the non-english speaking foreign developers are certainly stuck in I6
realm.
PaoloM
ifnyou
> 2) Text-based code is difficult to read, for several reasons. (a) There are
> seldom any indentations to guide the eye. (b) There is a shortage of the
> sort of punctuation (for instance (), [], {}, ::, and ==) that would clarify
> the structure. (c) The fact that properties, values, names, and other
> constructs are all referred to in similar ways has a sort of flattening or
> blurring effect.
I just wanted to comment on this because the thing I think I like most
about I7 is the readability of the code. I'm very close to being a
nonprogrammer... a few years ago I started teaching myself Python,
which I made a little progress in but found frustrating because...
sometimes other aspects of my life take over for a week or two and so I
drop a project and then have to come back to it. I'd find I'd look at
the code I'd written two weeks ago and have no idea what it was or how
it worked. So I took to writing extremely verbose comments for each
little section of code, but this was slow and frustrating and still
didn't solve the problem, because then coming back to the work later
I'd find I could understand the comments just fine but I'd still need
to re-work through how the code actually was solving the problem.
When I played ROTA, I thought, great, this game is really close to
something I'd like to make, I wonder if I can make some use of the
source to create a variant? So, I downloaded and opened up the
source... and with a "cold" reading of code written by someone else in
a language I was minimally familiar with, I could understand just about
every line (well, at least before it gets to the Maze of Royal Beasts -
but even that I think doesn't terrify me in the way that a similar
thing in Python (or, heaven forfend, C) would). Now, why exactly some
things were done in the way they were done and not some other possible
way, I suppose I didn't (and still don't) understand. But I knew
immediately what each section was doing, and it was quick and easy to
see how it was doing it. Maybe it's just because my programming skills
are weak, but this was far better than I was able to do with code that
I had written myself (in Python), and that was doing much simpler work
than the code in ROTA is doing. And with what adds up to about four or
five hours work, I have a playable variant up and running (albeit, I
did get people on the forum to help with the hard bits - thanks guys!).
So, perhaps for stronger programmers than myself, code readability
really is a minus for I7, but for me, it gets all the ticks I can give
it. ;)
Neil Cerutti
> I don't want to come off as an I7-basher here. I think perhaps
> one factor that's leading us into a wrangle is the fact that
> this entirely new language is called Inform. "Inform" is the
> name of an existing, highly successful IF language, with which,
> at the user level, this new language has almost nothing in
> common. The fact that it's called Inform leads people like me
> to expect or hope for certain things that we wouldn't expect
> (though we might hope for them) if it were called Ocelot or
> Teacup.
I admit I'm uncomfortable with the name, too. But it was Graham's
prerogative. At least it wasn't called Inform 2006.
> To be specific, I don't think the analogy I made yesterday was
> fair. It's perfectly swell to open up a sculptors' studio in
> which all of the marble-carving is done with lasers, and no
> chisels or hammers are to be found. We, the user community,
> mustn't expect that new software releases will forever carry
> along the baggage of older releases. Backwards compatibility
> can become a nightmare for the developer, and there IS a point
> at which any developer has to say, "Let's wipe the slate clean
> and start fresh."
>
> So comparisons, invidious or otherwise, with I6 are not
> appropriate, though comparisons with other IF languages **in
> general** are certainly appropriate, and I6 happens to be one
> of them.
>
> Briefly, then, here are a few tentative observations I've made
> about the user interface of natural-language programming after
> a week or two poking around with Ocelot/Teacup 1.0b. I may be
> wrong on any of these points. I bring them up strictly as an
> invitation to further dialogue:
>
> 1) Natural-language programming requires more typing than code.
> For those of us who have issues with wrist tendons and tingling
> fingertips, this is not desirable.
Natural language is much easier to type than your run-of-the-mill
computer language. I don't have to reach for the symbols nearly
so often.
And in practice, despite how it might feel, Inform 7 codes tends
to be more concise than Inform 6.
> 2) Text-based code is difficult to read, for several reasons.
> (a) There are seldom any indentations to guide the eye. (b)
> There is a shortage of the sort of punctuation (for instance
> (), [], {}, ::, and ==) that would clarify the structure. (c)
> The fact that properties, values, names, and other constructs
> are all referred to in similar ways has a sort of flattening or
> blurring effect.
I agree with this. Scanning source code is slightly more time
consuming. But scanning Inform 6 code is only faster in proportio
to how often my code follows convention. Boilerplate--easy to
scan and understand. Any time the code does something odd--deep
reading is required.
There are a few humongous barnacles on Inform 6 that Inform 7
scraped away: ChooseObjects (sadly, not replaced with something
better), and parse_name (sadly, not really improved upon, but I
haven't had to write one yet), general parsing routines (not sure
if these are really dead, but I think so), scope hacking (easier
and much less error-prone in Inform 7).
> 3) This is a more subtle point, but probably worth mentioning:
> The process of creating IF involves two activities (coding and
> writing the prose that will be read by the player) that are
> quite different intra-psychically. They may actually use
> different parts of the brain. They're different first because
> coding requires a narrower form of syntactic specificity and
> second because the writer of prose can readily refer to
> complexities that are not coded, don't need to be, and perhaps
> could not be. A system that forces the IF author to write
> English sentences while coding pushes the syntax of the
> natural-language code into the mental space usually reserved
> for prose writing. The danger is that the author's prose may
> begin to resemble textcode. It may come to read, that is, like
> bad Hemingway: "Jared is a large man. Jared stands in the
> doorway glowering at you. He is holding a revolver." Do we
> really want IF to go in this direction?
One other person has suggested that this might be a problem. The
mental gear-shift required to write good prose is still present,
even when using a language that's more removed from natural
English, though. Coding in a subset of natural language may add
a new type of mental gymnastic to the process of designing IF.
I'm unsure.
> I also think we'll be moving forward if we look at I7 as a 1.0
> release, not as a 7.0 release. I look at new music software all
> the time, and I seldom see a 1.0 release that can't benefit
> from some refinements, large or small. (I earn decent money, in
> fact, by suggesting where those refinements could be made.) If
> this discussion is to be healthy rather than carping, it will
> be because it generates a helpful wishlist for the 1.5 release.
[OT] Ever used Mup from Arkkra Enterprises? I love it. Best $40 I
ever spent on a piece of music software. But you better enjoy
coding and have a good text editor before dipping in.
> Anyway, that's what my brain told me to say about it. I'll be
> curious to read others' comments.
Thanks for your thoughts.
--
Neil Cerutti
Gregory Weir
> I also think we'll be moving forward if we look at I7 as a 1.0 release, not
> as a 7.0 release. I look at new music software all the time, and I seldom
> see a 1.0 release that can't benefit from some refinements, large or small.
> (I earn decent money, in fact, by suggesting where those refinements could
> be made.) If this discussion is to be healthy rather than carping, it will
> be because it generates a helpful wishlist for the 1.5 release.
Actually, I was of the impression that I7 was still in the beta
process. It is, in fact, I7 0.3V01, if I understand the (unusual)
version numbers. Otherwise, I think we would see more people
complaining about the bugs that have yet to be ironed out.
Gregory Weir
http://ludusnovus.net
Daryl McCullough
>I just wanted to comment on this because the thing I think I like most
>about I7 is the readability of the code.
I think that I7 code is very readable *locally*, in the
sense that each line of code is understandable without
much effort and without even knowing much I7. On the
other hand, large sections of I7 can be pretty hard to
understand.
For example, the Emily Short game "Patient Zero"
The current actor is a person which varies. The current owner is a person which
varies.
Every turn:
if player is active, follow the character movement rules.
Every turn:
change the last person named to the player;
change the last thing named to the player;
now every person is active.
A person can be active or passive. The player is passive.
The character movement rules are a rulebook.
The first character movement rule:
change group size to 1;
change the last person named to the player;
change the last thing named to the player;
now the player is passive.
A character movement rule:
repeat with mover running through innocent people
begin;
change the current actor to the mover;
consider the shopper rules;
now the current actor is passive;
end repeat;
consider the movement reporting rule.
...
I'm not sure what would be the best language for
describing this game (perhaps an agent-based language?)
but it's far from clear what is going on.
Neil Cerutti
> A character movement rule:
> repeat with mover running through innocent people
> begin;
> change the current actor to the mover;
> consider the shopper rules;
> now the current actor is passive;
> end repeat;
> consider the movement reporting rule.
>
> describing this game (perhaps an agent-based language?)
> but it's far from clear what is going on.
It seems to be using rulebooks with non-functional names as
functions, by using global variables for parameters. It might be
hard to understand in any syntax:
[ CharacterMovement mover;
objectloop(mover ofclass person) {
if (mover has innocent) {
current_actor = mover;
Shopper();
give current_actor passive;
}
}
ReportMovement();
];
I think rulebooks make lousy functions.
--
Neil Cerutti
Potluck supper: prayer and medication to follow. --Church
Bulletin Blooper
Jason
> I read Graham's essay about the power of natural language, but
> I'm still not completely convinced. Basically, his argument amounts
> to an argument for more powerful programming constructs
> (for example, "now all nearby mice are frightened" instead
> of something like "loop over objects o: if o ofclass Mouse and
> location(o) = location(player) then give o frightened.") But
> do these more powerful constructs have to be expressed in
> natural language? I'm not convinced that it helps to do so.
Hmm... it depends on the feature.
At least some the "powerful constructs" in I7 come from Graham's study
of English grammar and semantics. They literally come straight out of
English. They are "expressed in natural language" not because "it
helps to do so", but because that's the only way that makes any sense:
the language design is already done, you see.
Take the phrase "all nearby mice". How would you like to see this
written? Maybe you would prefer something like mathematical
set-builder notation, "{m in allMice | isNearby(m)}". Or the
equivalent SQL, "select m from allMice where isNearby(m)". Each of
these is twice as long as the I7 equivalent, and for what? Was "all
nearby mice" unclear? Perhaps you want something like the Haskell
"filter isNearby allMice". But functional programming has its own
problems, not least of which is a reputation for being bloody
difficult. Frankly, I don't think anyone is going to improve on "all
nearby mice". It's clear, concise, and terribly useful.
To be fair, many other bits of I7 are more like AppleScript--only
superficially like English. But to answer your question, yes, I think
some features are expressed in natural language for a reason.
-j
Adam Thornton
No, it's still being actively developed.
The problem (from my perspective) is that it's very much in
polishing-obscure-bits-of-chrome mode, rather than "call it done,
finalize a manual, and release" mode (yes, I realize that the second
part is the hard part, and no, I'm not volunteering...but the problem
is, neither is anyone else, preferring to define new subclasses for
effects that simply are never going to be all that common, even *if*
well-supported--which they are--in the library).
Adam
Eric Eve
news:ebrela$q0m$1...@fileserver.fsf.net...
When you say "neither is anyone else" you seem to be dismissing the
considerable amount of work that went into writing Getting Started
in TADS 3 and the TADS 3 Tour Guide. All right, they're not manuals,
and they're not substitutes for an official manual produced by Mike
Roberts, but at least some people seem to have found them of some
use in learning TADS 3, and their existence should surely qualify
your comment that the rest of us are simply "preferring to define
new sublasses for effects that simply are never going to be all that
common".
Moreover, I can't speak for anyone else, but most of what I've
posted on the TADS 3 list over the last couple of years has arisen
from bugs and issues I've encountered in actually using TADS 3 to
write games. You can't seriously be suggesting that such issues
ought not to be reported.
-- Eric
Eric Eve
news:ebrt3m$b5d$1...@frank-exchange-of-views.oucs.ox.ac.uk...
> When you say "neither is anyone else" you seem to be dismissing
> the considerable amount of work that went into writing Getting
> Started in TADS 3 and the TADS 3 Tour Guide.
Lest I should seem to be equally guilty of dismissing the efforts of
others I should add that a number of people who post regularly to
the TADS 3 list have (a) indeed offered help with the writing of the
manual, (b) contributed technical articles or (c) posted TADS 3
hints and tips/tutorial material on their websites.
A few further observations:
(1) I think we are agreed that the current version of TADS 3
(3.0.9) is perfectly usable as it is (though I am aware of one of
two bugs I'd really like to see fixed; there's at least one that has
quite a serious potential impact on my WIP). Merely labelling it an
'official release' wouldn't change much.
(2) There is no shortage of existing documentation for people who
wish to get to grips with TADS 3 right now. In particular there's:
(a) The substantial language documentation that comes with TADS 3
(b) A collection of technical articles on using the system at
http://www.tads.org/articles.htm
(c) The proto-documentation produced by Edward Stauff's docgen
program.
(d) Getting Started in TADS 3
(e) The TADS 3 Tour Guide
(f) Various tips and hints on a number of websites.
These resources between them provide more than enough for someone
who wants to learn TADS 3 to get started with it. Perhaps the
problem is that's there's almost too much here, and that's
potentially a bit overwhelming. Of course it would be nice to have a
manual that provided a single point of reference, but 'Getting
Started' at least tries to help the beginner over the basic concepts
(if you don't think it does the job well enough, I'm always open to
suggestions on how it could be improved).
(3) No one is denying that an official TADS 3 manual would be
highly desirable, but it seems a little implausible to suggest (or
at least, imply) that its production is somehow being delayed by the
discussions that take place on the TADS 3 list (which have hardly
been substantial over the last many months, in any case). If the
official manuanl's taking a long time to appear, the reason is
presumably because it's a non-trivial task to write and the one
person who's in a position to write it is busy with other things. At
best the rest of us could only produce more unofficial documentation
that isn't the official manual, but that doesn't seem to be what you
want.
-- Eric
sdball
> All this said, I agree with your substantive point: every language, even
> those based on a natural language "front end", as it were, do require
> learning and perhaps the intuition part should not be as expected as it is.
> And, yet, that is bound to happen. Natural language is intuitive to people:
> that is why it is their *natural* language. So people will bring their
> intuitions to a natural language and I have found that either the system has
> to accomodate that or make the language constructs so clear that the
> separation of "true" natural language from the "contrived" natural language
> is patently obvious. In other words, you have to show where people's
> intuition (which is an inevitable component they bring with them) should not
> be relied on.
>
> - Jeff
My take on the NL aspect of Inform 7 is that the natural language
structure and grammar will make it easy to read and understand, not
that it will be easy to write.
Benefits:
- enables newbies to grasp, copy, and extend code from any source
pretty easily
- does a lot to prevent code rot because the code is almost always
(moreso than any other language I've worked with) self-documenting
- abstracts huge amounts of complexity behind a deceptively simple
syntax
Hindrance:
Programming in Inform 7, being deceptively simple, lulls the quick
learning programmer into assuming that they have a full grasp of its
syntax after a few basic examples. If a statement looks "Inform-like"
then it is frustrating to try and track down the error. I'm not sure
what could be done to alleviate this except to note the tendency early
in the manual. The improved manual linking/searching that seems to be
in the works would help as well.
steve....@gmail.com
> To be fair, many other bits of I7 are more like AppleScript--only
> superficially like English. But to answer your question, yes, I think
> some features are expressed in natural language for a reason.
Some features, sure. But all features?
To take your example, if you're doing object loops a lot, you could
easily write a macro or function that makes things a bit more compact
for you; you could even make it look English if you want. All well and
good.
But that NL-sounding programming constructs can work nicely sometimes
is a point distant to the question of the propriety of NLProgramming as
an absolute or thoroughgoing design principle. It is the latter that is
being debated, not the former.
Greg Boettcher
> The problem (from my perspective) is that it's very much in
> polishing-obscure-bits-of-chrome mode, rather than "call it done,
> finalize a manual, and release" mode (yes, I realize that the second
> part is the hard part, and no, I'm not volunteering...but the problem
> is, neither is anyone else, preferring to define new subclasses for
> effects that simply are never going to be all that common, even *if*
> well-supported--which they are--in the library).
This is just to reiterate Eric Eve's Point #3.
Suppose all the most knowledgeable TADS 3 programmers were to quit
their jobs and start working on the TADS 3 manual full time. Do you
think this would put an end to bug reports and feature requests?
I don't think so. Such an effort would require people to spend a lot
more time looking at the TADS 3 library. They would find more bugs than
they do now, and think of more features to request. Probably they would
mention such things at the TADS 3 group a lot more than they do now.
I suspect there's literally nobody who presently is not working on the
TADS 3 manual, but would be working on it if it weren't for all the bug
reports and feature requests going on in the TADS 3 group.
Greg
Jason
> To take your example, if you're doing object loops a lot, you could
> easily write a macro or function that makes things a bit more compact
> for you; you could even make it look English if you want.
I'm skeptical. An example would be enlightening, if you would be so
kind as to provide one.
> But that NL-sounding programming constructs can work nicely sometimes
> is a point distant to the question of the propriety of NLProgramming as
> an absolute or thoroughgoing design principle. It is the latter that is
> being debated, not the former.
You asked, perhaps rhetorically, "do these more powerful constructs
have to be expressed in natural language?" Take my response as an
answer (a qualified yes) to that specific question.
I'm not interested in taking a position on the larger question.
-j
Neil Cerutti
> Jason wrote:
>> To be fair, many other bits of I7 are more like
>> AppleScript--only superficially like English. But to answer
>> your question, yes, I think some features are expressed in
>> natural language for a reason.
>
> Some features, sure. But all features?
I can't think of any non-joke programming language that expresses
all its features in the same way. That's not a reasonable
question.
> To take your example, if you're doing object loops a lot, you
> could easily write a macro or function that makes things a bit
> more compact for you; you could even make it look English if
> you want. All well and good.
You're going to hurt your wrists with all that hand-waving.
> But that NL-sounding programming constructs can work nicely
> sometimes is a point distant to the question of the propriety
> of NLProgramming as an absolute or thoroughgoing design
> principle. It is the latter that is being debated, not the
> former.
The debate you claim to be having is silly. Even I7 doesn't use
natural language for everything. See the chapter on Tables, for
one example of many.
--
Neil Cerutti
Let us join David and Lisa in the celebration of their wedding
and bring their happiness to a conclusion. --Church Bulletin
Blooper
steve....@gmail.com
> > To take your example, if you're doing object loops a lot, you could
> > easily write a macro or function that makes things a bit more compact
> > for you; you could even make it look English if you want.
>
> I'm skeptical. An example would be enlightening, if you would be so
> kind as to provide one.
Ok, here's a rough prototype, again from your example:
First make an objLoop function, which takes a class and a stat, and
returns a list of all members of the class for which 'stat' is true:
objLoop(class, stat) {
local ret = [];
for(local obj = firstObj(class) ; obj ; obj = nextObj(class))
if(obj.stat)
ret += obj;
return ret;
}
Then make a macro substitution so that 'forall(class, stat)' expands to
'foreach(local obj in objLoop(class, stat))':
#define forall(class, stat) foreach(local obj in objLoop)
Then you can write such things as...
forall(Mouse, nearby)
mouse.attackPlayer();
(Assuming class Mouse defines nearby() { return canSee(gPlayerChar); }
or somesuch.)
If you're doing a lot of object loops, you may find this more
convenient than...
for(local mouse = firstObj(Mouse) ; mouse ; mouse = nextObj(Mouse))
if(mouse.nearby)
mouse.attackPlayer;
No doubt this simple sample can be improved, but I hope the quick
sketch is fair enough that you can glean the general idea.
> You asked, perhaps rhetorically, "do these more powerful constructs
> have to be expressed in natural language?"
I don't recall that being my question. Constructs like we're talking
about are not more powerful, just slightly less typing (though I7 in
general is indisputably verbose). But clearly there's no necessity to
write in "NL," any more than there is to write in *English* in
particular.
> Take my response as an
> answer (a qualified yes) to that specific question.
That NL *can* be usefully appropriated into a formal syntax, yes of
course. Break, while, foreach, not in, else....
> I'm not interested in taking a position on the larger question.
That's cool. I just wanted to notice that they're two very different
issues.
steve....@gmail.com
Neil Cerutti wrote:
> On 2006-08-15, steve....@gmail.com <steve....@gmail.com> wrote:
> > Jason wrote:
> >> To be fair, many other bits of I7 are more like
> >> AppleScript--only superficially like English. But to answer
> >> your question, yes, I think some features are expressed in
> >> natural language for a reason.
> >
> > Some features, sure. But all features?
>
> I can't think of any non-joke programming language that expresses
> all its features in the same way. That's not a reasonable
> question.
I don't understand what you mean. Could you elaborate please?
Jason has made the excellent (if obvious) point that NL-constructions
are good syntax for certain procedures. I have said that making the
"whole syntax" NL is quite another issue.
> You're going to hurt your wrists with all that hand-waving.
I think this is a joke, and I hope a friendly one. (I'm sure I'd like
the joke if I understood it.)
But anyway, "hand-waving" (as far as I know) normally means that
someone is "gesturing" rather than saying something precise. Is that
the point? If so, please indicate where you would like some further
explanation.
> > But that NL-sounding programming constructs can work nicely
> > sometimes is a point distant to the question of the propriety
> > of NLProgramming as an absolute or thoroughgoing design
> > principle. It is the latter that is being debated, not the
> > former.
>
> The debate you claim to be having is silly. Even I7 doesn't use
> natural language for everything. See the chapter on Tables, for
> one example of many.
You are of course correct. There is nevertheless an overwhelming NL
aesthetic driving the syntax and system design. I'm sure you see that.
Please kindly understand that this is what I'm referring to, and please
kindly recognize that the debate is not merely silly.
Adam Thornton
Eric Eve <eric...@NOSPAMhmc.ox.ac.uk> wrote:
>When you say "neither is anyone else" you seem to be dismissing the
>considerable amount of work that went into writing Getting Started
>in TADS 3 and the TADS 3 Tour Guide. All right, they're not manuals,
>and they're not substitutes for an official manual produced by Mike
>Roberts, but at least some people seem to have found them of some
>use in learning TADS 3, and their existence should surely qualify
>your comment that the rest of us are simply "preferring to define
>new sublasses for effects that simply are never going to be all that
>common".
Consider it qualified. And PUBLICIZE those guides! Announce the URLs
when you mention them.
>Moreover, I can't speak for anyone else, but most of what I've
>posted on the TADS 3 list over the last couple of years has arisen
>from bugs and issues I've encountered in actually using TADS 3 to
>write games. You can't seriously be suggesting that such issues
>ought not to be reported.
Sure, report 'em.
But honestly, the language has been basically mature since the
SmoochieComp! Release. Release a point version to fix the little bugs
like a candle, carried inside a permeable but opaque container, when
coated in an oily, rather than a watery substance, doesn't respond
appropriately to a gust of breathable-but-aesthetically-unpleasant
vapor.
Adam
Eric Eve
> In article <ebrt3m$b5d$1...@frank-exchange-of-views.oucs.ox.ac.uk>,
> Eric Eve <eric...@NOSPAMhmc.ox.ac.uk> wrote:
>>When you say "neither is anyone else" you seem to be dismissing
>>the
>>considerable amount of work that went into writing Getting Started
>>in TADS 3 and the TADS 3 Tour Guide. All right, they're not
>>manuals,
>>and they're not substitutes for an official manual produced by
>>Mike
>>Roberts, but at least some people seem to have found them of some
>>use in learning TADS 3, and their existence should surely qualify
>>your comment that the rest of us are simply "preferring to define
>>new sublasses for effects that simply are never going to be all
>>that
>>common".
>
> Consider it qualified. And PUBLICIZE those guides! Announce the
> URLs
> when you mention them.
Sure; for anyone that doesn't already know:
http://users.ox.ac.uk/~manc0049/TADSGuide/intro.htm.
-- Eric
Jeff Nyman
> (3) No one is denying that an official TADS 3 manual would be highly
> desirable, but it seems a little implausible to suggest (or at least,
> imply) that its production is somehow being delayed by the discussions
> that take place on the TADS 3 list (which have hardly been substantial
> over the last many months, in any case). If the official manuanl's taking
> a long time to appear, the reason is presumably because it's a non-trivial
> task to write and the one person who's in a position to write it is busy
> with other things.
Just to add my two cents, for what it is worth: I totally agree with Eric on
this.
In fact, I am comparing I7 and TADS 3 in an attempt to write the start of
the same game in both to learn (on the topic of this thread) how "hard" it
is to do "simple stuff" and (hopefully) how easy it is to do hard stuff.
Regarding the manual and Eric's point above, just in terms of my own
learning of TADS 3, I can only imagine how difficult it would be to write a
full manual for TADS 3. There are so many things to consider. Personally,
however, I have found the comments in the library source code to be largely
very useful. (The documentation browser that Eric mentions helps
considerably in this.)
I also found going through sample full games in TADS 3 is actually more
helpful than it is in Inform 7. For example, going through "Square Circle"
or "Return to Ditch Day" with the Javadoc-like documentation is actually
easier than going through, say, "Bronze" or "When In Rome" for Inform 7.
That said, the Inform 7 manual contains so many helpful examples that I find
it is easier to learn Inform 7 by just browsing those and applying. So I
think, in its current state, TADS 3 *needs* a manual less than Inform 7 (but
agree with others who say an official manual is no doubt desirable).
In any event, I find that I can supplement the lack of a manual in TADS 3
much easier than I probably could a lack of a manual in Inform 7.
If there were volunteer points to help write the TADS 3 manual, I would be
glad to volunteer to help as I find the challenge of TADS 3 in this regard
to be daunting but exciting.
- Jeff
Chephren
Jeff Nyman wrote:
> In fact, I am comparing I7 and TADS 3 in an attempt to write the start of
> the same game in both to learn (on the topic of this thread) how "hard" it
> is to do "simple stuff" and (hopefully) how easy it is to do hard stuff.
>
Reading your post, it made me thing it might be interesting to port
some of the examples from the inform7 manual to tads3. Both as a
learning exercise and as an interesting comparison. If I ever get
round to learning I7, I might try that. It would be particularly
interesting to see how tads3 handles examples that make use of I7's
relational logic.
Jason Orendorff
> Jason wrote:
> > > To take your example, if you're doing object loops a lot, you could
> > > easily write a macro or function that makes things a bit more compact
> > > for you; you could even make it look English if you want.
> >
> > I'm skeptical. An example would be enlightening, if you would be so
> > kind as to provide one.
>
This is about what I expected. Among the things it can't say:
a person who is affected by web
armour which is worn by someone (called the victim)
the scariest hostile monster in the location
a leaf which is part of the branch
These are taken from a real game.
> > You asked, perhaps rhetorically, "do these more powerful constructs
> > have to be expressed in natural language?"
>
> I don't recall that being my question.
Pardon me, it wasn't you; it was the person I was originally writing
to, Mr McCullough.
-j
Daryl McCullough
Jason says...
>At least some the "powerful constructs" in I7 come from Graham's study
>of English grammar and semantics. They literally come straight out of
>English. They are "expressed in natural language" not because "it
>helps to do so", but because that's the only way that makes any sense:
>the language design is already done, you see.
I agree that the constructs "come straight out of English". That
*doesn't* imply that natural language is the only way to express
them that makes any sense, or that it is the best way to express
them. "the language design is already done" isn't really relevant.
Human natural languages were developed for a specific purpose,
which was communication with *humans*. Humans use real world
knowledge to disambiguate what they hear. They are enormously
tolerant of ungrammatical utterances. In contrast, compilers
and interpreters are notoriously brittle. If you use the wrong
syntax, they break. That's as true of Inform 7 as it is of a
more traditional compiler/interpreter.
>Take the phrase "all nearby mice". How would you like to see this
>written? Maybe you would prefer something like mathematical
>set-builder notation, "{m in allMice | isNearby(m)}". Or the
>equivalent SQL, "select m from allMice where isNearby(m)". Each of
>these is twice as long as the I7 equivalent, and for what?
I don't care about the *concrete* syntax, I care about the
abstract syntax and the semantics. I want to know what is
possible and how it can be expressed. In the case of Inform 7,
I'm not sure whether "now all nearby mice are frightened"
is legal or not (I don't think so). There are many, many
ways that such a condition could be expressed in English,
but only a tiny subset will be accepted and correctly
understood by Inform 7. Figuring out what that subset
is the problem.
>Was "all nearby mice" unclear?
Not to *me*, but it is unclear to Inform 7. The problem of programming
can be characterized as
1. Deciding what you want the program to do.
2. Figuring out how to express it in the programming language.
3. Later, in the maintenance phase, doing the reverse: you look
at the code and try to figure out what it was the programmer
intended to do.
Using Inform 7 makes step 3 much easier. With very little training,
you can read I7 code and understand what is meant.
Using natural language in my opinion makes step 2 *harder* rather
than easier. If it were *really* the case that
Express what you want in English, and Inform 7 will do what you
want.
then using natural language would be a big win. However, I don't
think that's the case. I don't think it *can* be the case without
something like AI.
>Frankly, I don't think anyone is going to improve on "all
>nearby mice". It's clear, concise, and terribly useful.
But it doesn't actually work in Inform 7, so that's not actually
an argument in favor of I7's use of natural language.
Jason Orendorff
> I'm not sure whether "now all nearby mice are frightened"
> is legal or not (I don't think so).
Oh, sure it is. You do have to tell Inform what you mean by "nearby",
"mice", and "frightened":]
Definition: A thing is nearby if the location of it is the location of
the player.
The plural of mouse is mice. A mouse is a kind of animal.
An animal can be frightened.
[...but having done this, you can say things like:]
Before doing anything to a mouse:
now all nearby mice are frightened.
[The rest of a sample program is provided, just for fun. LOOK AT MOUSE
will provoke the desired reaction.]
After printing the name of a frightened mouse, say " (quivering in
abject terror)". After printing the plural name of a frightened mouse,
say " (quivering in abject terror)".
The Basement is a room. In the Basement are two mice. South of the
Basement is the Narrow Crawl. In the Crawl is a mouse. South of the
Narrow Crawl is the Abandoned Subway Station. In the Station are
twelve mice.
[j]
steve....@gmail.com
Jason Orendorff wrote:
> > > An example would be enlightening, if you would be so
> > > kind as to provide one.
> >
> > Ok, here's a rough prototype [...forall() prototype omitted...]
>
> This is about what I expected.
I take that as good news. If you can anticipate the example, it's a
good sign that you understand my idea.
> Among the things it can't say:
> a person who is affected by web
> armour which is worn by someone (called the victim)
> the scariest hostile monster in the location
> a leaf which is part of the branch
Certainly. (Of course you recognize that I intentionally wrote a
limited-purpose algorithm, for the sake of quick example.) It would be
equally easy to write functions and macros to handle your additional
examples (and all other object-loop stuffs), and *most* other things
that I7 provides.
The upshot is that you can pretty easily write your own syntax sugar as
needed. I7 is not *relatively* powerful because its built-in sugar can
be put to good use; it is only arguably *relatively* powerful if it
allows directives which are difficult to reproduce without considerably
more work.
Note that some stuff that I7 provides gets considerably trickier, and
you need some more sophisticated algorithms to handle it -- in some
areas it is arguably *relatively* powerful. There's at least a couple
kinds of basic search algorithms in I7, trivial by professional
standards, but extremely difficult for a beginner; and the main rule
search is arguably non-trivial. The most complicated procedure of all
is (for me) the least wanted and the least useful: the parse-layer. I
encounter that latter as a great loss of power.
(For quite different reasons, I consider rule-based programming as also
a great loss, of procedural oversight. That combined with a parse-layer
that obscures the underlying structure of the program, and it's just
yuck. But it happens that I'm biased, and I am certainly not a genius
programmer, so don't take my hobby-horse too seriously.)
Jon Rosebaugh
> yuck. But it happens that I'm biased, and I am certainly not a genius
> programmer, so don't take my hobby-horse too seriously.)
Don't worry; we haven't been.
steve....@gmail.com
> [C]ompilers
> and interpreters are notoriously brittle. If you use the wrong
> syntax, they break.
I'd like to point out that this is by design; breakage is not so much
"notorious" as it is "inevitable," or better, "necessary and useful."
In other words, we *want* compilers to break (or flag) when they
encounter something even conceivably problematic. The science is in
figuring out how to make the breakage more useful.
> I want to know what is
> possible and how it can be expressed.
And the best way to do this is to learn a new specialized syntax -- and
definitely not to confuse it with a syntax you already know in an
entirely different and radically unrelated context.
> In the case of Inform 7,
> I'm not sure whether "now all nearby mice are frightened"
> is legal or not (I don't think so).
Ok, so it happens that your guess is wrong. My guesses about what I7
will understand are almost always wrong. That tendency is a mark
against the practical usability of I7.
> The problem of programming
> can be characterized as
>
> 1. Deciding what you want the program to do.
> 2. Figuring out how to express it in the programming language.
> 3. Later, in the maintenance phase, doing the reverse: you look
> at the code and try to figure out what it was the programmer
> intended to do.
>
> Using Inform 7 makes step 3 much easier.
The actual code only tells you what the programmer did. The *comments*
tell you what the programmer *intended* to do.
Jason Orendorff
> Jason Orendorff wrote:
> > Among the things it can't say:
> > a person who is affected by web
> > armour which is worn by someone (called the victim)
> > the scariest hostile monster in the location
> > a leaf which is part of the branch
>
> Certainly. (Of course you recognize that I intentionally wrote a
> limited-purpose algorithm, for the sake of quick example.) It would be
> equally easy to write functions and macros to handle your additional
I have trouble believing this; I think as you add cases, macros get
worse. I wouldn't be able to write a macro for "the scariest hostile
monster in the location" and keep a straight face. I mean,
getObjByMaxattrFlagClassAndLoc()? Get real.
> The upshot is that you can pretty easily write your own syntax sugar as
> needed.
*frown* This seems disingenuous to me. Sure, you *can* write a ton of
macros--but there are good reasons why you don't. I expect you know
them as well as I do.
> I7 is not *relatively* powerful because its built-in sugar can
> be put to good use; it is only arguably *relatively* powerful if it
> allows directives which are difficult to reproduce without considerably
> more work.
What is power in a programming language? The ability to express ideas
as code. Quickly, clearly, correctly. I believe brevity helps all
three.
Check out this thread:
http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/3e03b48dcfc7db4e/
The poster wanted to prevent the player from wearing two hats at once.
The answer: 24 lines of TADS 3 code, not counting comment lines and
such. The equivalent I7 is only 9 lines:
----
A hat is a kind of thing. Hats are always wearable.
Before wearing a hat when the person asked is [already] wearing
a hat (called the old hat):
if the person asked is the player,
say "(first taking off [the old hat])";
silently try the person asked trying taking off the old hat;
if the person asked is [still] wearing the old hat,
stop the action.
Home is a room. A bowler, a fedora, and a sombrero are hats in Home.
----
I find this surprising--and compelling.
A few random comments about this:
- The TADS version spends 7 lines on the curHat method alone. For some
reason the author didn't just use a macro.
- Neither solution is what I would call "easy"; they both work closely
with some rather complex machinery.
- I7 could clearly benefit from some simple things TADS has:
"[You/He]", "[You're/They're]", "implicitly try ...". I hope this will
come with time.
> Note that some stuff that I7 provides gets considerably trickier, and
> you need some more sophisticated algorithms to handle it -- in some
> areas it is arguably *relatively* powerful.
I'm not sure what you're referring to here. What stuff?
-j
signwriter
> The most complicated procedure of all
> is (for me) the least wanted and the least useful: the parse-layer.
If you don't want a parsing layer, why on earth would you choose to
program in Inform at all?
Granted, it's possible to write programs in it which are not works of
IF, but given that it's specifically intended to address the
difficulties of both parsing and of relating parsed input to a world
model, complaining that you don't want that seems...a little odd.
Given that nobody is *obliged* to program in Inform by commercial
necessity or management edict - if Inform is not the right tool for your
problem, *you* picked the wrong tool. It's not Inform's fault.
steve....@gmail.com
> I think as you add cases, macros get
> worse. I wouldn't be able to write a macro for "the scariest hostile
> monster in the location" and keep a straight face. I mean,
> getObjByMaxattrFlagClassAndLoc()?
Heh. You're right of course -- one wouldn't want to write a lot of
highly specialized macros and functions, but would much rather work
towards a few general ones. I appreciate you challenging me to do this
(but please note that I am certainly not the expert on this stuff!).
Anyway, I think you would want to decompose the command into combinable
simples: for your example, the simples might be 1) getting all the
objects of a class which satisfy a given condition or conditions (e.g.,
they are in a specific location and hostile), and 2) selecting from a
list the object which has the highest value for a given property.
So following this logic, there will be two operations, and so a
reasonable sugar-syntax might be:
objLoop(Monster, hostile, location == startRoom).most(scary)
First, 'loop(cls, condList)' would need to expand to to the familiar
firstObj/nextObj loop, the interior of which would check each condition
in turn. I think the following should work (though I'm sure all this is
improvable):
#define objLoop(cls, condList...) (new function() { \
local ret = []; \
for(local obj = firstObj(cls) ; obj ; obj = nextObj(cls)) { \
if(condList#foreach : obj.condList : && :) \
ret += obj; \
} \
return ret; } \
)
The "most" macro is very easy if your language has a sort() method,
though it's also pretty easy to write one:
#define most(prop) sort(true, { a, b: a.prop - b.prop })[1]
But again, I don't think syntactic sugar actually makes the language
more powerful or expressive. I mean, if it were opening doors to new
capabilities, that would be something really neat. But I look at this
kind of thing as minor convenience stuff.
Personally, I used to hate macros and templates -- any convenience
gloss -- vastly preferring to see the machinery I'm dealing with. I'm
still not a huge fan, but I don't mind them so much any more. In fact,
I think you've convinced me that a 'useful loops' extension would be a
nice project for TADS 3.
> What is power in a programming language? The ability to express ideas
> as code. Quickly, clearly, correctly. I believe brevity helps all
> three.
Yes certainly: taken by itself, brevity is good. Any argument against
brief code will *not* be simply that "it's brief and we don't like
brevity."
Eric Eve
> http://groups.google.com/group/rec.arts.int-fiction/browse_thread/thread/3e03b48dcfc7db4e/
>
> The poster wanted to prevent the player from wearing two hats at
> once.
> The answer: 24 lines of TADS 3 code, not counting comment lines
> and
> such. The equivalent I7 is only 9 lines:
>
> ----
> A hat is a kind of thing. Hats are always wearable.
>
> Before wearing a hat when the person asked is [already] wearing
> a hat (called the old hat):
> if the person asked is the player,
> say "(first taking off [the old hat])";
> silently try the person asked trying taking off the old hat;
> if the person asked is [still] wearing the old hat,
> stop the action.
>
> Home is a room. A bowler, a fedora, and a sombrero are hats in
> Home.
> ----
But in fairness the TADS 3 code *could* have been a lot more
compact. This would have done the job:
class Hat: Wearable
actionDobjWear(){
local wornHat = gActor.contents.valWhich({x: x.ofKind(Hat)
&& x.wornBy==gActor});
if(wornHat != nil)
tryImplicitAction(Doff, wornHat);
inherited;
}
;
startRoom: Room 'Home'
;
+ blackHat: Hat 'black hat*hats' 'black hat'
;
+ whiteHat: Hat 'white hat*hats' 'white hat'
;
-- Eric
steve....@gmail.com
> I think the following should work [...]
So happens it didn't, but I figured out the problem, and refactored it
to make lighter use of macros, which is always a good idea:
/* objLoop calls our internal method 'objLoop_', after converting each
* condition to an anonymous function.
* e.g., objLoop(Thing, isOpen) -> objLoop_(Thing, {x: x.isOpen})
*/
#define objLoop(cls, condList...) objLoop_(cls, \
condList#foreach~ {x: x.condList}~,~ )
/* take a class 'cls' and a set of functions, and return a list of
* objects whose class is 'cls' and which satisfy all the functions.
*/
function objLoop_(cls, [funcList]) {
local ret = [];
outerLoop:
for(local obj = firstObj(cls) ; obj ; obj = nextObj(obj, cls))
{
foreach(local func in funcList) {
if(!func(obj))
continue outerLoop;
}
ret += obj;
}
return ret;
}
It's still probably not ideal, but it works anyway.
> #define most(prop) sort(true, { a, b: a.prop - b.prop })[1]
That need not be a macro at all. I'd probably prefer...
modify List
most(prop) { return sort(true, {a, b: a.prop - b.prop})[1]; }
;
...though of course you need to pass 'prop' as a pointer when calling
this method.
Jason Orendorff
> Jason Orendorff wrote:
> > I think as you add cases, macros get
> > worse. I wouldn't be able to write a macro for "the scariest hostile
> > monster in the location" and keep a straight face. I mean,
> > getObjByMaxattrFlagClassAndLoc()?
>
> Heh. You're right of course -- one wouldn't want to write a lot of
> highly specialized macros and functions, but would much rather work
> towards a few general ones. I appreciate you challenging me to do this
> (but please note that I am certainly not the expert on this stuff!).
Well, you were using the word "easy" pretty freely. It's only fair.
:) Thanks for taking the time to write this. I'll comment on your new
thread when I get the chance.
My closing thoughts on this thread:
- We have a different opinion of concrete syntax generally. My view is
this: Usability matters; affordances matter; therefore concrete syntax
matters.
- PL concrete syntax design is a nontrivial problem. The really
interesting PLs-- I'm thinking of things like Scheme, Prolog, and
Haskell-- all have a unique view of the universe that is going to be
very challenging to anyone who has mostly done procedural and OO
programming. It would be possible to describe how a Scheme programmer
solves problems without resorting to concrete code-- but I believe
there's a quale there which you just don't get without seeing, reading,
doing. Concrete syntax determines what all those experiences are like.
- Noun phrases are the product of a linguistic evolution that was
basically finished thousands of years before we were born. The syntax
isn't merely interesting. It's the best concrete syntax for the
abstract concept it represents. Period. You're not going to beat it.
(Well, arguably. My assumption here is that evolution is smarter than
engineers, which I think ought not be controversial.) The only
question is whether the abstract concepts underlying NL are the ones
you want for the problems at hand. If you need to join 15 SQL tables
to get your answer, probably not. If you're interested in describing
and modeling the interaction of people and things in the everyday world
(IF, that is), then you are fortunate: that is the problem domain for
which English is optimized.
I'll leave you with this:
the scariest hostile monster in startRoom
objLoop(Monster, hostile, location == startRoom).most(scary)
The formal syntax of the I7 version is very similar to that of English:
np ::= determiner* adjective* noun (prep-phrase | dep-clause)*
Some interesting (and halfway relevant) bits of English grammar:
http://www.ucl.ac.uk/internet-grammar/determin/ordering.htm
http://www.ucl.ac.uk/internet-grammar/adjectiv/ordering.htm
> But again, I don't think syntactic sugar actually makes the language
> more powerful or expressive. I mean, if it were opening doors to new
> capabilities, that would be something really neat. But I look at this
> kind of thing as minor convenience stuff.
That misses the mark. PL features help not by opening up new
capabilities (the Turing-complete languages are after all theoretically
equivalent in that regard) but by changing the way we think. Syntax
determines what is convenient, that is all: and to the programmer, that
is everything.
> I think you've convinced me that a 'useful loops' extension would be a
> nice project for TADS 3.
Great! I am quite fond of query-expressions; I always like to see them
in new places.
The abstract idea here that you like is not new. What I see as new
about I7's noun phrases is not the abstract idea (we have list
comprehensions in Haskell and Python, and query-expressions in SQL,
XQuery, and C#; surely Graham is aware of the similarities) but the
concrete syntax. The experience of using an I7 noun phrase is, I
assure you, quite different from writing an equivalent LINQ
query-expression.
[j]
Daryl McCullough
>- Noun phrases are the product of a linguistic evolution that was
>basically finished thousands of years before we were born. The syntax
>isn't merely interesting. It's the best concrete syntax for the
>abstract concept it represents. Period. You're not going to beat it.
I think there are two different issues having to do with the usability
of a particular syntax: (1) Given an expression in that syntax, how
hard is it for you to figure out what it means. (2) Given an intended
meaning, how hard is it for you to express that meaning.
Using a subset of natural language is a big help for issue (1). We
*already* know what natural language means. However, it's not clear
that it is a big help for issue (2). Why not? Because it is only a
*subset* of natural language. We can very easily formulate what we
want to say into natural language, but not every expression in natural
language will be understood by the compiler. So we have to do two
things: (A) figure out what we want to say, and then (B) figure out
a paraphrase that will be understood by the compiler.
Task (B) is not, in my opinion, helped by using natural language
unless it is either a very simple subset of natural language (so
that it is immediately clear when you have ventured outside of
what can be understood), or it is a very large subset of natural
language (so that almost everything you try to say is actually
understood).
Your examples don't really address this issue. You give the
example of
"the scariest hostile monster in startRoom"
That's certainly clear and easy to understand, which addresses
issue (1), but I don't see how it addresses issue (2). For
issue (2) (how easy is it to generate expressions that are
what you mean and are also understood correctly by the compiler)
you need to show that it is easy to learn which subset
of natural language will be understood by the compiler.
An example that came up with me recently is the use of timers.
It's easy enough in Inform 7 to say something like:
Instead of burning the bomb:
say "You light the fuse.";
The bomb explodes in five turns
from now.
When the bomb explodes: Say "Kaboom!";
remove the bomb from play.
That's perfectly clear, from the point of view of issue (1).
However, suppose you want to have a condition of the form
If the bomb has exploded then ...
Inform 7 will have *no* idea what you are talking about.
That's because "the bomb explodes" is treated by I7
as the name of an event, not as a sentence with subject "bomb"
and predicate "explodes". You could just as well have said
"Kablooy fitzumi in five turns from now".
In my opinion, a less "natural" syntax would make it much
clearer what is going on.
Jason Orendorff
http://groups.google.com/group/rec.arts.int-fiction/msg/1f013988a7621c53
> [too much really well-thought-out stuff to quote in entirety]
Excellent post.
I mostly agree. The problem, as you rightly argue without actually
claiming, is that some NL aspects of I7 actually *hurt* both deep
readability (in the sense of deep understanding, the sort needed for
debugging) and writeability (on all levels).
> [...] So we have to do two
> things: (A) figure out what we want to say, and then (B) figure out
> a paraphrase that will be understood by the compiler.
>
> Task (B) is not, in my opinion, helped by using natural language
> unless it is either a very simple subset of natural language (so
> that it is immediately clear when you have ventured outside of
> what can be understood), or it is a very large subset of natural
> language (so that almost everything you try to say is actually
> understood).
Great--this is exactly the right ground for this discussion. Here's
where we start to disagree a bit. What is necessary is that the
boundary between what works and what doesn't work be clear and easily
picked up. I don't think "very simple" necessarily follows from that;
I don't think "very large subset" is the right criterion either; and in
any case I don't think "simple" means "not enough", even when talking
about NL.
For example, I don't think I7 needs subjunctive mode, or anticipatory
"it", or questions. Nor do I think it needs a large built-in
vocabulary. Nor should it try to disambiguate between homographs. All
these are fundamental features of English, but these and many others
may be usefully omitted.
So "very large" isn't really the requirement. What's needed is some
chunk of grammar that's useful, coherent, and comprehensible, that
doesn't have you constantly wondering "hmmm, can I say that?" Which I
believe to be possible, even if I7 isn't the best example at present.
Earlier today I posted something about how rules, noun phrases,
sentences, boolean properties, relations, pattern matching, and guards
all have strong synergy in I7. That group of features is neither "very
simple" nor "very large", but they all make sense together, and after
using them for a while, I feel it's pretty obvious what is and isn't
possible. Other parts of I7 give me trouble. But I see no reason the
rest of the language necessarily *must* be murky and confusing.
Graham has tried a lot of things at once. There are some hits and some
misses.
> Your examples don't really address this issue. You give the
> example of
>
> "the scariest hostile monster in startRoom"
>
> That's certainly clear and easy to understand, which addresses
> issue (1), but I don't see how it addresses issue (2). For
> issue (2) (how easy is it to generate expressions that are
> what you mean and are also understood correctly by the compiler)
> you need to show that it is easy to learn which subset
> of natural language will be understood by the compiler.
It's inconvenient that I7 is the specimen we have to argue over. :) My
experience with I7 is that the best features, like yes/no properties,
are easy to pick up from example and use; you try things and they just
work (can I say "things which are not lighted"? yes!), and so on.
This is no different from VB; how many people learn that by examining
the formal grammar? Is there even such a thing?
Yet I7 as a whole is hard. I believe this is largely because it's
inconsistent in how much English it understands.
For example, I7 understands relational verbs ("carries", "supports",
"is affected by") quite well, but action verbs not so much.
Another example: I7 can learn new nouns, adjectives, verbs, and
prepositions; but then when you name something, I7 ignores all the
vocabulary you've taught it and treats the name as a bag of completely
meaningless words. ("A large spicy meal" is neither spicy nor a meal,
even if you've previously said "A meal is a kind of thing. A meal can
be spicy.")
Another example: you can't use noun phrase syntax with table rows. You
can't ask for "a row in the Table of Conversation which has a state-id
entry of 13"; you must instead remember the exact words of the
particular phrase for searching tables.
All of these are problems of consistency in language design. It's not
that I7 needs to parse more or less English overall. Mostly it just
needs to be consistent.
> An example that came up with me recently is the use of timers.
> It's easy enough in Inform 7 to say something like:
> [...]
> When the bomb explodes: Say "Kaboom!";
> [...]
> However, suppose you want to have a condition of the form
>
> If the bomb has exploded then ...
>
> Inform 7 will have *no* idea what you are talking about.
> That's because "the bomb explodes" is treated by I7
> as the name of an event, not as a sentence with subject "bomb"
> and predicate "explodes". You could just as well have said
> "Kablooy fitzumi in five turns from now".
Wonderful example. These cases where I7 *allows* stuff that *looks*
like English--but might as well be gibberish for all I7 cares--these
cases muddy the waters a great deal.
But the problem here is a mismatch between the degree of NL
understanding (on the part of the compiler) and the degree of NL
appearance (on the part of the source code). It is not that the
compiler understands too much or too little generally.
> In my opinion, a less "natural" syntax would make it much
> clearer what is going on.
I agree somewhat: the parts where I7 does not attempt to parse the
natural English structure of a phrase should not look like natural
English. For example, I7 could require event names to be all one word:
"The-bomb-explodes in five turns from now." The ugliness would be a
welcome hint to the user.
[j]
Daryl McCullough
>So "very large" isn't really the requirement. What's needed is some
>chunk of grammar that's useful, coherent, and comprehensible, that
>doesn't have you constantly wondering "hmmm, can I say that?" Which I
>believe to be possible, even if I7 isn't the best example at present.
Okay, I agree with that.
Yes. That's what I would like, in general. I'm not sure how easy
and convenient it would be to enforce such a rule.
Andrew Plotkin suggested an alternative that almost be as good:
If I7 provided some kind of syntax-highlighting or even better
sentence diagramming support so that you could look at a command
and know which expressions were being treated as a meaningless
string, and which were being treated as something parseable.
steve....@gmail.com
> Jason Orendorff says...
>
> >So "very large" isn't really the requirement. What's needed is some
> >chunk of grammar that's useful, coherent, and comprehensible, that
> >doesn't have you constantly wondering "hmmm, can I say that?" Which I
> >believe to be possible, even if I7 isn't the best example at present.
>
> Okay, I agree with that.
Yes, but it seems that NL-sheen *inevitably* produces "hmmm, can I say
that?"
I also would like to explore what I7 does, but in a syntax which does
not have any pretentions to NL. Hence my attempts to take some useful
constructions that I7 discovers, and express them in a more
conventional functional structure, i.e., to unconceal the formal
machine-instruction.
The only way I can think to make the formalism clear is to avoid NL
altogether. But Jason is right; there's some syntactical convenience in
certain NL expressions, and some programming synergy when they're taken
together. I wonder if it's possible to appropriate NL in a limited way,
without going all the way to that NL-sheen which makes the code so much
more difficult to read (as code -- "read deeply" as Jason says) and to
write (with the legalities and the formalism firmly in mind, as is
indispensable when programming).
CobraA1
comment.
I7 looks great, especially the IDE and the language.
I like all of the concepts behind it, including the rules-based method
of creating a story. While it appears there's a bit of controversy
about it, it's really similar to an expert system, which is used for
problem solving and AI in games. Personally, I think it's a great way
to do things, especially since it's written in an english-like
language.
The only problem I have is trying to write it. While reading it is
easy, writing it is a bit harder because it's written in an
english-like language, and it's too tempting to treat it like plain
english. Alas, our language is large and complex, and it often ends up
I have to look up the proper way to say things in I7. Once I figured
out how to use it, I'd say it definitely has the feel of a programming
language.
Other than that, it looks like a great way of writing interactive
fiction. Makes me feel like Atrus in Myst, writing books that come
alive . . . perhaps behind that D'ni alphabet is the next version of
Inform ;).
One suggestion, though: Add some syntax highlighting. It would be nice
to know what I7 thinks my words are doing, and if I've accidently
stumbled across a reserved word or something like that.
Nikos Chantziaras
> Maybe it's just me. Maybe it's because I'm getting old and my brain doesn't
> work as well as it used to. Or maybe I just like being whiny in public. But
> ... why am I struggling, grappling, and floundering over the syntax with
> which to attach a simple numerical variable to an object? Isn't this
> supposed to be, like, something that we all learned to do in programming
> 101?
None of the above, actually. It's just that I7 is roflcakes.
But that's just me though.