[Parsing/Inform] necessity of multiinside/multiexcept?
Jon Zeppieri
Figured I'd post once I'd written a game. (I "figured" this back in
1995, I think.) Well, that didn't happen. Anyway, I've got a question
for the Inform gurus.
I'm fooling around with the idea of writing IF libraries for a
general-purpose language. I've been looking over the Inform parser (as
I understand it, the TADS parser is part of the VM and not in the
library), and I'm curious what people think: are the
"multiinside" and "multiexcept" tokens necessary in the verbs' grammar
lines? If not necessary, are they useful?
It's not clear to me that it's the parser's responsibility to ensure
that the objects are in the proper containers. Would it make sense for
the parser simply to generate the semantic event and allow the code
processing that event to check for errors?
Or more generally: would it make sense to limit the parser's role to
that of simply ensuring correct syntax and basic semantic integrity?
For example, the sentence "Take the pea from the jar." will pass through
the parser without error, even if the pea is not in the jar -- even, in
fact, if there is neither a pea nor a jar within the actor's scope. The
parser merely validates that it is possible, in general, to take a pea
from a jar.
Then, things like checking the actor's scope for the items in question
and checking that they are in the correct physical relation to one
another (that the pea is in the jar rather than in the cupboard) becomes
the responsibility of the semantic action code (the TakeSub routine in
Inform, for instance -- I think).
So, uh...is this at all a good idea?
-jaz
--
Don't bother replying to the above email address;
I'll never check it. The actual address is my
first name at eease dot com.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Andrew Plotkin
> I've been "lurking" (as They say) aorund here for a *really* long time.
> Figured I'd post once I'd written a game. (I "figured" this back in
> 1995, I think.) Well, that didn't happen. Anyway, I've got a question
> for the Inform gurus.
>
> I'm fooling around with the idea of writing IF libraries for a
> general-purpose language. I've been looking over the Inform parser (as
> I understand it, the TADS parser is part of the VM and not in the
> library), and I'm curious what people think: are the
> "multiinside" and "multiexcept" tokens necessary in the verbs' grammar
> lines? If not necessary, are they useful?
Their purpose, simply, is to ensure that "put all in box" doesn't include
"put box in box", and "take all from box" only includes things that are
*in* the box.
These restrictions are important. As a programmer, I don't care whether
they're handled in the parser or the action code, as long as they're
handled.
I don't think purity of modularity is worth worrying about. Keep it as
elegant as you can, but IF-language parsing is an inherently messy task,
and you will wind up with messy code.
It will all live or die on whether it's easy to override one library
action or behavior without impacting any other default action or behavior.
This sounds trivial, but you will mess it up dozens of times before you
coem close to getting it right.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Jon Zeppieri
The number of globals used in the Inform parse routines is absolutely
frightening. Now, I *know* that I can improve on that; I can simplify
the really technical details (like have a parser object which, at least,
encapsulates its own state and doesn't pollute the global namespace).
But actually simplifying the algorithm is another matter entirely.
Well, I'll see what I can do. Oh, to raise another age-old issue: in
what general-purpose language, if any, would people enjoy writing IF? I
haven't actually decided on that myself. Statically or dynamically
typed? O-O? Functional?
-jaz
In article <7nhn6b$s...@dfw-ixnews13.ix.netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
> Their purpose, simply, is to ensure that "put all in box" doesn't
include
> "put box in box", and "take all from box" only includes things that
are
> *in* the box.
>
> These restrictions are important. As a programmer, I don't care
whether
> they're handled in the parser or the action code, as long as they're
> handled.
>
> I don't think purity of modularity is worth worrying about. Keep it as
> elegant as you can, but IF-language parsing is an inherently messy
task,
> and you will wind up with messy code.
>
> It will all live or die on whether it's easy to override one library
> action or behavior without impacting any other default action or
behavior.
> This sounds trivial, but you will mess it up dozens of times before
you
> coem close to getting it right.
>
> --Z
>
> "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
> borogoves..."
>
--
BrenBarn
>that of simply ensuring correct syntax and basic semantic integrity?
>For example, the sentence "Take the pea from the jar." will pass through
>the parser without error, even if the pea is not in the jar -- even, in
>fact, if there is neither a pea nor a jar within the actor's scope. The
>parser merely validates that it is possible, in general, to take a pea
>from a jar.
>
>Then, things like checking the actor's scope for the items in question
>and checking that they are in the correct physical relation to one
>another (that the pea is in the jar rather than in the cupboard) becomes
>the responsibility of the semantic action code (the TakeSub routine in
>Inform, for instance -- I think).
haven't written a full game yet either.) But anyway. . .
There's nothing really wrong with this idea. In fact, the IDEA is
perfect. In practice, however, it needs a little modification. For example,
there are very few cases in which you want to allow the player to "DO X TO Y"
if Y is not accessbile to the player (i.e., in scope). So it makes sense to
take the scoping code outside of the verb routines and make it global. A few
other general restrictions like this may apply, but in general, Inform works a
lot like what you describe. Instead of it being the responsibility of the verb
routine, though, the specific chores are usually the work of the object
involved (since Inform is object-oriented), usually in the form of a "before"
or "after" routine.
From,
Brendan B. B.
Bren...@aol.com
(Name in header has spam-blocker, use the address above instead.)
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
Jim Aikin
> Well, I'll see what I can do. Oh, to raise another age-old issue: in
> what general-purpose language, if any, would people enjoy writing IF?
C++. Definitely.
--Jim Aikin
Jonadab the Unsightly One
I'll go along with that.
elisp, anyone?
Actually, Inform is pretty good. In fact, if Inform could do
proper file I/O and arbitrarily large dynamic memory allocation I'd
almost certainly be using it as a general purpose language.
Come to think of it, I *have* used it that way on occasion.
-- jonadab
I've given up spamblocking; it wasn't working all that
well anyway; my email address is now correct in the headers.
Jonadab the Unsightly One
> The number of globals used in the Inform parse routines is absolutely
> frightening.
Parsing is complicated.
> Now, I *know* that I can improve on that; I can simplify
> the really technical details (like have a parser object which, at least,
> encapsulates its own state and doesn't pollute the global namespace).
Just be careful what you encapsulate. Don't encapsulate too much.
It would be a lot easier to encapsulate too much than too little.
You sparked my curiosity, so I whipped out a copy of parserm.h
and pulled out all the globals (except some #ifdefed ones), and
there were 152. Yeah, that's a lot, but consider this: I then
went through and removed from the list just the ones that I know
should not be encapsulated because game code needs to access
them for one reason or another. I'm left with 95 on the list,
but I'm pretty sure that if I posted the list people here could
cross off a few more -- there are whole entry points I've
never even used, so I doubt I've messed with all the library
globals I'll ever need to mess with.
I can post my list of 95 if anyone is curious.
> But actually simplifying the algorithm is another matter entirely.
No kidding.
> Well, I'll see what I can do. Oh, to raise another age-old issue: in
> what general-purpose language, if any, would people enjoy writing IF? I
> haven't actually decided on that myself. Statically or dynamically
> typed? O-O? Functional?
QBasic ;-)
Kathleen M. Fischer
> You sparked my curiosity, so I whipped out a copy of parserm.h
> and pulled out all the globals (except some #ifdefed ones), and
> there were 152. Yeah, that's a lot, but consider this: I then
> went through and removed from the list just the ones that I know
> should not be encapsulated because game code needs to access
> them for one reason or another. I'm left with 95 on the list,
> I can post my list of 95 if anyone is curious.
I'm curious to see BOTH lists :)
Kathleen
--
*******************************************************************
* Kathleen M. Fischer *
* kfis...@greenhouse.nospam.gov (nospam = l l n l) *
** "Don't stop to stomp ants while the elephants are stampeding" **
Jurgen Lerch)
Jon Zeppieri <97...@my-deja.com> wrote:
[...]
> Well, I'll see what I can do. Oh, to raise another age-old issue: in
> what general-purpose language, if any, would people enjoy writing IF? I
> haven't actually decided on that myself. Statically or dynamically
> typed? O-O? Functional?
Pascal/Modula/Oberon & co.
Lisp or Prolog, maybe.
Definitely not C(++)/Java!
Ad Astra!
JuL
--
ler...@uni-duesseldorf.de / Never disturb a dragon, for you will
J"urgen ,,JuL'' Lerch / be crunchy and taste good with ketchup!
http://www-public.rz.uni-duesseldorf.de/~lerchj/
BrenBarn
>It would be a lot easier to encapsulate too much than too little.
>
>and pulled out all the globals (except some #ifdefed ones), and
>there were 152. Yeah, that's a lot, but consider this: I then
>went through and removed from the list just the ones that I know
>should not be encapsulated because game code needs to access
>them for one reason or another.
before I started learning Inform, I'm still in the dark about this idea: How is
defining a global variable different from defining an object called "global"
and then using properties of that object to store what would otherwise be
stored in global variables? I'm sure this is a simple question, it's just that
I've never gotten around to looking for an answer.
Brian Takle
BrenBarn wrote:
>
> >Just be careful what you encapsulate. Don't encapsulate too much.
> >It would be a lot easier to encapsulate too much than too little.
> >
> >You sparked my curiosity, so I whipped out a copy of parserm.h
> >and pulled out all the globals (except some #ifdefed ones), and
> >there were 152. Yeah, that's a lot, but consider this: I then
> >went through and removed from the list just the ones that I know
> >should not be encapsulated because game code needs to access
> >them for one reason or another.
This is true for the Inform parser, but only because it's not much
written in an object-oriented way. It's entirely possible to write a
fully encapsulated parser object.
> This interests me. Since I had never really done much OO programming
> before I started learning Inform, I'm still in the dark about this idea: How is
> defining a global variable different from defining an object called "global"
> and then using properties of that object to store what would otherwise be
> stored in global variables? I'm sure this is a simple question, it's just that
> I've never gotten around to looking for an answer.
This is another result of Inform not being very strenuously
object-oriented. In Inform, you could do exactly what you propose. But
in stricter OO, objects hide their internal data from the outside world,
and you only interact with objects by way of their public entry points.
To make this easier to understand, imagine that instead of one "thread"
running through an Inform program there were, say, three things going on
simultaneously. If one of those threads changed some global variable, it
might inadvertently mess up something one of the other threads was in
the middle of doing. By only defining variables inside of objects,
access to those variables can be controlled and this sort of mishap
avoided altogether.
--
Brian Takle
Email: ta...@earthling.net
PGP: www.pressenter.com/~btakle/pgp/pgpkey.html
"Nothing is worth more than today."
-- Johann Wolfgang von Goethe
Jim Aikin
>
> proper file I/O and arbitrarily large dynamic memory allocation I'd
> almost certainly be using it as a general purpose language.
>
> Come to think of it, I *have* used it that way on occasion.
I'm far indeed from being an expert programmer, but I'm not sure I
agree. Inform has a lot of very nice features, and I don't want to sound
ungrateful for all the amazing work Graham has put into it. But....
(a) Do you really want to use a general-purpose language that can only
be used for text I/O? Even within the realm of IF, I can think of lots
of interesting graphics-based puzzles that would REALLY push the
envelope if implemented in ASCII. (And my soon-to-be-released game has
an entire electric train layout, complete with tunnels, a cowcatcher on
the engine, track switches, and a loading crane, all of which are
implemented in ASCII, so I think I've pushed that envelope about as far
as I care to.)
(b) I want to be able to pass pointers as arguments to functions. That
would eliminate a lot of code overhead in terms of setting up variables
that you have to use to store stuff in in order to pass the values from
place to place.
(c) Working with string variables is a pain in Inform. I miss Visual
C++'s nice CString class operators. This type of thing would make
assembling a text message for printout much neater -- you could write a
single line of code to assemble your output message without worrying
about the contents of specific string variables.
(d) Having to use the self prefix for object-level variables is clumsy.
I keep forgetting to do it, but the compiler doesn't always seem to flag
it as an error, so it causes bugs.
(e) Large integers. Need I say more?
--Jim Aikin
Jon Zeppieri
pointers.
No, wait. I don't think I want to program anything at all in a language
that exposes pointers.
NOT that I want to start a language war. Just stating my own
preferences.
Elisp is an interesting idea. (One more reason never to leave your
Emacs window!) I've looked at Python, SML, Objective CAML (briefly),
Haskell. Haven't made up my mind yet.
In article <379d8745...@news.bright.net>,
jon...@bright.net (Jonadab the Unsightly One) wrote:
> Jim Aikin <jaikin....@pacbell.net> wrote:
>
> > Jon Zeppieri wrote:
> >
> > > Well, I'll see what I can do. Oh, to raise another age-old
issue: in
> > > what general-purpose language, if any, would people enjoy writing
IF?
> >
> > C++. Definitely.
>
> I'll go along with that.
>
> elisp, anyone?
>
> Actually, Inform is pretty good. In fact, if Inform could do
> proper file I/O and arbitrarily large dynamic memory allocation I'd
> almost certainly be using it as a general purpose language.
>
> Come to think of it, I *have* used it that way on occasion.
>
> -- jonadab
>
> I've given up spamblocking; it wasn't working all that
> well anyway; my email address is now correct in the headers.
>
--
Jon Zeppieri
> How is
> defining a global variable different from defining an object called
"global"
> and then using properties of that object to store what would otherwise
be
> stored in global variables? I'm sure this is a simple question, it's
just that
> I've never gotten around to looking for an answer.
There is only one (important) difference: global variables, in
languages which have them, all occupy the top-level namespace. Why is
this, in most cases, undesirable? Because if you define a local
variable with the same name, at some narrower lexical scope, you will
*hide* the global variable. Name hiding is very error prone: you may
think you are changing the value of a global, while, in reality, you are
changing a local variable (or vice versa, which is far worse). Inform
may not allow you to hide names; I don't know. But, in that case,
global variables limit the names which *you* can apply to variables.
If, for instance, "i" were a global, you couldn't use it for your "for"
loops.
As to the question of why global variables, in general, are icky (even
if you put them in an accessible "global" object): they externalize too
much state. As a wildly random example, take the "inferfrom" global
variable, defined in the parserm.h file of the Inform library. There is
no good reason why this value should be accessible by any code other
than the parser. The more you externalize the state of your code, the
more difficult it becomes to manage that state. You have to keep track
of which functions change global values (not which functions *can
potentially* change them, because that's ALL functions) and when.
Yuck.
-jaz
Adam J. Thornton
J"urgen Lerch <ler...@uni-duesseldorf.de> wrote:
>Definitely not C(++)/Java!
See, I think Java would be just fine, except for having to write a parser.
Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
L. Ross Raszewski
wrote:
>
>I'm far indeed from being an expert programmer, but I'm not sure I
>agree. Inform has a lot of very nice features, and I don't want to sound
>ungrateful for all the amazing work Graham has put into it. But....
>
>(a) Do you really want to use a general-purpose language that can only
>be used for text I/O? Even within the realm of IF, I can think of lots
>of interesting graphics-based puzzles that would REALLY push the
>envelope if implemented in ASCII. (And my soon-to-be-released game has
>an entire electric train layout, complete with tunnels, a cowcatcher on
>the engine, track switches, and a loading crane, all of which are
>implemented in ASCII, so I think I've pushed that envelope about as far
>as I care to.)
Inform does have graphical capabilities. TO do more, it would probably
need some sort of way to do call out to machine-native functions. G'bye
portability.
>
>(b) I want to be able to pass pointers as arguments to functions. That
>would eliminate a lot of code overhead in terms of setting up variables
>that you have to use to store stuff in in order to pass the values from
>place to place.
Um... you can, I think, for arrays and objects. Global variables don't live
in memory, but I think you can still pass their number around, though I
don't know if there's an easy way to get the number of a global variable.
(Sounds like a job for a library!)
>
>(c) Working with string variables is a pain in Inform. I miss Visual
>C++'s nice CString class operators. This type of thing would make
>assembling a text message for printout much neater -- you could write a
>single line of code to assemble your output message without worrying
>about the contents of specific string variables.
<cough>istring<cough>.
>
>(d) Having to use the self prefix for object-level variables is clumsy.
>I keep forgetting to do it, but the compiler doesn't always seem to flag
>it as an error, so it causes bugs.
Huh?
>
>(e) Large integers. Need I say more?
That's a library concern, though a language feature for it might be useful
to some people (again, I've never needed it).
L. Ross Raszewski
>Eww. I don't think I want to program IF in any language that exposes
>pointers.
>
>No, wait. I don't think I want to program anything at all in a language
>that exposes pointers.
>
available in a language, if you never have to use them? Aside from my work
writing a memory manager, I don't think that I've ever done anything in
inform that required pointers.
I don't think I could ever program in a language WITHOUT pointers. Not enough
power.
Andrew Plotkin
>> proper file I/O and arbitrarily large dynamic memory allocation I'd
>> almost certainly be using it as a general purpose language.
>>
>> Come to think of it, I *have* used it that way on occasion.
>
> agree. Inform has a lot of very nice features, and I don't want to sound
> ungrateful for all the amazing work Graham has put into it. But....
>
> (a) Do you really want to use a general-purpose language that can only
> be used for text I/O? Even within the realm of IF, I can think of lots
> of interesting graphics-based puzzles that would REALLY push the
> envelope if implemented in ASCII. (And my soon-to-be-released game has
> an entire electric train layout, complete with tunnels, a cowcatcher on
> the engine, track switches, and a loading crane, all of which are
> implemented in ASCII, so I think I've pushed that envelope about as far
> as I care to.)
As the Glulx/Glk projects clunk along, this will all get more reasonable.
With my (unreleased, in-progress) compiler, I can already compile standard
Inform code which allows proper file I/O, true memory allocation, graphics
at least as powerful as Infocom's V6, and sound (though that's only
implemented on the Mac.)
And large integers, of course.
Evin C Robertson
[Parsing/Inform] necess.. by Andrew Plo...@netcom.co
> Inform code which allows proper file I/O, true memory allocation, graphics
Glk graphics are perhaps slightly easier to write for, and allow easier
scrollback and resizing, but are definitely not as powerful as v6. v6
allows arbitary mixes of graphics and text and easier single-pixel
manipulation. Not to mention the many weirdness bugs and lack of
transparency support in current Glk implementations.
If Glk were as powerful as v6, I'd have finished v6 Glk support by now.
Andrew Plotkin
> Excerpts from netnews.rec.arts.int-fiction: 28-Jul-99 Re:
> [Parsing/Inform] necess.. by Andrew Plo...@netcom.co
>> With my (unreleased, in-progress) compiler, I can already compile standard
>> Inform code which allows proper file I/O, true memory allocation, graphics
>> at least as powerful as Infocom's V6, ...
>
> Glk graphics are perhaps slightly easier to write for, and allow easier
> scrollback and resizing, but are definitely not as powerful as v6. v6
> allows arbitary mixes of graphics and text and easier single-pixel
> manipulation.
You're right; I should have thought before I posted that.
Let me instead say: powerful enough to handle the formatting used in
Infocom's games Arthur, Shogun, and Zork Zero. (They used graphics-only
panels and some inline images; I can't recall anything else. I guess you
could include palette-switching tricks, but that was really only used as a
way to save on image count.)
Journey was implemented with multiple overlapping text windows, which I
chose not to touch with a big stick -- but I think you could implement
something similar enough that users wouldn't notice. (Again, unless
there's something I'm not recalling.)
> Not to mention the many weirdness bugs and lack of
> transparency support in current Glk implementations.
I definitely have to get transparency working. What other bugs are you
thinking of?
Jon Zeppieri
The only valid reason to use pointers over transparent references
(pointers are handled by the runtime, not by the programmer) is for
passing function pointers. But, in languages where functions are first
class citizens (just about any functional language you can think of:
LISP, Scheme, ML, Haskell, &c.), you pass the function itself, not
pointer to it. It's *much* more powerful than using pointers directly
-- and *much* less error prone.
-jaz
--
Don't bother replying to the above email address;
I'll never check it. The actual address is my
first name at eease dot com.
Mike Roberts
>See, I think Java would be just fine, except for having to write a parser.
Indeed - before embarking on the T3 project, I gave serious consideration to
targeting the JVM as the TADS 3 compiler's output. Implementing a parser
wouldn't be easy, but it wouldn't be that much different from implementing a
parser in any other language (perhaps it would be easier than in some other
languages, in fact, since Java has a reasonably powerful string library).
There are a number of other facilities that we mostly take for granted in an
IF VM, though, that wouldn't be trivial to implement in Java - serialization
of game state (i.e., save/restore), undo, restart, object enumeration, and
completely run-time type binding, for example. You could implement all of
these with a data model implemented in Java, but that effectively would be
running a VM on a VM, which might be inefficient.
Maybe if I find myself with a whole lot of time on my hands someday I'll
write a JVM code generator for my TADS 3 compiler.
--Mike
Adam J. Thornton
Mike Roberts <mjr-S...@hotmail.com> wrote:
>Adam J. Thornton wrote in message <7nlqfe$gp1$1...@cnn.Princeton.EDU>...
>>See, I think Java would be just fine, except for having to write a parser.
>
>Indeed - before embarking on the T3 project, I gave serious consideration to
>targeting the JVM as the TADS 3 compiler's output. Implementing a parser
>wouldn't be easy, but it wouldn't be that much different from implementing a
>parser in any other language (perhaps it would be easier than in some other
>languages, in fact, since Java has a reasonably powerful string library).
>There are a number of other facilities that we mostly take for granted in an
>IF VM, though, that wouldn't be trivial to implement in Java - serialization
>of game state (i.e., save/restore), undo, restart, object enumeration, and
>completely run-time type binding, for example. You could implement all of
>these with a data model implemented in Java, but that effectively would be
>running a VM on a VM, which might be inefficient.
Here I largely disagree.
Presuming that your game state is encapsulated in an object tree, you
simply declare the objects in that tree Serializable or Externalizable (if
the latter, then you write the serialization methods yourself).
Preallocate some chunk of memory, and at the end of each turn, serialize
the object tree into that chunk of memory. If there's not enough room, get
rid of older turn-images until there is room. You've just gotten yourself
save and multiple undo. Restore is, of course, the readObject() method
that goes with the serialization interface.
No need for a VM within a VM.
I don't understand what you mean about object enumeration, and I agree that
run-time type binding would require a VM within Java--but what do you need
run time typing for anyway?
Mike Roberts
>In article <7nnj3n$7f9$1...@inet16.us.oracle.com>,
>Mike Roberts <mjr-S...@hotmail.com> wrote:
>>There are a number of other facilities that we mostly take for granted in
an
>>IF VM, though, that wouldn't be trivial to implement in Java -
serialization
>>of game state (i.e., save/restore), undo, restart, object enumeration, and
>>completely run-time type binding, for example.
>
>
>Presuming that your game state is encapsulated in an object tree, you
>simply declare the objects in that tree Serializable or Externalizable (if
>the latter, then you write the serialization methods yourself).
>Preallocate some chunk of memory, and at the end of each turn, serialize
>the object tree into that chunk of memory. If there's not enough room, get
>rid of older turn-images until there is room. You've just gotten yourself
>save and multiple undo. Restore is, of course, the readObject() method
>that goes with the serialization interface.
This would work well for save/restore, but it probably would be too slow for
saving undo every turn. Serialization has to traverse all the run-time type
information for the entire tree of objects to be serialized, so it's a lot
slower than just making a copy of memory, and also takes up more memory than
the original objects themselves do. You'd also need a way of enumerating
all of the root objects for serialization, but that's just a matter of
conventions.
>I don't understand what you mean about object enumeration, and I agree that
>run-time type binding would require a VM within Java--but what do you need
>run time typing for anyway?
Object enumeration is what you get from objectloop in Inform or
firstobj/nextobj in TADS. As for run-time typing, you could live without
it, but it's handy for writing IF - you frequently want to be able to test
an arbitrary object for an arbitrary property. You could use a very wide
"Thing" base class, with most every property in the game defined on it;
every subclass instance would have all of those properties, so you could
test any object for them. The drawback would be that this would make
"Serializable"-based undo take longer to save its snapshots - of all those
field values that would have to be traversed and stored for every object.
You could alternatively test an object for membership in a class, but that
makes for brittle code.
I don't mean to suggest that Java wouldn't make a good IF language - I'm
sure that with some effort one could build a decent infrastructure for it.
Of all of the general-purpose languages I've used, Java is probably the most
suitable for IF; TADS 3 will have a great deal in common with Java, in fact.
But it wouldn't be trivial to build a good IF framework in Java, and I think
there are advantages to using a VM tailored to this application.
--Mike
Jon Zeppieri
> I don't understand what you mean about object enumeration, and I agree
that
> run-time type binding would require a VM within Java--but what do you
need
> run time typing for anyway?
>
In general, I don't like dynamic typing, but in IF, it's nice to be able
to do things like change a property of an object to a method. Well,
it's kind-of nice. It's powerful, but error prone.
First-class functions would be *very* nice to have, but "strategy"
patterns can by used in O-O to get around that lack -- it just makes the
code more verbose.
I agree with you about the state serialization -- it's just a matter of
ensuring that references to all state-relevant objects are kept in some
standard place. Java doesn't let you walk the heap.
-jaz
okbl...@my-deja.com
Jon Zeppieri <97...@my-deja.com> wrote:
>
> Well, I'll see what I can do. Oh, to raise another age-old issue: in
> what general-purpose language, if any, would people enjoy writing IF?
> typed? O-O? Functional?
Smalltalk. Eiffel.
--
[ok]
Jonadab the Unsightly One
> > Actually, Inform is pretty good. In fact, if Inform could do
> > proper file I/O and arbitrarily large dynamic memory allocation I'd
> > almost certainly be using it as a general purpose language.
> >
> > Come to think of it, I *have* used it that way on occasion.
>
> I'm far indeed from being an expert programmer, but I'm not sure I
> agree. Inform has a lot of very nice features, and I don't want to sound
> ungrateful for all the amazing work Graham has put into it. But....
>
> (a) Do you really want to use a general-purpose language that can only
> be used for text I/O?
No. That's why I gave the proviso that it needed proper file I/O.
As for graphics, really only a few applications have any use for
them. Most programs don't need them. (Except on a Mac, but that's a
whole 'nother universe.) There are many, many things you write
programs to do that have no need for graphics. Most of what I
code are programs that read in one text file, process it in some
way, and write out another text file. Occasionally I find myself
writing code that reads or writes a binary file of some kind.
When I'm coding anything to do with graphics I either do it
in QBasic (if it's pretty simple graphics and has no use for
portability or needs to be interactive) or Persistence Of Vision
(otherwise).
> Even within the realm of IF, I can think of lots
> of interesting graphics-based puzzles that would REALLY push the
> envelope if implemented in ASCII.
I prefer games without graphics-based puzzles, generally.
(Note that I did not say games without graphics; Descent
is great, as is Scorched Earth.)
> (b) I want to be able to pass pointers as arguments to functions.
How, exactly, is that a problem in inform? Just because Inform
doesn't call it a pointer doesn't mean it isn't a pointer. If
your variable has a unique object number which refers to exactly
one object... that's a pointer. Not only that, it's a void-typed
pointer, in C terms, because the same variable could also hold
a pointer to a string or a function or a dictionary entry or
something else.
> That
> would eliminate a lot of code overhead in terms of setting up variables
> that you have to use to store stuff in in order to pass the values from
> place to place.
I don't see how.
> (c) Working with string variables is a pain in Inform.
Actually, when one has used BASIC quite a bit, working
with string variables in C++ is a pain, too. What you
ultimately end up doing in any language that lacks a
fundamental string type is using functions that act on
an array of characters (or some class/object construction
that is essentially the same thing) as if it were a
string. In C++ there are implementations of this in
the standard library, and in Inform you'd have to make
them, but it wouldn't be that big a deal, and once you
make them once you've got them forever.
> (d) Having to use the self prefix for object-level variables is clumsy.
> I keep forgetting to do it, but the compiler doesn't always seem to flag
> it as an error, so it causes bugs.
Whoah, you've been brain-dammaged by lesser languages here.
The syntax I think you mean ( i = description; ) has another
(intuitively obvious, I thought) meaning, and changing it
to refer to self.description would interfere with existing
functionality. There are any number of reasons to need to
be able to set a variable to the number of a particular
property, and I wouldn't want to have to mess with some
arcane syntax in order to do it, either. Furthermore, it
breaks the principle that the same syntax should do the
same thing in an embedded routine that it would do in an
external routine -- unless you disallow the syntax outside
embedded routines, in which case NO routines could access
the property numbers... bad, bad, bad.
> (e) Large integers. Need I say more?
That's a VM issue, not a language issue. Besides, it
wouldn't be hard at all to create a class that could
handle VERY large integers, and given unlimited proper
dynamic memory allocation it would be possible to create
one that would handle an integer limited in size only
by available memory.
I've actually thought about creating an Inform program
to calculate the factorials of successively large
integers until the user comes back from vacation and
presses a key...
Jonadab the Unsightly One
> Jonadab the Unsightly One wrote:
> > You sparked my curiosity, so I whipped out a copy of parserm.h
> > and pulled out all the globals (except some #ifdefed ones), and
> > there were 152. Yeah, that's a lot, but consider this: I then
> > went through and removed from the list just the ones that I know
> > should not be encapsulated because game code needs to access
> > them for one reason or another. I'm left with 95 on the list,
>
> > I can post my list of 95 if anyone is curious.
>
> I'm curious to see BOTH lists :)
I realised after I'd deleted a whole bunch of them that someone
might ask to see the full list, but it was too late. Anyway,
here's the one's I'm not sure about...
Parser variables I'm not certain need to be global:
sline1
sline2
standard_interpreter
undo_flag
just_undone
last_score
print_player_flag
lastdesc
c_style
lt_value
wlf_indent
inventory_style
pretty_flag
menu_nesting
menu_item
item_width
item_name
keep_silent
parser_trace
parser_one
parser_two
inputobjs
parser_inflection
meta
multiple_object
multiflag
toomany_flag
kept_results
best_etype
nextbest_etype
pattern
pcount
pattern2
pcount2
line_ttype
line_tdata
line_token
parameters
nsns
special_number1
special_number2
params_wanted
inferfrom
inferword
dont_infer
action_reversed
advance_warning
found_ttype
found_tdata
token_filter
length_of_noun
lookahead
multi_mode
multi_wanted
multi_had
multi_context
indef_mode
indef_type
indef_wanted
indef_guess_p
indef_owner
indef_cases
indef_possambig
indef_nspec_at
allow_plurals
take_all_rule
dict_flags_of_noun
pronoun__word
pronoun__obj
scope_token
scope_error
ats_flag
ats_hls
placed_in_flag
match_list
match_classes
match_scores
number_matched
number_of_classes
match_length
match_from
buffer2
parse2
buffer3
usual_grammar_after
oops_from
saved_oops
oops_workspace
held_back_mode
hb_wn
PowersOFTwo_TB
short_name_case
old_itobj
old_himobj
old_herobj
Jonadab the Unsightly One
> > I can post my list of 95 if anyone is curious.
>
> I'm curious to see BOTH lists :)
Unfortunately, I didn't think to save before I started
deleting, but I'll post the list of ones I'm not sure about.
Parser variables I'm not certain _need_ to be global:
Jonadab the Unsightly One
> > You sparked my curiosity, so I whipped out a copy of parserm.h
> > and pulled out all the globals (except some #ifdefed ones), and
> > there were 152. Yeah, that's a lot, but consider this: I then
> > went through and removed from the list just the ones that I know
> > should not be encapsulated because game code needs to access
> > them for one reason or another. I'm left with 95 on the list,
>
> > I can post my list of 95 if anyone is curious.
>
> I'm curious to see BOTH lists :)
Unfortunately, I didn't think to save before I started
deleting all the ones I knew need to be global. But
Jonadab the Unsightly One
[Same thing three times.]
Sorry about that. Apparently, in spite of the fact that
I was getting a fatal exception that terminated the
newsreader each time I tried to post it, it was getting
through. Such are the joys of a certain OS I need not
explicitely mention.
Marnie Parker
>From: jon...@bright.net (Jonadab the Unsightly One)
>Date: Wed, 18 August 1999 05:21 AM EDT
>Parser variables I'm not certain _need_ to be global:
>
>sline1
>sline2
If you want to write your own status line using time, yes those two need to be
global. I am unsure about the rest. But then I haven't really looked at them.
Doe :-)
-----------------------------
doea...@aol.com
The Doepage - http://members.aol.com/doepage/index.htm
IF Art Gallery - http://members.aol.com/iffyart/gallery.htm
"I can live for two months on a good compliment." Mark Twain