[platform-design] Language and Syntax
David A. Cornelson
I'm starting to monkey with language syntax and along with that things about
how I want the language to function are coming out, including some things
that would be considered library elements.
I'd like to open up not necessarily for discussion but possibly a request
for ideas related to a new syntax and things in an IF library that are good
in what is currently available and what is missing or what might be done
differently.
Comments about what people like about the new TADS 3 library are perfectly
acceptable since I'm going through a lot of TADS 3 code to garner ideas. I'm
also going through the Inform library, the Hugo library, and Platypus so any
comments from those are welcome as well.
The syntax I'm creating is going to be verbose and have elements of Basic,
C, Inform, and possibly even COBOL. But it also has things that are relevent
to the .NET framework which you won't notice unless you've used it.
Design goals are readability, inherent multi-player development, verbosity,
and extensibility.
I have a sample piece of code and if you'd like to discuss it, stop by ifMUD
and join the #if# channel. I'd rather not open it up _yet_ to the newsgroup
because it's in its first trimester and has some growing to do. (sorry for
the baby ref, but my wife is due to deliver our fourth daughter in August).
So bring it on. Let's see what you really want in an IF system and what you
love about the current systems.
I think I should point out that the strongest gravitational pull in the new
syntax is to maintain as much of the elegance of Inform, Hugo, and TADS as I
can. And I'm not in a huge hurry. Mike first announced TADS 3 about 3 years
ago. I'm about a year or more away from making an equivalent announcement
and that would only be a syntax and an alpha compiler. Not a library. Of
course I've garnered some interest from non-IF compiler people so I may have
help. That may move up an alpha compiler date. We'll see.
Dave
Jim Aikin
would be more informative compiler error messages. You know, not just
"Unexpected token, line 347," which probably refers to a typo on line 346,
but something more robust -- maybe something that can make an educated
guess about what the real problem is. It's not at all unusual for the TADS
compiler, for instance, to report an "error" hundreds of lines away from
the actual typo. Sometimes I have to compile three or four times while
commenting out various blocks of code in order to zero in on the trouble spot.
I suspect this would be a thorny programming problem in its own right, but
it's probably worth thinking about.
(No, I don't use TADS Workbench much. I just compile from the MS-DOS prompt.)
--JA
Mr. J
phrase them as generally as possible hand hope they refer to all IF
languages. Many of the things I mention can be done in Inform now, but
have no special language to to deal with it. I have 20 lines of code
that will get me the last day of a month in PHP3, but only 1 line in
PHP4.
Two form of expanding come to mind.
One is to become more of simulation by increasing the physical model.
Curerntly it is only a tree of child-parent-sibling. What about
building in aspects of current simulationism models?
The other is getting greater control of output because, after all,
"You walk up to the counter" is as vivid to a reader as a simulation
where you can walk around a room.
I liked the results I get in Inform, because the games parser works
like the old Infocom games I played. No IF system really parses full
english sentences. The senteces typed by IF players are very tailored
to the IF. A parser tries to extract what actions and nouns are most
likely being refered to in scope. I'd like to see more hi-level
syntax for dealing with how sentences are parsed.
When I introduce someone to IF for the first time they can hardly get
anywhere because you must learn the basic "language" of getting
around. If they see something, they don't know that they don't have to
"walk up to it". Most people in this group know you just can say
"Take object", but I think the future fo IF lay in creating a scope
outside of the "room" model. It seems to break down in huge rooms, or
outdoors (though the illusion is always mantained by clever
programming and prose.). Just as there are fake actions, could/should
there be sould be fake movments? Or maybe even native code for
non-compass based moment.
The actual syntax I have suggestion for, but to anyone versed in
Inform this is never a problem... but I have other languages that I
work in that are very consitant rules for syntax that seems to be
missing in Inform. I'm at the point that what I used to find
inconsitant has just been memorized.
There are a huge glut of "work arounds" that should be modernized.
I'm interested in a larger Library so as not to have to code so much
behavior code.
Those are some very general ideas. Anyone have some specifics?
L. Ross Raszewski
>One is to become more of simulation by increasing the physical model.
>Curerntly it is only a tree of child-parent-sibling. What about
>building in aspects of current simulationism models?
The primary problem with this is that once you move beyond the simple,
you're going to tend to lock users in to a more complex model that
isn't what they want; the simple parent-sibling-child object hierarchy
is primitive, but it's also universal. If you had a more complex
modeling, it would not be well-fit to every game; you'd have a
tendency to only write the sorts of games that wanted that physical
model.
>
>There are a huge glut of "work arounds" that should be modernized.
>I'm interested in a larger Library so as not to have to code so much
>behavior code.
This a totally disagree about. The library is not the place for every
feature anyone can think of. The library is where stuff *every* game
should have goes, not where *anything any game might want* should go.
Ben Caplan
> So bring it on. Let's see what you really want in an IF system and what you
> love about the current systems.
I think it would be nice to support adverbs, in much the same vein as
adjectives. Here's some TADS2 pseudo-code (and transcript) to demonstrate
what I mean:
casuallyinspectVerb: deepverb
verb = 'inspect' 'examine' 'x' 'look at' 'l at'
adverb = 'casually' 'nonchalantly'
sdesc = "casually inspect"
doAction(actor) = 'Casuallyinspect'
;
carefullyinspectVerb: deepverb
verb = 'inspect' 'examine' 'x' 'look at' 'l at'
adverb = 'carefully' 'closely'
sdesc = "carefully inspect"
doAction(actor) = 'Carefullyinspect'
;
Example Room
You are in a very small room.
There is a red hat here.
>X HAT
How do you want to x it: casually inspect, or carefully inspect?
>CASUALLY
It's bright red. Very gaudy.
>CAREFULLY INSPECT HAT
The perfect fashion statement, if the wearer happens to be planning on
running away with the circus. Which he probably was, judging by the stub of
a ticket stuck in the brim.
Actually, exactly the same as adjectives. Has this been done?
----------------------------------------------------------------
Ben Caplan -- philosopher, linguist, and thaumaturge
David A. Cornelson
news:3EA0B292.5040303@end_of_spam.org...
This is partly syntax checking on the compiler's part and partly a
contemporary IDE. One of the benefits of using a .NET language is that you
can use either VS.Net (if you can afford it or use it through work) or the
free .NET IDE called the Matrix. But of these IDE's provide inline
syntax-checking, a list of compiler errors that when clicked on will take
you to the offending code, and more.
But the detailed error messages is a good thought and something to keep in
mind.
Dave
Mike Roberts
> I think it would be nice to support adverbs, in much the same
Possibly; it's certainly been discussed extensively here before. In fact,
it's been discussed here so much before that it's probably only a few
notches below "copyright thread" for a lot of people, so I'll refrain from
saying more, and instead refer you to groups.google.com - try a search like
group:rec.arts.int-fiction adverbs
--Mike
mjr underscore at hotmail dot com
Lucian P. Smith
: On 19 Apr 2003 00:34:49 -0700, Mr. J <john...@earthlink.net> wrote:
:>There are a huge glut of "work arounds" that should be modernized.
:>I'm interested in a larger Library so as not to have to code so much
:>behavior code.
: This a totally disagree about. The library is not the place for every
: feature anyone can think of. The library is where stuff *every* game
: should have goes, not where *anything any game might want* should go.
You know, I think I disagree. The library *should* have stuff for
anything and everything. That would make it much easier to help a newbie,
for one--you wouldn't have to say, "download menus.h" every time they said
they wanted menus, for example.
The only real disadvantage of putting everything in the library is game
size bloat, and it seems to me it wouldn't be terribly difficult to
modularize the library so it was clever enough to not compile into the
game bits that would never be called. If size is an issue for you at all.
Having a modular library would also allow people to offer their own
'menus.h' which could be dropped in easily if users needed the behavior
changed.
(And yes, I know 'menus.h' has a bug in it that modern interpreters
complain about. This proves my point--if it was in the library, it would
have been fixed much earlier.)
Oh, and you need a menus.h in the library. Only way to go for
invisicule-style hints, IMO.
-Lucian
tarage
(in message <yPfoa.7642$yO5...@nwrddc02.gnilink.net>):
I agree. The very concept of a library as far as code goes, is one of
universiality. If you have to compile with all these funky switches to take
stuff out because either 1) your game doesn't need it or 2) it takes up too
much space, the library isn't universal anymore. I don't see how folks are
inconvienienced by adding a few include files to the beginning of their
program.
~tarage~
David A. Cornelson
news:b7t0tk$g7v$2...@joe.rice.edu...
> L. Ross Raszewski <lrasz...@loyola.edu> wrote in
<yPfoa.7642$yO5...@nwrddc02.gnilink.net>:
> : On 19 Apr 2003 00:34:49 -0700, Mr. J <john...@earthlink.net> wrote:
>
> : This a totally disagree about. The library is not the place for every
> : feature anyone can think of. The library is where stuff *every* game
> : should have goes, not where *anything any game might want* should go.
>
> You know, I think I disagree. The library *should* have stuff for
> anything and everything. That would make it much easier to help a newbie,
> for one--you wouldn't have to say, "download menus.h" every time they said
> they wanted menus, for example.
>
> The only real disadvantage of putting everything in the library is game
> size bloat, and it seems to me it wouldn't be terribly difficult to
> modularize the library so it was clever enough to not compile into the
> game bits that would never be called. If size is an issue for you at all.
>
> Having a modular library would also allow people to offer their own
> 'menus.h' which could be dropped in easily if users needed the behavior
> changed.
>
I'm really trying to avoid talking about .NET, but there's an important
point that I'd like to make about my intentions. I certainly will provide
all source to everything I do, but this doesn't mean you need it. I will
also offer .NET Assemblies that would likely handle the IFSharp language,
the IF# Library, and then IF# Extensions. Now contributions could be placed
into a new namespace, such as IFSharp.Contributions.Menus. So then the
author would just put:
using IFSharp.Constributions.Menus;
...and this would give them access in there code to use the menuing system.
Even the IFSharp.Library could be broken up into different pieces so you
didn't have to include the whole thing. I can think of one example which
would be which "language" the author was writing in (English, Italian, etc).
So they would do this:
using IFSharp.Library.English;
OR
using IFSharp.Library.Italian;
I can think of other things to partition within the library, such as doors.
In fact doors are perfect example of something that belongs at a layer in
between an IF platform library and the game code, but not really _in_
either.
There's granularity available that's been implemented with include files
(perfectly reasonable) with current platforms, but with .NET, this would be
done with some intelligent partitioning of classes and setting these into
various namespaces and physical assemblies (you can have 10 namespaces in
one assembly or break them up however you'd like).
Dave
Mr. J
> you're going to tend to lock users in to a more complex model that
> isn't what they want; the simple parent-sibling-child object hierarchy
> is primitive, but it's also universal.
There is no reason that higher fucntionality would over-rule the
existing Parent Child Sibling model... it just could have more cousin,
aunts, and grandfather functions :-)
Graphics used to be done in assembly for speed, and still can be, but
for the most part other syntax is used. Yes you can still access in
assembly if you want to. There is no reason that higher level syntax
can't be use for complex, but common aspects, instead of having to
interupt the parser one letter/word at a time.
> The library is not the place for every
> feature anyone can think of. The library is where stuff *every* game
> should have goes, not where *anything any game might want* should go.
I thought the MINIMUM it should have is what every game needs, but
that should not be the maximum. You mentioned people coding based on
the model, but isn't that the problem with the compass navigation?
There was been almost no shift from that model with a few exceptions.
It's an unnatural way to move, but is easy to implement.
Most people I've seen playing IF for the first time who see "there is
a path to the west" will type "follow path" before they type "go west"
"walk west" or "W". It's VERY easy to get into the accepted form of
input and gameplay. Most here have been playing these for years.
Parent-Child-Sibling may be universal, but the current library is
already filled with things that are not.
Just as additions and contributions are added, I'm just talking about
expanding the existing library. I really don't think size of final
games would take a strong hit.
Right now in Inform using the library is fine, until you want it to be
different. Overriding library functions could be better handled.
A game that handled pure, natural text may be way off or impossible...
but I think there is a huge room for improvement.
-John
L. Ross Raszewski
<lps...@rice.edu> wrote:
>L. Ross Raszewski <lrasz...@loyola.edu> wrote in
<yPfoa.7642$yO5...@nwrddc02.gnilink.net>:
>
>anything and everything. That would make it much easier to help a newbie,
>for one--you wouldn't have to say, "download menus.h" every time they said
>they wanted menus, for example.
I'm the wrong person to say this to, since I wrote both of the
alternative menuing systems. If menus.h was in the library, altmenu
wouldn't exist. (It's also not a great example because menuing is in
the standard library.)
But I think menus.h has a better case than most of the library
extentions out there, just because it's by graham. Rolling other
extentions into the library is tantamount to "canonizing" certain
extentions as "official".
Further, I think that "anything and everything" is sort of a silly
thing to say we want in the library. Should the library have
archetypes for common objects? Should it have money? Should it have
physics modeling? Ropes? Liquids? Most library extentions handle
things that are very game-specific in their implementation; if we
choose one rope implementation and add it to the library, then games
which want rope behavior which is incompatable with that
implementation are left out.
>
>The only real disadvantage of putting everything in the library is game
>size bloat, and it seems to me it wouldn't be terribly difficult to
>modularize the library so it was clever enough to not compile into the
>game bits that would never be called. If size is an issue for you at all.
>
How about creeping featurism? How many people would include things
that their game doesn't really call for because it's in the library?
How many inform games include sack objects?
>Having a modular library would also allow people to offer their own
>'menus.h' which could be dropped in easily if users needed the behavior
>changed.
>
Modular library, smarter compiler, none of this would I argue with.
>(And yes, I know 'menus.h' has a bug in it that modern interpreters
>complain about. This proves my point--if it was in the library, it would
>have been fixed much earlier.)
(Where exactly the bug lies is not quite clear; I consider it a bug in
the inform compiler myself. But I highly doubt it would have been
fixed any sooner for being in the library)
>
>Oh, and you need a menus.h in the library. Only way to go for
>invisicule-style hints, IMO.
>
With the possible exception of hints.h, which actually *does*
invisiclues-style hints (The functionality in menus.h only reproduces
the very first step of the way invisiclues were presented in infocom
games). There's also a program that produces inform source for an
invisiclues-style menu from non-inform input.
Andrew Plotkin
> L. Ross Raszewski <lrasz...@loyola.edu> wrote in <yPfoa.7642$yO5...@nwrddc02.gnilink.net>:
> : On 19 Apr 2003 00:34:49 -0700, Mr. J <john...@earthlink.net> wrote:
> :>There are a huge glut of "work arounds" that should be modernized.
> :>I'm interested in a larger Library so as not to have to code so much
> :>behavior code.
> : This a totally disagree about. The library is not the place for every
> : feature anyone can think of. The library is where stuff *every* game
> : should have goes, not where *anything any game might want* should go.
> You know, I think I disagree. The library *should* have stuff for
> anything and everything. That would make it much easier to help a newbie,
> for one--you wouldn't have to say, "download menus.h" every time they said
> they wanted menus, for example.
> The only real disadvantage of putting everything in the library is game
> size bloat, and it seems to me it wouldn't be terribly difficult to
> modularize the library so it was clever enough to not compile into the
> game bits that would never be called. If size is an issue for you at all.
I think everyone agrees with modular. :) It does require some degree
of compiler support, though. Inform's management of library extensions
is, shall we say, somewhat raw.
There are two practical problems with the "anything and everything"
approach. (Bear with me if you've heard this before. I'm mostly
responding to "Mr. J", above.)
1) Even a single world-model feature -- say, ropes -- has so many
possible variations that it's hard to write. No two games are going to
want the same implementation. Can you write library code that is
useful to everyone who wants the feature? Do you try to include every
variation, or the smallest common set, or something in between?
2) Features interfere with each other. Okay, menus.h isn't going to
interfere with ropes.h, but most world-model variations are going to
collide in strange ways; these will *certainly* have to be worked out
on a game-by-game basis.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.