Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

which IF system has best world model & parser?

333 views
Skip to first unread message

Ed

unread,
Jul 9, 2002, 2:50:15 PM7/9/02
to
I'm looking for opinions on which IF system (for which source code is
available) has the best world model, and which IF system has the best
parser.

Some clarification is in order:

By "best" I mean the most powerful, consistent, robust, and extensible.

My reason for asking is that I'm considering writing a class library (or
set of class libraries) for C# and/or Java to enable those languages to be
used for writing IF. I don't want to reinvent any more wheels than I have
to, so I'd like to take advantage of what's been done before. I plan to
study the source code for one or two existing IF systems as part of the
design process for my own system.

Also, I don't care about graphics, sound, or fancy typography, just a good
solid purely text-based IF system.

Somebody is bound to ask "why write yet another IF system?" My reasons are
personal:

1. I've spent a fair amount of time playing around with Inform, and taken a
close look at TADS and Hugo, and I don't like them. As a software engineer
with 20 years experience, and an admitted language bigot as well, I have a
strong preference for fully object-oriented languages with C-like syntax.

2. I need to become more fluent in C# (currently my favorite language) and
Java (currently my second-favorite language), and this seems like a fun
project to use a learning experience. I'm more interested in the
programming part of the learning experience than in a high-level redesign
of IF world model or parser architecture, hence my original question.

And a few more things...

Yes, I will give credit where credit is due to any systems I "steal" from.

No, I'm not planning on trying to sell this. If it does grow into a usable
system, I plan to share it for free with the IF community.

If someone has already done this, I'd like to hear about it.

-- Ed

wo...@one.net

unread,
Jul 9, 2002, 3:02:36 PM7/9/02
to

Hi Ed <e...@mewsic.SPAMGUARD.com> wrote:

>I'm looking for opinions on which IF system (for which source code is
>available) has the best world model, and which IF system has the best
>parser.

You might take a look at PAWS, it's written in pure Python so
all the source is available. I won't claim it's the best :)
but I'm told the code is easy to follow and it's been
documented to within an inch of its life...

http://w3.one.net/~wolf/PAWS.shtml


Respectfully,

Wolf

"The world is my home, it's just that some rooms are draftier than
others". -- Wolf

Neil Cerutti

unread,
Jul 9, 2002, 3:46:09 PM7/9/02
to
In article <Xns924696F5A38E7ed...@199.45.49.11>,

Ed wrote:
> I'm looking for opinions on which IF system (for which source
> code is available) has the best world model, and which IF
> system has the best parser.
>
> Some clarification is in order:
>
> By "best" I mean the most powerful, consistent, robust, and
> extensible.

The problem with this question is that, once you have learned the
object model of an IF system, you have finished learning that
system. In other words, you need to be an expert in every current
IF system to know the answer to your question.

Another problem is, some of the terms you use are too open to
subjective interpretation.

Several systems have been used to write hundreds of playable
games. I see those systems as robust.

Several systems have created huge games. I see those
systems as powerful and extensible.

I'm guessing that you may have different expectations. Mine are
fulfilled.

There is some good news, though. See below.

> My reason for asking is that I'm considering writing a class
> library (or set of class libraries) for C# and/or Java to
> enable those languages to be used for writing IF. I don't want
> to reinvent any more wheels than I have to, so I'd like to take
> advantage of what's been done before. I plan to study the
> source code for one or two existing IF systems as part of the
> design process for my own system.

Here's the good news:

The most popular IF systems, and even the up-and-comers, all have
excellent documentation. You can use those documents to
determine, for yourself, the state of the art in world model.

> Somebody is bound to ask "why write yet another IF system?" My
> reasons are personal:
>
> 1. I've spent a fair amount of time playing around with Inform,
> and taken a close look at TADS and Hugo, and I don't like them.
> As a software engineer with 20 years experience, and an
> admitted language bigot as well, I have a strong preference for
> fully object-oriented languages with C-like syntax.
>
> 2. I need to become more fluent in C# (currently my favorite
> language) and Java (currently my second-favorite language), and
> this seems like a fun project to use a learning experience.
> I'm more interested in the programming part of the learning
> experience than in a high-level redesign of IF world model or
> parser architecture, hence my original question.

Your first reason is unconvincing (Inform and TADS are both
object-oriented and C-like), but your second reason is obviously
compelling.

> And a few more things...
>
> Yes, I will give credit where credit is due to any systems I
> "steal" from.
>
> No, I'm not planning on trying to sell this. If it does grow
> into a usable system, I plan to share it for free with the IF
> community.
>
> If someone has already done this, I'd like to hear about it.

You would think that by now a C-library or C++-library would have
materialized that allowed you to write IF, but I honestly can't
think of one.

If I may suggest, you should consider using Glk for your I/O
layer. This will kill many birds.

--
Neil Cerutti <cer...@trans-video.net>

Tzvetan Mikov

unread,
Jul 9, 2002, 5:46:15 PM7/9/02
to

"Neil Cerutti" <cer...@trans-video.net> wrote in message
news:agfei1$l7p10$1...@ID-60390.news.dfncis.de...

> > If someone has already done this, I'd like to hear about it.
>
> You would think that by now a C-library or C++-library would have
> materialized that allowed you to write IF, but I honestly can't
> think of one.

I asked a question along these lines some time ago (the thread was called
"[Dis]Advantages of IF languages") and eventually became convinced that a
C/C++/C#/Java IF library would be very inconvenient to use, if not outright
impossible.

-tzvetan


Raybert

unread,
Jul 9, 2002, 6:17:19 PM7/9/02
to
Ed wrote:
> I'm looking for opinions on which IF system (for which source code is
> available) has the best world model, and which IF system has the best
> parser.
<snip>

> My reason for asking is that I'm considering writing a class library (or
> set of class libraries) for C# and/or Java to enable those languages to be
> used for writing IF. I don't want to reinvent any more wheels than I have
> to, so I'd like to take advantage of what's been done before. I plan to
> study the source code for one or two existing IF systems as part of the
> design process for my own system.
<snip>

> 2. I need to become more fluent in C# (currently my favorite language) and
> Java (currently my second-favorite language), and this seems like a fun
> project to use a learning experience. I'm more interested in the
> programming part of the learning experience than in a high-level redesign
> of IF world model or parser architecture, hence my original question.
<snip>

> If someone has already done this, I'd like to hear about it.


Hi Ed,

Coincidentally, you & I are in a similar situation.

I'm a SWE with 15 years experience who has been laid off for some
months. I'm also a huge text adventure fan from way back (in fact,
it's what got me interested in programming back in the early 80's).

I recently decided that I should do something constructive while I'm
unemployed. So I decided to start learning Java.

Around the same time I heard about IFComp 2002 and realized that
writing an adventure game would be a great way to learn Java!

I've been working on the game for a few weeks now and it's coming
along pretty well. My parser is now mostly finished and I'm working
on the remaining game infrastructure. I have a game idea from many
years ago that I'm planning to implement with this code.

I'm not writing an IF system though; rather, just a standalone game.
Therefore, the code I'm writing is specific to the game that I plan to
develop. But it is written in Java and is therefore OO and many
components will be re-usable. Perhaps the start of a class library?

I briefly considered writing an IF system, but decided not to. I've
explored TADS in the past and thought it was pretty well done. So, if
I just wanted to develop IF, I would probably use TADS (I haven't
looked at the other IF systems out there though so I can't compare).
My main goal is really to learn Java. I didn't want to commit to too
large of a project and I also didn't want to re-create a perfectly
good wheel (TADS). So I decided to limit my project to just a
standalone game (for now anyway).

This decision led me to some design decisions that do not lend
themselves to an IF system (which needs to be divorced from any
specific game data). For example, things (like vocabulary words, game
objects, game locations, etc.) in my game are identified internally
with constant integer IDs which allow game code to refer to specific
things in a direct and efficient manner. A real IF system would have
to use only runtime object references resolved through a dictionary
and manipulated through an external game script.

A class library or framework is another thing entirely though. Such a
thing would be intended for game developers who wish to work in Java,
rather than a 3GL, such as TADS. I think my classes could be modified
to serve as some basis for a framework or class library. Some
specifics would have to be separated out and the ID system would have
to be re-thought to some degree. But I think it could work.

I've employed some ideas in my parser that I've been carrying around
with me for some years. Since I had already given a lot of thought
over the years about how to parse for text adventures, I was pretty
much able to jump right into the programming. I believe the resulting
parser is about as smart as Infocom's.

I have a lot more work to do yet, but I hope to have a simple game up
and running in the next week. After that, it'll be mostly a matter
populating the game with locations, objects, and verbs.

So, anyway, FWIW... maybe this means we should talk about
collaboration? maybe it's just a curiosity? I dunno... ;)

Good luck with whatever you decide to do.

[ray]

PS: I've found that Java interfaces are very powerful for implementing
special attributes of game objects. (e.g. lockable; openable; etc.)

John

unread,
Jul 9, 2002, 7:20:54 PM7/9/02
to
Ray,

I am interested in what you did for the parsing.

Do you search the input string for verbs, nouns, etc and go from there, or
do you do it a different way?

What kind of commands can you cope with?

For instance, "get the green robe and put it on" ?

John.

"Raybert" <senorv...@yahoo.com> wrote in message
news:c023b4af.02070...@posting.google.com...

Raybert

unread,
Jul 10, 2002, 4:28:56 AM7/10/02
to
"John" <nojgoa...@hotmail.com> wrote in message news:<qdKW8.2205$Kx3....@newsread1.prod.itd.earthlink.net>...

> Ray,
>
> I am interested in what you did for the parsing.
>
> Do you search the input string for verbs, nouns, etc and go from there, or
> do you do it a different way?
>
> What kind of commands can you cope with?
>
> For instance, "get the green robe and put it on" ?
>
> John.

Hi John,

My parser has three stages to it.

The first is the lexical parsing stage, where I extract the words and
look them up in a dictionary to make sure they're known to the game.
I also discard useless words at this time, such as articles (i.e.
"the", "a", "an").

Next is the classify stage, where I try to assign a grammatical type
to each word (verb, noun, adjective, etc.). To do this, I use a
position-dependent algorithm, which I'll describe below.

Last is the "resolve" stage, where I try to resolve the words to
internal game objects (the verb resolves to a verb handler class and
each object to a game object class).

If everything works correctly I end-up with a Command object that
contains references to the verb and object handlers (as well as the
original sentence in case it's needed later).

The rules for the classify stage go something like this:

- the first word is always a verb

- in a simple (verb/noun) sentence, the direct object is always the
last word

- an indirect object can only exist in a prepositional phrase, which
must begin with a preposition; I have a list of prepositions and I
search words #3 through #n-1 for a match; if a prep is found, the word
directly to the left of it is the direct object and the last word in
the sentence is the indirect object

- if a preposition is found in the second position I assume that the
sentence uses the "implied self" form; e.g. in "look at picture" the
direct object is the implied "you" -- i.e. "look you at picture", or,
more properly, "you look at picture" (remember, from English class:
who is doing the looking? "you" :)

- I can also recognize an adverb in the last position; e.g. "turn
light on"

- any noun/object can be preceded by an adjective

After assigning a grammatical type to each word I check to see if I
missed any words; if I did, I assume that the sentence uses a
structure that I don't understand and issue an error message.

This logic allows the following types of sentences:

look
examine the red key
open the wooden door with the gold key
turn the oil lamp on
look at the faded picture
look behind the oil painting

I also provide special support for "and" and "then" (I admit it's been
a while since I played an Infocom game, but I think this is how they
did it):

- AND is used to join multiple direct objects together to all receive
the same action. e.g. take gold key and rock and red ball

- THEN is used to join together multiple verb clauses (sentences).
e.g. "get the green robe THEN put it on" [;)]

AND can be abbreviated with a comma and THEN can be abbreviated with a
period. e.g. "take gold key, rock. open door with key. throw rock"

I handle AND and THEN by generating multiple sentences, internally,
during the classify stage. If THEN is used, the sentence is split at
each THEN. If AND is used, the affected sentence is copied multiple
times and each copy gets one of the objects. Thus, the command
execution stage (which follows the parsing stage) is greatly
simplified: it only has to deal with one verb, one direct object, and
one indirect object.

I also support the special word "it" (as demonstrated above in the
"green robe" example). IT always refers to the direct object in the
previous verb clause. If there was no D.O. in the previous V.C., IT
cannot be resolved and an error results.

I also support the special word "all", which can be used with verbs
like take, drop, put, etc., to manipulate all objects within reach.
(However, ALL isn't resolved in the parser like everything else
mentioned above. I have a dummy object in the game called ALL which
tricks the parser into thinking a normal object has been referenced.)

After writing my earlier post today, I did some thinking and had an
epiphany, of sorts. ;) Briefly, I had been writing bunches of ugly ad
hoc code to validate prepositions and adverbs and I knew deep inside
of me that it was wrong to do it this way. After some thought, I
realized that prepositions and adverbs, although they are technically
different parts of speech, really serve the same purpose in a verb
clause: they modify the verb. Thus, I realized that I could simplify
my logic by calling them "verb modifiers" and treat them very much
like adjectives (which are essentially noun modifiers)!

Adjectives and nouns are paired for processing; i.e. if the user types
"gold key" it can only match an object that has the same noun and
adjective. (However, the game allows the adjective to be omitted if
there's only one "key" available.)

Likewise, verbs and their modifiers should be paired together as well!
Instead of matching just the verb and then writing ugly code to
verify the correctness of the modifier, a verb/modifier pair actually
constitute a unique verb!

For example, "look at picture" and "look behind picture" are both uses
of LOOK. BUT, "look at" and "look behind" are really two very
different things. Therefore, the game should have two separate verbs:
"look at" and "look behind". If verb matching is performed in this
manner, there is no further need to validate the verb modifier.

Another example: "put key in box" and "put key under rock" both use
PUT, but are really two different verbs: "put in" and "put under".

Another example (different sentence form): "turn lamp on" and "turn
lamp off" are two separate verbs: "turn on" and "turn off".

I'm sure that I'm not the first to think of this and some folks who
read this will laugh and say "No shit Sherlock! We knew that all
along!!" Well, good for you. And good for me too because now I know
it too. ;)

Further thinking through of this concept led me to convince myself
that I don't need specific verb handling classes (as I currently
have), but rather, verbs should be implemented within the object/noun
classes (with default processing supplied in the base class).
Furthermore, if the verb/modifier matching is done in the object
classes in this manner, virtually all of my vocabulary will be defined
in a distributed manner within the object classes and my dictionary
can be generated at runtime when the objects are created and
registered. This will allow me to do away with having to predefine a
vocabulary and hand-generate word IDs, etc. When I want to add a new
object to the game, I simply create a new class and specify the verbs
(and verb modifiers) that it will use right there in the new class.
This is much, much simpler than my current program architecture and it
means I have a bunch of new work to do. :)

(IIRC, TADS defines verbs as members of objects and I knew this so I
should have thought of this sooner. But, I'm writing Java code not a
3GL, so it's slightly different. I don't remember how TADS handles
verb modifiers, or if it even does.)

When I wrote earlier to Ed I mentioned that my code uses hard-coded
IDs, etc. But I now have a vision for a new architecture that will
not need anything of the sort and which can be neatly organized into a
generic reusable Java class library. And, believe it or not, the
changes required to my existing code will not be very extensive.

As I said, I have some work to do... ;)

[ray]

Plugh!

unread,
Jul 10, 2002, 4:30:34 AM7/10/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote in message news:<Xns924696F5A38E7ed...@199.45.49.11>...

> I'm looking for opinions on which IF system (for which source code is
> available) has the best world model, and which IF system has the best
> parser.

Despite your previous dislike of TADS 2, the anwer is undoubtedly TADS 3.

Ed

unread,
Jul 10, 2002, 7:57:33 AM7/10/02
to
"Tzvetan Mikov" <ce...@jupiter.com> wrote:
>> You would think that by now a C-library or C++-library would have
>> materialized that allowed you to write IF, but I honestly can't
>> think of one.
> I asked a question along these lines some time ago (the thread was
> called "[Dis]Advantages of IF languages") and eventually became
> convinced that a C/C++/C#/Java IF library would be very inconvenient
> to use, if not outright impossible.

Could you go into more detail, please?

Thanks,

-- Ed

Ed

unread,
Jul 10, 2002, 8:24:57 AM7/10/02
to
NOTE: I suspect this is a topic which has been revisited often. This
message is a response to a remark someone made, and is NOT intended as an
attack on any of the IF systems I mention. I am expressing my own
opinions, and not trying to start a flame war.

In a previous thread ("which IF system has best world model & parser") I
wrote:


>> 1. I've spent a fair amount of time playing around with Inform,
>> and taken a close look at TADS and Hugo, and I don't like them.
>> As a software engineer with 20 years experience, and an
>> admitted language bigot as well, I have a strong preference for
>> fully object-oriented languages with C-like syntax.

Neil Cerutti <cer...@trans-video.net> replied:


> Your first reason is unconvincing (Inform and TADS are both
> object-oriented and C-like),

Okay, here's a laundry list of what I don't like about what seems to be
the "big three" (Inform, TADS and HUGO). I didn't look at any of the
systems which advertised themselves as being GUI- or forms-driven, or
sought to minimize "programming".

All three lack support for floating point.
All three use dynamic rather than static typing.

Inform
Routine definition, using square brackets, is definitely not C-like.
Integers appear to be limited to 16 bits.
The 'for' statement is not C-like.

HUGO
The only data type seems to be 16-bit integers.
Line endings are significant; long lines must be broken up with '\'.
'!' for comments instead of '/* */' and '//'.
Boolean operators are words ('and', 'or').

TADS
Inconsistent use of curly braces.
Non-C-like use of semicolons.
Assignment operator is ':=', not '='.
Local variables must be explicitly declared 'local'.

Please don't tell me I "don't need" floating point or 32-bit integers.
If you don't need them, that's fine. I refuse to get into a religious
war over static vs. dynamic typing; suffice to say that my personal
preference is for static typing because it helps me find more bugs at
compile time.

-- Ed


Ed

unread,
Jul 10, 2002, 8:08:58 AM7/10/02
to
Neil Cerutti <cer...@trans-video.net> wrote:
> The problem with this question is that, once you have learned the
> object model of an IF system, you have finished learning that
> system. In other words, you need to be an expert in every current
> IF system to know the answer to your question.

Well, I was sort of hoping that there might be a person or two out there
who has, in fact, done that research and would be willing to share their
opinions.



> Several systems have been used to write hundreds of playable
> games. I see those systems as robust.

If you're implying that a system is robust because it has been used
widely and successfully, then I disagree with your definition. I use
"robust" to mean something more like "free of bugs" and "handles errors
gracefully". A non-robust system can certainly be used, but the user has
to learn how to avoid breaking it.



> Several systems have created huge games. I see those
> systems as powerful and extensible.

Again, I think I'm using a different definition of "extensible". I mean
that the fundamental capabilities of the game engine and/or language can
be extended. For example, a system may come with support for travelling
north, south, east, west, but not ne, se, sw, and nw; if that system is
extensible, I should be able to add the missing directions. Being able
to create thousands of rooms doesn't make it extensible, by my
definition.



> I'm guessing that you may have different expectations. Mine are
> fulfilled.

Quite so. I am not here to bash the existing systems, or win over anyone
to my point of view.



> The most popular IF systems, and even the up-and-comers, all have
> excellent documentation. You can use those documents to
> determine, for yourself, the state of the art in world model.

This is good to know.



>> 1. I've spent a fair amount of time playing around with Inform,
>> and taken a close look at TADS and Hugo, and I don't like them.
>> As a software engineer with 20 years experience, and an
>> admitted language bigot as well, I have a strong preference for
>> fully object-oriented languages with C-like syntax.
>

> Your first reason is unconvincing (Inform and TADS are both
> object-oriented and C-like),

Oh dear, I'm afraid I really must address this in detail (sigh), but I'll
do it in a separate thread.

> If I may suggest, you should consider using Glk for your I/O
> layer. This will kill many birds.

I've seen Glk described; this sounds like a good idea.

Thanks for the feedback,

-- Ed


Ed

unread,
Jul 10, 2002, 8:27:56 AM7/10/02
to
senorv...@yahoo.com (Raybert) wrote:
> Coincidentally, you & I are in a similar situation.
> I'm a SWE with 15 years experience who has been laid off for some
> months.

I've also been pounding the pavement since March.

> So, anyway, FWIW... maybe this means we should talk about
> collaboration? maybe it's just a curiosity? I dunno... ;)

I'm certainly open to the idea. I'm a lousy correspondent at the best of
times, and I'm in the middle of moving, so if you don't hear from me, feel
free to check in. Remove the spamguard from my e-mail address.

-- Ed

Neil Cerutti

unread,
Jul 10, 2002, 8:47:32 AM7/10/02
to
In article <Xns924752ECDC224ed...@199.45.49.11>,

Ed wrote:
> Neil Cerutti <cer...@trans-video.net> wrote:
>> The problem with this question is that, once you have learned
>> the object model of an IF system, you have finished learning
>> that system. In other words, you need to be an expert in every
>> current IF system to know the answer to your question.
>
> Well, I was sort of hoping that there might be a person or two
> out there who has, in fact, done that research and would be
> willing to share their opinions.

There are some. I know a very few authors have even released
games written in different systems.

The other thing that may stop this thread before much good
discussion ensues is how unwilling this group has been, historically,
to enter into language wars.

>> Several systems have been used to write hundreds of playable
>> games. I see those systems as robust.
>
> If you're implying that a system is robust because it has been
> used widely and successfully, then I disagree with your
> definition. I use "robust" to mean something more like "free
> of bugs" and "handles errors gracefully". A non-robust system
> can certainly be used, but the user has to learn how to avoid
> breaking it.

What I meant is that most of the current, popular systems are
robust enough for the purposes of creating IF games. That isn't
to say that people would not welcome an even *more* robust
system.

>> Several systems have created huge games. I see those systems
>> as powerful and extensible.
>
> Again, I think I'm using a different definition of
> "extensible". I mean that the fundamental capabilities of the
> game engine and/or language can be extended. For example, a
> system may come with support for travelling north, south, east,
> west, but not ne, se, sw, and nw; if that system is extensible,
> I should be able to add the missing directions. Being able to
> create thousands of rooms doesn't make it extensible, by my
> definition.

I agree with your definition.

Most of the IF systems, as you might have guessed, can be easily
extended in ways that were anticipated by the authors. For
example, adding new verbs, actions, objects, and directions (as
above) is very easy with the Inform language and library.

They can also be extended in ways that were not anticipated, but
it's more work. For example, adding useful NPC action handling in
Inform is quite difficult. This is one area where a new system
can make a lot of headway, as far as I'm concerned. But I'm not
really aware of TADS3's capabilities in this area, and HUGO also
made some strides in this direction. There has been a lot of work
done for Inform in this area by 3rd parties, but unfortunately
I'm not that familiar with how they work and I don't think
they've really been used yet.

The most difficult thing to do is not extending the world models,
but when the time comes that you have to violate the world model
For example, in Inform, it's hard to create an object that you
can put things in and on top of, because Inform uses a very
simple object tree to handle containment.

Room <--> Box <--> Apple

The Apple is either in the box or on the box, depending on a
property of the box.

>> I'm guessing that you may have different expectations. Mine
>> are fulfilled.
>
> Quite so. I am not here to bash the existing systems, or win
> over anyone to my point of view.
>
>> The most popular IF systems, and even the up-and-comers, all
>> have excellent documentation. You can use those documents to
>> determine, for yourself, the state of the art in world model.
>
> This is good to know.
>
>>> 1. I've spent a fair amount of time playing around with
>>> Inform, and taken a close look at TADS and Hugo, and I don't
>>> like them. As a software engineer with 20 years experience,
>>> and an admitted language bigot as well, I have a strong
>>> preference for fully object-oriented languages with C-like
>>> syntax.
>>
>> Your first reason is unconvincing (Inform and TADS are both
>> object-oriented and C-like),
>
> Oh dear, I'm afraid I really must address this in detail
> (sigh), but I'll do it in a separate thread.

This type of debate is often found on this newsgroup, and it will
probably be welcome, as long as the discussion remains focused on
the applicability of object-oriented programming concepts to IF.
In other words, pointing out ways in which TADS or Inform are not
fully object oriented will be more useful if the shortcomings you
see can be related to IF development.

There are some old threads on Google where language design for IF
was discussed and argued in depth, and I found it very
interesting.

--
Neil Cerutti <cer...@trans-video.net>

Ed

unread,
Jul 10, 2002, 8:55:10 AM7/10/02
to
pl...@plugh.info (Plugh!) wrote:
> Despite your previous dislike of TADS 2, the anwer is undoubtedly TADS
> 3.

I just looked over the T3 docs, and ... Wow! I think you may be right. T3
seems to fix almost (but not quite) everything I don't like about T2,
Inform and HUGO.

Thanks for bringing this to my attention!

-- Ed

Neil Cerutti

unread,
Jul 10, 2002, 9:26:55 AM7/10/02
to
In article <Xns924755A2D30A1ed...@199.45.49.11>, Ed wrote:
> NOTE: I suspect this is a topic which has been revisited often. This
> message is a response to a remark someone made, and is NOT intended as an
> attack on any of the IF systems I mention. I am expressing my own
> opinions, and not trying to start a flame war.
>
> In a previous thread ("which IF system has best world model & parser") I
> wrote:
>>> 1. I've spent a fair amount of time playing around with Inform,
>>> and taken a close look at TADS and Hugo, and I don't like them.
>>> As a software engineer with 20 years experience, and an
>>> admitted language bigot as well, I have a strong preference for
>>> fully object-oriented languages with C-like syntax.
>
> Neil Cerutti <cer...@trans-video.net> replied:
>> Your first reason is unconvincing (Inform and TADS are both
>> object-oriented and C-like),
>
> Okay, here's a laundry list of what I don't like about what
> seems to be the "big three" (Inform, TADS and HUGO). I didn't
> look at any of the systems which advertised themselves as being
> GUI- or forms-driven, or sought to minimize "programming".
>
> All three lack support for floating point.

There are a few 3rd-party libraries available to help with this.
So there is *some* support.

> All three use dynamic rather than static typing.

Not really. Inform, for example, is in fact statically typed, it
just doesn't do any static checking for you. Basically,
everything is a 16-bit number (or 32-bit number for Glulx) that
operates a lot like a pointer that you dereference with different
operators depending on what it points to. It's a bit like Perl.

If x is a dictionary word:

print (address) x;

If x is a compressed string:

print (string) x;

If x is an object with a short_name property:

print (name) x;

If x is a routine that prints something:

x();

Inform does provide a little bit of RTTI. You can find out if a
value is an Object, a Routine, a String, or none of the
above using the ZRegion routine.

> Inform
> Routine definition, using square brackets, is definitely
> not C-like.

Inform is definitely the least C-like of the three under
consideration. The three-tiered system of using square brackets to
define routine blocks, and curly-brackets to define other code
blocks, and "Object" and ";" for object delimiters is a little
silly.

On the other hand, Inform has a lot of non-C-like syntax that is
really very useful for writing IF. For example, all routines are
an implicit switch (action) statement if you want to treat them
that way. This makes writing before, after, and its ilk very
convenient.

> Integers appear to be limited to 16 bits.

This is a limitation of the virtual machine to which you compile.
If you compile to Glulx, you get 32-bit numbers.

> The 'for' statement is not C-like.

This is a sore spot for a lot of people. However, using the
C-like syntax is accepted and merely generates a warning.

> HUGO
> The only data type seems to be 16-bit integers.
> Line endings are significant; long lines must be broken up with '\'.
> '!' for comments instead of '/* */' and '//'.

'/* */' comments are not good, e.g., x = 5/*b, cannot be nested,
etc. So I'm not surprised some people opted for line comments
only.

> Boolean operators are words ('and', 'or').

They can be words in C, too.

> TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.

This is an option in TADS. You may opt for the C versions of
these operators with a compiler switch.

> Local variables must be explicitly declared 'local'.

You can probably see that I know a lot more about Inform that
about the other languages under discussion. ;-)

--
Neil Cerutti <cer...@trans-video.net>
*** Mischievous glak elves broke into your storage shed and
stole half your food. ***

Matthew Russotto

unread,
Jul 10, 2002, 10:04:59 AM7/10/02
to
In article <agflj7$1...@dispatch.concentric.net>,

Tzvetan Mikov <ce...@jupiter.com> wrote:
>
>I asked a question along these lines some time ago (the thread was called
>"[Dis]Advantages of IF languages") and eventually became convinced that a
>C/C++/C#/Java IF library would be very inconvenient to use, if not outright
>impossible.

A preprocessor could solve the major obstacle (all those one-off objects). But
then it's not really C/C++/C#/Java, I guess..

--
Matthew T. Russotto mrus...@speakeasy.net
=====
Every time you buy a CD, a programmer is kicked in the teeth.
Every time you buy or rent a DVD, a programmer is kicked where it counts.
Every time they kick a programmer, 1000 users are kicked too, and harder.
A proposed US law called the CBDTPA would ban the PC as we know it.
This is not a joke, not an exaggeration. This is real.
http://www.cryptome.org/broadbandits.htm

OKB (not okblacke)

unread,
Jul 10, 2002, 11:45:06 AM7/10/02
to
Neil Cerutti wrote:
> Inform does provide a little bit of RTTI. You can find out
> if a value is an Object, a Routine, a String, or none of
> the above using the ZRegion routine.

Just a little side note: this is really a "fake" mechanism. It doesn't have any internal notion of the
type of anything -- it converts everything to a number and then essentially decides what the type is
based on how big the number is. (That is, it says something like "ok, things with numbers 8000-10000
are objects, numbers 10001-150000 are strings, etc.") This mapping works when you're actually doing
things like metaclass(SomeObj) and metaclass("A string"), but it pays to be careful, because it's possible
for, say, metaclass(13207) to return Routine.

--
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

Ed

unread,
Jul 10, 2002, 12:11:09 PM7/10/02
to
Neil Cerutti <cer...@trans-video.net> wrote:
> The other thing that may stop this thread before much good
> discussion ensues is how unwilling this group has been, historically,
> to enter into language wars.

Well, I was hoping to avoid that. Between well-informed people, language
wars invariably, in my experience, boil down to issues of personal
preference.

>For example, adding useful NPC action handling in
>Inform is quite difficult.

Yes, I discovered that, in detail. :-)

> There are some old threads on Google where language design for IF
> was discussed and argued in depth, and I found it very
> interesting.

I'll look for it.

Thanks again,

-- Ed

John

unread,
Jul 10, 2002, 1:02:10 PM7/10/02
to
Ray

Thankyou for taking the time to make this post. It was very helpful for me.
I have been taking a similar approach using verbs as methods. That made the
most sense to me. I got to the point of splitting sentences and ignoring
"the,an,a" etc. Also implemented "it" much the same way.

My current method of attack is using regular expressions. Currently the
seem to make this very easy and compact. I wonder why there are not
predominantly Perl-based text adventure systems?

I would like to hear from the players in this group to find out if there are
other types of commands that they would deem necessary for an interactive
fiction game:

look
examine the red key
open the wooden door with the gold key
turn the oil lamp on
look at the faded picture
look behind the oil painting

take the book then look at it take the
book. Look at it
take the book and the gold key take the
book, gold key

Possibly also a minimal vocabulary?

You know, this would be awesome to capture somewhere (it its not already),
as a series of test cases for adventures. Maybe have different levels of
functionality. Could set up a simple specific location, maybe from one of
the classic games with a couple of rooms for navigation. It could be like a
hello world of IF? Just a thought.

I am not suggesting that someone else do all the work. I would be quite
willing to help collect all the information together. I would even host the
web pages if we get that far. I just respect the people of this groups
opinions in this regard more than mine for playing these games.

Given the sporadic nature of information related to creating a text
adventure game, I would also likely add help related to that on the site
too. This may go someway to help raise the level of submissions and thus
reduce the 99% crap number !!!! ;-)

John.

"Raybert" <senorv...@yahoo.com> wrote in message

news:c023b4af.0207...@posting.google.com...

Adam Thornton

unread,
Jul 10, 2002, 1:51:54 PM7/10/02
to
In article <Xns924755A2D30A1ed...@199.45.49.11>,

Ed <e...@mewsic.SPAMGUARD.com> wrote:
>NOTE: I suspect this is a topic which has been revisited often. This
>message is a response to a remark someone made, and is NOT intended as an
>attack on any of the IF systems I mention. I am expressing my own
>opinions, and not trying to start a flame war.

OK. In the same sprit:

>Okay, here's a laundry list of what I don't like about what seems to be
>the "big three" (Inform, TADS and HUGO). I didn't look at any of the
>systems which advertised themselves as being GUI- or forms-driven, or
>sought to minimize "programming".
>
>All three lack support for floating point.
>All three use dynamic rather than static typing.

There have been Inform libraries which implement IEEE FP, or at least a
significant subset thereof. I don't know if any such thing has been
done with TADS or Hugo. I'll accept that as you say below, dynamic
vs. static typing is a religious issue with you, but as I don't see why
it matters, I won't comment.

>Inform
> Routine definition, using square brackets, is definitely not C-like.
> Integers appear to be limited to 16 bits.
> The 'for' statement is not C-like.

Routine definition is definitely not C-like. "For" seems pretty C-like
except that it uses colons rather than semicolons as statement
separators, IIRC. Which trips me up every time I start a new Inform
project too.

Integers are 16-bit in Inform-compiling-to-zcode, and 32-bit in Glulx
Inform. I'm pretty sure there are library extensions to give you
arbitrarily-sized integers as well.

>HUGO
> The only data type seems to be 16-bit integers.
> Line endings are significant; long lines must be broken up with '\'.
> '!' for comments instead of '/* */' and '//'.
> Boolean operators are words ('and', 'or').

I don't know Hugo, so I can't comment.

>TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.
> Local variables must be explicitly declared 'local'.

I think the assignment operator is switchable with a pragma, which may
also ameliorate the curly-brace problem. Dunno.

>Please don't tell me I "don't need" floating point or 32-bit integers.
>If you don't need them, that's fine. I refuse to get into a religious
>war over static vs. dynamic typing; suffice to say that my personal
>preference is for static typing because it helps me find more bugs at
>compile time.

It seems to me that what you need is not a new IF development language,
but a preprocessor wrapped around one of the existing ones that sugars
the syntax for you. m4 could probably be applied usefully here.

Adam

L. Ross Raszewski

unread,
Jul 10, 2002, 2:04:01 PM7/10/02
to
On Wed, 10 Jul 2002 12:24:57 GMT, Ed <e...@mewsic.SPAMGUARD.com> wrote:
>
>All three lack support for floating point.

True. Fair comment even.

>All three use dynamic rather than static typing.
>

!!

IF is not well suited to static typing.

>Inform
> Routine definition, using square brackets, is definitely not C-like.
> Integers appear to be limited to 16 bits.

True depending on the platform to which it is compiled. SImilarly, in
C, an integer is limited to 16 bits if your target platform is, say, DOS.

> The 'for' statement is not C-like.
>
>HUGO
> The only data type seems to be 16-bit integers.
> Line endings are significant; long lines must be broken up with '\'.
> '!' for comments instead of '/* */' and '//'.
> Boolean operators are words ('and', 'or').
>
>TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.
> Local variables must be explicitly declared 'local'.

>
>Please don't tell me I "don't need" floating point or 32-bit integers.
>If you don't need them, that's fine. I refuse to get into a religious
>war over static vs. dynamic typing; suffice to say that my personal
>preference is for static typing because it helps me find more bugs at
>compile time.

That's true. It's one of the things PL guys discovered about static
typing. But I don't think it would really be advantageous in an IF
language; it's been discussed recently that in most contexts, you
actually can't statically type; if the input to some routine is an
object typed in by the player, it could be of any class. Obviously,
you could statically type the 'metaclasses' -- constrain variables to
be one and only one of <number>,<object>, <string>, or <routine>,
say. This, of course, would greatly complicate a lot of the
polymorphic properties of, say, inform, unless you always used the
type "thingy", in which case, it wouldn't be very good at catching
errors at compile time.

Also, I notice that the majority of your complaints seem to be "syntax
isn't identical to C". These lagnauges aren't C, and I think it's not
alway fair to make the blanket claim that "all languages should have
identical syntax to C". Perl, Pascal, ML, and SQL don't have the same
syntax as C and this isn't generally taken as a weakness of any
sort. Of course, you're expressing your personal preference ('Why I
don't like them'), but you're doing it in a context where 'what's
wrong with them' is implied.

Robb Sherwin

unread,
Jul 10, 2002, 3:07:07 PM7/10/02
to
On Wed, 10 Jul 2002 17:51:54 +0000 (UTC), ad...@fsf.net (Adam Thornton)
wrote:

>In article <Xns924755A2D30A1ed...@199.45.49.11>,
>Ed <e...@mewsic.SPAMGUARD.com> wrote:
>>HUGO
>> The only data type seems to be 16-bit integers.
>> Line endings are significant; long lines must be broken up with '\'.
>> '!' for comments instead of '/* */' and '//'.
>> Boolean operators are words ('and', 'or').
>I don't know Hugo, so I can't comment.

The last two items stems from the fact that -- as far as I can tell --
one of the main points of Hugo is that the code anyone can generate
with it is extremely readable. To the point of readability, in fact,
being somewhat enforced. I've only been seriously programming on a
regular basis for three or four years now, so I'm still firmly of the
mindset that while it's impressive to have multiple things going on in
any given, single line of code, it doesn't do me much good when trying
to make sense out of it. However, because Hugo demands that you write
your code in such a manner, it puts rookies and veterans on a kind of
equal level. There are some library contributions that were written by
people like Cardinal Teubachs and John Menichelli -- guys who
obviously know what they are doing. I was able to follow along in the
Hugo port of Zork before I really had a grasp of the language, though,
because regardless of how intricate those guys would like (or dislike)
to be, they had to generate output that was quite approachable to my
newb self.

I think the first two parts mentioned in the quoted text above are
that way due to older operating systems and machines still being able
to run Hugo games perfectly well (though I'm not 100% certain that's
it -- Kent would know for sure.) It's never really bothered me,
though, because I'd rather my stuff be accessible to the whole of text
adventure fans regardless of what OS they were running than have some
features that would be cool for the Windows XP and OS-X ports of Hugo
but shut me off from older systems. But Ed's coming into this from the
experiences of someone with a lot more professional experience than I,
and I can absolutely see where he's coming from. His points in this
are well-taken.

Robb
=-=-=-=-=-
Robb Sherwin, Fort Collins CO
Jolt Country BBS: www.joltcountry.com/phpBB2
Reviews From Trotting krips: www.joltcountry.com/trottingkrips

Ed

unread,
Jul 10, 2002, 3:03:10 PM7/10/02
to
ad...@fsf.net (Adam Thornton) wrote:
> There have been Inform libraries which implement IEEE FP, or at least
> a significant subset thereof. I don't know if any such thing has been
> done with TADS or Hugo. I'll accept that as you say below, dynamic
> vs. static typing is a religious issue with you, but as I don't see
> why it matters, I won't comment.

In the spirit of explanation (not argument), the value of static typing is
that you can catch more bugs at compile time, when *all* the code is
processed all at once. For example, if you have a routine which expects a
string, and will fail miserably if it is passed anything else, and you try
to pass it something else, with static typing, the code where you try to
pass it something else will fail to compile. With dynamic typing, the
error won't be found until the code actually executes, and possibly not
until just the right set of circumstances occur, making the bug harder to
track down.

In fairness, dynamic typing has its own advantages.

More about this elsewhere in this thread...

-- Ed

Ed

unread,
Jul 10, 2002, 3:11:44 PM7/10/02
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
> IF is not well suited to static typing.
> ...

> it's been discussed recently that in most contexts, you
> actually can't statically type; if the input to some routine is an
> object typed in by the player, it could be of any class. Obviously,
> you could statically type the 'metaclasses' -- constrain variables to
> be one and only one of <number>,<object>, <string>, or <routine>,
> say. This, of course, would greatly complicate a lot of the
> polymorphic properties of, say, inform, unless you always used the
> type "thingy", in which case, it wouldn't be very good at catching
> errors at compile time.

I don't see how it would upset polymorphism. I see how it might be
advantageous in an IF system to not statically distinguish between
different classes of objects, but static checking for the "metaclasses", as
you called them (string, integer, float, boolean, array, and object) seems
to me to be highly desirable. Perhaps the problem you're thinking of would
be solved (in a statically typed language) by method overloading.?

> Also, I notice that the majority of your complaints seem to be "syntax
> isn't identical to C". These lagnauges aren't C, and I think it's not
> alway fair to make the blanket claim that "all languages should have
> identical syntax to C". Perl, Pascal, ML, and SQL don't have the same
> syntax as C and this isn't generally taken as a weakness of any
> sort. Of course, you're expressing your personal preference ('Why I
> don't like them'), but you're doing it in a context where 'what's
> wrong with them' is implied.

Yes, in retrospect, "what's wrong with some existing IF languages" wasn't
the best title.

-- Ed

OKB (not okblacke)

unread,
Jul 10, 2002, 3:23:15 PM7/10/02
to
John wrote:

> You know, this would be awesome to capture somewhere (it
> its not already), as a series of test cases for adventures.
> Maybe have different levels of functionality. Could set
> up a simple specific location, maybe from one of the
> classic games with a couple of rooms for navigation. It
> could be like a hello world of IF? Just a thought.

Sounds like Roger Firth's "Cloak of Darkness": http://www.firthworks.com/roger/cloak/

Nikos Chantziaras

unread,
Jul 10, 2002, 3:39:26 PM7/10/02
to
"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924696F5A38E7ed...@199.45.49.11...
> My reason for asking is that I'm considering writing a class library
> (or set of class libraries) for C# and/or Java to enable those
> languages to be used for writing IF. [...]

Since you're using C# and Java, I recommend taking a look at the Tads3
sources. They're written in OO C++. Its world model should be
adaptable to any other OO language.

-- Niko


Nikos Chantziaras

unread,
Jul 10, 2002, 4:08:36 PM7/10/02
to
"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924755A2D30A1ed...@199.45.49.11...

> Okay, here's a laundry list of what I don't like about what seems to be
> the "big three" (Inform, TADS and HUGO). I didn't look at any of the
> systems which advertised themselves as being GUI- or forms-driven, or
> sought to minimize "programming".
>
> All three lack support for floating point.
> All three use dynamic rather than static typing.

Add the following:
No private/protected members.
No private/protected inheritance.

> TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.

Huh?

> Assignment operator is ':=', not '='.

You can change this:

#pragma C+

This turns on C-operators. ('==' for comparing, '=' for assignments).

> Local variables must be explicitly declared 'local'.

C works the same way, but instead of 'local' you must give a datatype.
Since Tads doesn't support compile-type datatypes, we must use 'local'.

> Please don't tell me I "don't need" floating point or 32-bit integers.
> If you don't need them, that's fine.

This may be a lame answer, but have you considered using fixed-point
numbers?

> I refuse to get into a religious
> war over static vs. dynamic typing; suffice to say that my personal
> preference is for static typing because it helps me find more bugs at
> compile time.

I'm having a discussion about this with M. Roberts, and at the end it seems
that
it's impossible, even with C++, to avoid dynamic typing (you find the
discussion
in thread "[TADS 2] OO Library Design Questions From a Newbie").

-- Niko


Iain Merrick

unread,
Jul 10, 2002, 4:10:36 PM7/10/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote:

> I am expressing my own opinions, and not trying to start a flame war.

Cool. I think your points are well worth making, by the way, even if
they are a little contentious, so thanks for posting.

[...]


> Okay, here's a laundry list of what I don't like about what seems to be
> the "big three" (Inform, TADS and HUGO).

[...]


> All three lack support for floating point.

Have you looked at TADS 3? It has floating point support, among other
features, and lots of syntax tweaks which make it much more C-like than
TADS 2. (I think Mike has been converging the syntax towards Java rather
than C, in fact, but that's largely the same thing.) It's still
dynamically typed, however.

> All three use dynamic rather than static typing.

[...]


> TADS
> Inconsistent use of curly braces.
> Non-C-like use of semicolons.
> Assignment operator is ':=', not '='.

You can use '=' if you switch into C syntax mode, enabled with '#pragma
C+'. This is kind of ugly, since you'll probably still be using
libraries that don't use C mode (such as adv.t). As someone who learned
C before TADS, however, I find it useful.

TADS 3 has an even more C-like syntax, and no icky #pragma. Yay!

> Local variables must be explicitly declared 'local'.

This is really due to the dynamic typing, rather than a flaw in its own
right. Since everything's dynamic, you don't have to declare the type of
anything. The use of 'local' gives you some compile-time checking, since
it statically determines the scope of identifiers; therefore, I assume
you'd prefer it to no variable declarations at all.

I find the handling of local variables in Inform to be very untidy in
comparison -- unless I misunderstand it, local variables and parameters
are the same thing. That's just nasty.

--
Iain Merrick
ia...@diden.net

Nikos Chantziaras

unread,
Jul 10, 2002, 4:18:35 PM7/10/02
to
"Iain Merrick" <ia...@diden.net> wrote in message
news:iain-137BC7.2...@socrates.zen.co.uk...

> You can use '=' if you switch into C syntax mode, enabled with '#pragma
> C+'. This is kind of ugly, since you'll probably still be using
> libraries that don't use C mode (such as adv.t). As someone who learned
> C before TADS, however, I find it useful.
'#pragma C+' is safe to use. The compiler remembers which file uses what
syntax.

-- Niko


Iain Merrick

unread,
Jul 10, 2002, 4:27:01 PM7/10/02
to
Nikos Chantziaras <rea...@hotmail.com> wrote:

> Iain Merrick <ia...@diden.net> wrote:
>
> > You can use '=' if you switch into C syntax mode, enabled with '#pragma
> > C+'. This is kind of ugly, since you'll probably still be using
> > libraries that don't use C mode (such as adv.t). As someone who learned
> > C before TADS, however, I find it useful.
>
> '#pragma C+' is safe to use. The compiler remembers which file uses what
> syntax.

I didn't say it was unsafe, I said it was ugly.

For instance, if someone posts a code snippet to the newsgroup in the
normal syntax mode, I have to convert it to C mode before pasting it
into my game's source code. (Not much extra effort, admittedly, since I
always reformat it in my preferred style anyway.) Also, when debugging,
I might have to step through both my own code and the library code, and
if they use different syntax modes it looks a little odd.

--
Iain Merrick
ia...@diden.net

Stephen Cameron

unread,
Jul 10, 2002, 5:16:02 PM7/10/02
to
On Wed, 10 Jul 2002 17:02:10 GMT, John <nojgoa...@hotmail.com> wrote:
>Ray
>
>Thankyou for taking the time to make this post. It was very helpful for me.
>I have been taking a similar approach using verbs as methods. That made the
>most sense to me. I got to the point of splitting sentences and ignoring
>"the,an,a" etc. Also implemented "it" much the same way.
>

(Hmm, this came out longer than I expected... )

Articles are not completely useless and you might not want
to throw them away. For example, you know that after
seeing "a", "an", or "the", you pretty much have to see
a noun (or noun phrase at least) before you will see a verb again.
(I'm sure counterexamples exist, but it's a useful tactic)

Consider:

> look
you see a hammer, a ring, and a bell
> Take hammer ring bell. (is "ring" a verb or noun here? no way to know.)

vs.

> Take the hammer the ring and the bell. (clearly "ring" is a noun)

Also, "and" and "then" can help disambiguate:

Take hammer, then ring bell. (*probably+ "ring" is a verb... )
vs.
take hammer, ring and bell. (ring is definitely a noun because of "and")

Or:

> take hammer ring bell with hammer

It is possible to tell that ring must be a verb here.

(though your parser might think you mean to use the
hammer as a tool to take the hammer, the ring and the bell
if you aren't careful.)

Ages ago, (1988 or so) I wrote a parser that could handle this kind
of junk (in Turbo Pascal. What a waste. At the time it seemed
a reasonable choice. And now, that computer is dead... oh well. :-)

It worked by having a template for various types of phrases
I had a crude way of representing the grammar
by a string, each character represented some, not
exactly a part of speech, but something like it.

something like:

L = list of objects = [noun] [separator] [ list of objects ]
P = preposition
O = single object

(included in [noun] was "all", "it", etc.)

Then I had a format for each distinct verb. (A distinct verb
might have evil twin verbs that are spelled the same and mean
nearly the same thing, but have diferent "formats".)

For example, the grammar for "put" looked something like:

put "PL" (for "put on the sweater")
put "LP" (for "put the glasses and the sweater on")
put "LPO" (for "put everything on the table")
put "LPOPO" (for "put the peanut butter on the bread with the knife")

Then, as I was parsing a sentence, I kept a list of each possible
way of interpreting the sentence. Whenever I came to a word that
could be interpreted in multiple ways, I interpreted it multiple
ways. So If I start off with the work "put", immediately I generate
4 possible interpretations (using above example) If the next word
is a preposition, I can then toss 3 interpretations.
Hopefully by the end, only one interpretation would match all the
words, and need no more words to reach a completed state. In that
case, the sentence was successfully
parsed. If multiple interpretations matched, the parsing was ambigous.
If none matched, the sentence was not understood. So in a way it
worked similarly to something like YACC, except it could look arbitrarily
far ahead in the input stream, delaying the interpretation decision as
long as possible, and there weren't really any "productions" until
the very end of parsing a (possibly compound) sentence.

The vocabulary/grammer stuff was somewhat intertwined with the
representations of objects in the game, as it must be to some
extent for words like "everything" and using the presense or
absense of objects to know what is being talked about, as well
as binding the "words" to the "objects/meanings"

Anyway, just some stuff I thought you might enjoy.
Not to say my way is right, or even particularly good.

On the other hand, bothering with the articles and this kind of parser
is a lot of work considering that typically people go around typing very
simple commands most of the time (e.g. "n", "x object"),
if they are playing a game as opposed to playing with the parser.

Ok, back to lurk mode.

-- steve

Eytan Zweig

unread,
Jul 10, 2002, 6:13:42 PM7/10/02
to

"Stephen Cameron" <scam...@zuul.cca.cpqcorp.net> wrote in message
news:slrnaip7v4....@zuul.cca.cpqcorp.net...

> On Wed, 10 Jul 2002 17:02:10 GMT, John <nojgoa...@hotmail.com> wrote:
> >Ray
> >
> >Thankyou for taking the time to make this post. It was very helpful for
me.
> >I have been taking a similar approach using verbs as methods. That made
the
> >most sense to me. I got to the point of splitting sentences and ignoring
> >"the,an,a" etc. Also implemented "it" much the same way.
> >
>
> (Hmm, this came out longer than I expected... )
>
> Articles are not completely useless and you might not want
> to throw them away. For example, you know that after
> seeing "a", "an", or "the", you pretty much have to see
> a noun (or noun phrase at least) before you will see a verb again.
> (I'm sure counterexamples exist, but it's a useful tactic)
>
> Consider:
>
> > look
> you see a hammer, a ring, and a bell
> > Take hammer ring bell. (is "ring" a verb or noun here? no way to
know.)
>
> vs.
>
> > Take the hammer the ring and the bell. (clearly "ring" is a noun)
>

[snip]

Not to mention that you want to show the following is ungrammatical:

"Take the a hammer"

Eytan


L. Ross Raszewski

unread,
Jul 10, 2002, 5:29:39 PM7/10/02
to
On Wed, 10 Jul 2002 23:08:36 +0300, Nikos Chantziaras
<rea...@hotmail.com> wrote:
>"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
>news:Xns924755A2D30A1ed...@199.45.49.11...
>> Okay, here's a laundry list of what I don't like about what seems to be
>> the "big three" (Inform, TADS and HUGO). I didn't look at any of the
>> systems which advertised themselves as being GUI- or forms-driven, or
>> sought to minimize "programming".
>>
>> All three lack support for floating point.
>> All three use dynamic rather than static typing.
>
>Add the following:
> No private/protected members.
> No private/protected inheritance.

Inform has private members.

L. Ross Raszewski

unread,
Jul 10, 2002, 5:32:03 PM7/10/02
to
On Wed, 10 Jul 2002 20:10:36 GMT, Iain Merrick <ia...@diden.net> wrote:
>
>I find the handling of local variables in Inform to be very untidy in
>comparison -- unless I misunderstand it, local variables and parameters
>are the same thing. That's just nasty.

Not really. They just have the same syntax. In most languages,
parameters are local variables as well (Perl is an interestign
coutnertexamplem but perl is hardly 'most languages'. I can't see
anythign 'nasty' about it.

Tzvetan Mikov

unread,
Jul 10, 2002, 5:34:06 PM7/10/02
to

"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924750FD06ABAed...@199.45.49.11...
> "Tzvetan Mikov" <ce...@jupiter.com> wrote:
> >> You would think that by now a C-library or C++-library would have
> >> materialized that allowed you to write IF, but I honestly can't
> >> think of one.

> > I asked a question along these lines some time ago (the thread was
> > called "[Dis]Advantages of IF languages") and eventually became
> > convinced that a C/C++/C#/Java IF library would be very inconvenient
> > to use, if not outright impossible.
>
> Could you go into more detail, please?

You'd be better off checking the thread in google and making your own
conclusions. There were lots of interresting contributions on the subject,
for example how Tads evolved from a C library, through a C library with
scripting capabilities, finally to a full-blown language (IIRC).

Anyway, I here I am copying part of my final thoughts from that thread:

<<<<
I finally carefully read the Inform DM4 (something that I should have
done long time ago) and what can I say ... I must apologize for
wasting everybody's time. It is now obvious to me that it is
impossible to achieve similar functionality in C++ without an enormous
amount of typing (I am not even talking about the library).

Initially I started playing around with macroses, trying to "port" the
Cloak of Darkness (which I could finally understand, having read the
DM4) to C++, as if there was a C++ library. The initial results were
reasonably encouraging - I got something like this to even compile
with a C++ compiler:

Object( foyer, "Foyer of the Opera House" )
with
prop( description )
retprn "You are standing in a spacious hall...";
prop( s_to ) return bar;
prop( w_to ) return cloakroom;
prop( n_to ) retprn "You've only just arrived, and besides...";
has
attr |= light;
EndObject( foyer );

Seemed good at first, but of course soon after that I came to a dead
end. I just couldn't implement polymorphic properties - there was no
way to check for their existence in an object and keep an intuitive
syntax for accessing them. I realized that it is insane to
try to artificially transplant another language's concepts into C++.

Finally, I must admit that I felt significantly more comfortable with
Inform than I thought I would. It feels pretty neat.
>>>>

In short, the problems are:
- Polymorphic properties. To define an abstract interface for every property
and use dynamic_cast to check for it is sheer madness, IMHO :-)
- Instantiation of objects. This can be achieved with macroses, but as you
can see from my example above, then you aren't really programming in C++
since it is hidden underneath a thick layer.

I still don't exclude the possibility of implementing an entirely new IF
design in C++. That would make sense more than simply duplicating in another
language already existing and proven designs.

regards,
Tzvetan


OKB (not okblacke)

unread,
Jul 10, 2002, 6:23:15 PM7/10/02
to
L. Ross Raszewski wrote:

Well, I think there's a bit more to it than "just the same syntax". Or perhaps they "have the same
syntax" in that a single syntactical declaration defines them both, in an intermingled way. The crucial
thing is that there's no distinction between a local variable that's going to be initialized with a function
argument (when the function is called) and one that isn't. This means that the code inside the function
doesn't necessarily know "where it stands" with regard to its local variables.

The nastiness or lack thereof is something else. I actually found Inform's approach kind of handy
when writing in Inform, but in using TADS 3 I've never wanted it, and in fact it would probably be a
distraction. This is probably due as much to the different library designs as to the language differences.

Alex Warren

unread,
Jul 10, 2002, 6:28:05 PM7/10/02
to
Raybert wrote on the subject of parsing (all snipped)

I'm not convinced that a complicated parser is necessary for IF, particularly
when most commmands that are input by the player are one of only a few "rigid"
forms, e.g. "LOOK AT x", "TAKE x" (and their abbreviations) etc.

I deliberately made the Quest parser very simple, although with the latest
version (3.1) I have made it a little more sophisticated. The basic principle is
the same though - since often an IF author will simply want to allow the player
to type something specific, say "SMASH x", the Quest parser allows you set this
up. If you want the "x" to be an object, you'd put:

command <smash #@thing#> ...

where "..." is some script to execute whenever the player types "SMASH x", where
"x" is a valid object. This valid object must be something accessible to the
player, i.e. in the current room or the inventory, and Quest will remove any
"the" prefixed to it and it will also automatically cater for the player typing
"it", in which case it will use the last object that was referred to. If the
command is accepted, the name of the object that the player referred to will be
in the string variable named "thing", and the script will then be executed. If
there is an ambiguity, Quest will ask the player for clarification before
executing the script. If an object of the required name is not available, Quest
displays a standard message (or one the author specified).

As for the #@thing# syntax: in earlier versions of Quest, the name of an object
that was displayed was the same as the name of the object in code, and a
variable which might contain this object name would also be referred to as
#thing#, #object#, #whatever#... but with aliases meaning several objects might
all be referred to be the player as the same thing, the #@whatever# syntax
provides a quick way to refer to the displayed name instead.

I think this is a sensible approach - an author can easily cater for the vast
majority of possible ways that a player might try to express something, without
having to worry too much about what the parser might make of it.

Any kind of NLP parser would be a pain to code in the first place, and then
quite probably a pain for any IF author who might have to try and guess what it
would make of any given sentence - and I think possibly that the parsers in many
IF systems are too complicated already for the kinds of things that players
usually type.


Alex Warren
http://www.axeuk.com/quest

Kevin Forchione

unread,
Jul 10, 2002, 9:49:10 PM7/10/02
to
"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
news:Xns924755A2D30A1ed...@199.45.49.11...

> Okay, here's a laundry list of what I don't like about what seems to be
> the "big three" (Inform, TADS and HUGO).

Rather than debate these items point by point. I'm rather interested why you
believe these are deficiencies in the creation of Interactive Fiction.

--Kevin


L. Ross Raszewski

unread,
Jul 10, 2002, 10:30:26 PM7/10/02
to
On 10 Jul 2002 16:23:15 -0600, OKB (not okblacke) <Bren...@aol.com> wrote:
>L. Ross Raszewski wrote:
>
>> On Wed, 10 Jul 2002 20:10:36 GMT, Iain Merrick
>> <ia...@diden.net> wrote:
>>>
>>>I find the handling of local variables in Inform to be very
>>>untidy in comparison -- unless I misunderstand it, local
>>>variables and parameters are the same thing. That's just
>>>nasty.
>>
>> Not really. They just have the same syntax. In most
>> languages, parameters are local variables as well (Perl is
>> an interestign coutnertexamplem but perl is hardly 'most
>> languages'. I can't see anythign 'nasty' about it.
>
> Well, I think there's a bit more to it than "just the same
syntax". Or perhaps they "have the same
>syntax" in that a single syntactical declaration defines them both,
in an intermingled way. The crucial
>thing is that there's no distinction between a local variable that's
going to be initialized with a function
>argument (when the function is called) and one that isn't. This
means that the code inside the function
>doesn't necessarily know "where it stands" with regard to its local variables.
>

I'm not sure I understand this. In C, the code

x = y+z;

doesn't "know where it stands" with regard to local variables. I don't
see a fundamental difference between

[ foo bar baz zork;

and

foo(bar, baz)
{
local zork;


I gather you mean something like "after this point, you don't know if
zork was initialized by havign something passed to it", but this is
irrelevant; if you intend for zork to be a local and not a parameter,
what does it matter to you if it has "random data" in it at the
beginning of a function -- in the inform syntax, it could be
initialized as a result of someone calling this two-parameter function
with three parameters, in the C-like language above, it could have
random data as a result of the fact that a variable has random data in
it when you allocate it off the stack. There's no conceptual
differencefrom the point of view inside the function.

Unless your concern is more along the lines of 'I can't mandate that
foo is called with exactly two parameters'. This is maybe fair, but
it's a concern reliant on an idea of static typing, which inform
hasn't (you can, indeed, make this mandate at run-time; there's an
opcode to count the number of parameters passed in). The conflation
does allow you to write functions which take a variable number of
arguments
(And before you shout 'overloading', it's debatable whether this kind
of overloading is a Good Thing; C works close to the way inform does
in this respect with varargs, and Java doesn't allow you to change the
signature of overloaded methods).

Fred the Wonder Worm

unread,
Jul 10, 2002, 11:15:59 PM7/10/02
to

In article <slrnaip7v4....@zuul.cca.cpqcorp.net>,

Stephen Cameron <steve....@hp.com> wrote:
> Articles are not completely useless and you might not want to throw
> them away. For example, you know that after seeing "a", "an", or
> "the", you pretty much have to see a noun (or noun phrase at least)
> before you will see a verb again.

Another thing to consider is that "a" or "an" should indicate a
willingness to choose any of the available matches. e.g.:

You are in a room. There is a red ball and a blue ball here.
> take the ball
Which ball do you mean, the red ball or the blue ball?

vs

You are in a room. There is a red ball and a blue ball here.
> take a ball
red ball: taken

Not a big point, but the implication seems valid to me.

Cheers,
Geoff.

-----------------------------------------------------------------------------
Geoff Bailey (Fred the Wonder Worm) | Programmer by trade --
ft...@maths.usyd.edu.au | Gameplayer by vocation.
-----------------------------------------------------------------------------

Tzvetan Mikov

unread,
Jul 10, 2002, 11:21:47 PM7/10/02
to

"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:656X8.29751$5f3....@nwrddc01.gnilink.net...

>
> I'm not sure I understand this. In C, the code
>
> x = y+z;
>
> doesn't "know where it stands" with regard to local variables. I don't
> see a fundamental difference between
>
> [ foo bar baz zork;
>
> and
>
> foo(bar, baz)
> {
> local zork;

Don't you agree that there is a difference in the ease of understanding and
maintaining the code ?

-tzvetan


Joao Mendes

unread,
Jul 10, 2002, 11:43:26 PM7/10/02
to

Hi, :)

"John" <nojgoa...@hotmail.com> wrote in
news:mMZW8.12109$A43.1...@newsread2.prod.itd.earthlink.net:

> ignoring "the,an,a" etc.

To those of you writing parsers: please don't harcode this. Please have the
decency of having 'article' objects in the library and having your parser
ignore words that match them. Otherwise:

1) The article list won't be extendable

2) Your engine won't be localizable

3) (more obscure) You might run into problems if people stick articles in
their object vocabularies

> You know, this would be awesome to capture somewhere (it its not
> already), as a series of test cases for adventures. Maybe have
> different levels of functionality. Could set up a simple specific
> location, maybe from one of the classic games with a couple of rooms
> for navigation. It could be like a hello world of IF? Just a
> thought.

I would presume that the current IF 'hello world' is Cloak of Darkness...

Cheers,

J.

Dan Schmidt

unread,
Jul 10, 2002, 11:38:00 PM7/10/02
to
ad...@fsf.net (Adam Thornton) writes:

| It seems to me that what you need is not a new IF development
| language, but a preprocessor wrapped around one of the existing ones
| that sugars the syntax for you. m4 could probably be applied
| usefully here.

I used a combination of m4 and Inform for one project before I rewrote
it all in a different language, and it worked pretty well. I wasn't
doing any exciting syntactical things with it, though.

Dan

--
http://www.dfan.org

L. Ross Raszewski

unread,
Jul 11, 2002, 12:10:15 AM7/11/02
to

Actually I don't. When I read code, I understand the meaning of
variables from how they're used, not where they're declared. If
inform were statically typed, I might see this differently.

Tzvetan Mikov

unread,
Jul 11, 2002, 12:41:22 AM7/11/02
to

"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:Hy7X8.18$7W...@nwrddc02.gnilink.net...

If you saw the code:
baz = 1;
how would you know whether it wasn't a bug (overwriting the value of a
parameter) ?

Going back to your first example "x = y+z", the code in fact knows where it
stands to a certain extent - "x" is most likely not a parameter.

-tzvetan


Raybert

unread,
Jul 11, 2002, 1:24:55 AM7/11/02
to
Hi Steve,

Thanks for sharing your ideas.

scam...@zuul.cca.cpqcorp.net (Stephen Cameron) wrote in message news:
<snip>


> Articles are not completely useless and you might not want
> to throw them away. For example, you know that after
> seeing "a", "an", or "the", you pretty much have to see
> a noun (or noun phrase at least) before you will see a verb again.
> (I'm sure counterexamples exist, but it's a useful tactic)

This is a good point. But, considering that articles are optional and
that most players (with any experience) don't bother to type them, I
have to wonder if it's worth doing anything with them. When they're
there, they can provide good hints about the content. But you'll have
to have an alternate means of identifying the content anyway when
they're not present.


<snip>


> It worked by having a template for various types of phrases
> I had a crude way of representing the grammar
> by a string, each character represented some, not
> exactly a part of speech, but something like it.

I was reading a bit about the Inform langauge today and discovered
that it models sentence structures in a similar way.

Coincidentally, I did something similar some years ago for a scripting
language that I developed for a commercial communications package
(which was never released). But I've never considered doing this for
adventure games.

In the scripting language, I produced a "prototype" for each possible
command/argument combination and I validated the script contents based
on this. Inform does exactly the same thing.

I'm not done thinking about it yet but my feeling right now is that it
seems like overkill. Yes, this prototyping allows Inform to handle a
couple additional (probably a bit obscure) sentence structures that my
parser can't handle, but my parser can handle all of the common
structures and it doesn't require all of this extra sentence modeling
work. So, maybe that's good enough? I need to think about it some
more.

[ray]

Raybert

unread,
Jul 11, 2002, 1:32:42 AM7/11/02
to
Alex Warren <happy...@hotmail.com> wrote in message news:<kccpiu43sce7q0h4v...@4ax.com>...

> Raybert wrote on the subject of parsing (all snipped)
>
> I'm not convinced that a complicated parser is necessary for IF, particularly
> when most commmands that are input by the player are one of only a few "rigid"
> forms, e.g. "LOOK AT x", "TAKE x" (and their abbreviations) etc.

I tend to agree with you. I think a "reasonably intelligent" parser
is good enough for most cases. Even the parser that I described in my
earlier post is more complex than I had planned (I got a little
carried away... ;) Yet, it's really still a fairly simple
implementation that achieves some reasonably powerful stuff; so I'm
happy with it.

I could get much fancier -- like modeling every possible sentence
structure for every verb -- but I'm just not convinced it's necessary.

[ray]

Raybert

unread,
Jul 11, 2002, 1:52:17 AM7/11/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote in message news:<Xns92475624139EFed...@199.45.49.11>...
> senorv...@yahoo.com (Raybert) wrote:
> > So, anyway, FWIW... maybe this means we should talk about
> > collaboration? maybe it's just a curiosity? I dunno... ;)
>
> I'm certainly open to the idea. I'm a lousy correspondent at the best of
> times, and I'm in the middle of moving, so if you don't hear from me, feel
> free to check in. Remove the spamguard from my e-mail address.

Okay, cool. I've been reconsidering my design since my first post two
days ago and I'm now planning to more-or-less re-write from scratch
with some new ideas that I have for the object model (my parser
probably won't change much) and this time I plan to write from the
perspective of developing a reusable Java class library. I think I've
got some good ideas on how to make it work. I think I've figured out
how to eliminate all of the static IDs that I described earlier as
well as a code structure that will make implementing new verbs,
objects, etc., relatively painless for an author (e.g. everything for
each individual object is in one file/class rather than being
distriuted among many files).

That said though, it's important to note that anyone who would try to
use this would still be writing Java code and that environment is
probably not as friendly to the IF author as a specially designed
language is. Therefore, even if it turns to work wonderfully, there's
a good chance no one will want to use it! :)

Nevertheless, it will still achieve my main goal of helping me to
master Java and have some fun exercising my IF jones. ;)

I've still got some things to work out but I'll let you know when I
have something ready to show.

[ray]

L. Ross Raszewski

unread,
Jul 11, 2002, 2:05:27 AM7/11/02
to
On Thu, 11 Jul 2002 04:41:22 GMT, Tzvetan Mikov <ce...@jupiter.com> wrote:
>
>If you saw the code:
> baz = 1;
>how would you know whether it wasn't a bug (overwriting the value of a
>parameter) ?
>

It's never a bug. If I overrite the value of a parameter, I did it
with some reason. Syntax should't exist to enforce readability (do
*not* accuse me of saying that syntax should't *support*
readability. THat's a different issue); if you need the syntax to make
your code readable for you, you're programming wrong.

Sean T Barrett

unread,
Jul 11, 2002, 4:33:26 AM7/11/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote:
>All three use dynamic rather than static typing.

The thing is, dynamic "typing" a la Smalltalk--polymorphism
by "overloaded" message passing--is an incredibly good fit
for dealing with all the different types of simulated objects
in the world.

Interleaving that style of polymorphism with static typing
is difficult; Objective C does it, but message selectors have
global type signatures--if library X defines (I'll use C++
notation for clarity) a method that implements
obj->doSomething(int)
and library Y defines
obj->doSomething(string)
you can't link the two libraries together, since the message
types conflict.

There may be a better solution--possibly by doing something
more ML like and inferring the types being <integer> and
<string> in those cases, but I think you're basically stuck;
those messages become global. This might actually be ok in
IF, if all the objects are really used as simulation objects,
but it gets annoying when you also have topic objects and
menu objects and conversation response objects.

Moreover, even after this, you're now stuck with either cobbling
in a second, *different*, object-oriented system if you want
OO-ish behaviors from your base types like string and int, or
you're stuck treating them as primitives, that is, writing C code.

Actually, though, there's another issue. Most of these languages
allow the idea that you might say obj->foo and it returns a string,
but maybe it was a string or maybe it was actually a routine which
returned a string. This is awfully convenient in IF with all of
its singleton objects, and doesn't map onto any mainstream
languages, as far as I know, although I don't think there's any
reason it couldn't. (Self, a Smalltalk-inspired language, is the
only one I know of offhand besides pretty much every IF language.)

SeanB

Sean T Barrett

unread,
Jul 11, 2002, 4:43:06 AM7/11/02
to
Tzvetan Mikov <ce...@jupiter.com> wrote:
>"Ed" <e...@mewsic.SPAMGUARD.com> wrote in message
>> "Tzvetan Mikov" <ce...@jupiter.com> wrote:
>> >[attribution lost]

>> >> You would think that by now a C-library or C++-library would have
>> >> materialized that allowed you to write IF, but I honestly can't
>> >> think of one.
>> > I asked a question along these lines some time ago (the thread was
>> > called "[Dis]Advantages of IF languages") and eventually became
>> > convinced that a C/C++/C#/Java IF library would be very inconvenient
>> > to use, if not outright impossible.
>>
>> Could you go into more detail, please?
>
>for example how Tads evolved from a C library, through a C library with
>scripting capabilities, finally to a full-blown language (IIRC).

There's

http://groups.google.com/groups?selm=GsB7wq.7E%40world.std.com

which both the authors of Tads and Hugo followed up saying
it roughly described the evolution of their systems.

The two issues of dealing with polymorphism and initializaing lots
of exceptional objects seem to me to be crucial. As I like to
put it: traditional languages are designed around manipulation
of entities that are all "the same" in some sense. Authorship of
IF is apparently essentially unique in the demands it puts for
creating and manipulating lots of entities that are entirely
different, which thus leads to what I said in the first sentence
of this paragraph. This uniqueness sees to be a consequence of
the nature of the real world and the level at which we are
"simulating" it; see also Andrew Plotkin's IF definition for
some hints that this is part of what makes IF interesting.

SeanB

Richard Bos

unread,
Jul 11, 2002, 4:49:38 AM7/11/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote:

> Neil Cerutti <cer...@trans-video.net> replied:
> > Your first reason is unconvincing (Inform and TADS are both
> > object-oriented and C-like),

> Inform
> Routine definition, using square brackets, is definitely not C-like.
> Integers appear to be limited to 16 bits.
> The 'for' statement is not C-like.

Oh, bah. Inform is mainly imperative and often uses interpunction rather
than extra keywords. This is C-like, with a bit of semi-object-
orientation mixed in. Things like using colons instead of semi-colons
are piddling details that shouldn't bother any hacker worth his salt.
The only thing which is fundamentally rather than cosmetically un-C-like
in Inform is the dynamic-ish typing.

If you want a truly un-C-like IF system, fire up the old Speccy and try
the Quill.

Richard

Richard Bos

unread,
Jul 11, 2002, 4:49:39 AM7/11/02
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:

> On Wed, 10 Jul 2002 12:24:57 GMT, Ed <e...@mewsic.SPAMGUARD.com> wrote:
>
> >Inform
> > Routine definition, using square brackets, is definitely not C-like.
> > Integers appear to be limited to 16 bits.
>

> True depending on the platform to which it is compiled. SImilarly, in
> C, an integer is limited to 16 bits if your target platform is, say, DOS.

Not entirely true; see, for example, DJGPP.

Richard

Tzvetan Mikov

unread,
Jul 11, 2002, 7:49:30 AM7/11/02
to

"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:He9X8.241$7W6...@nwrddc02.gnilink.net...

Often the issue is making your code readable for *other people*, not for
yourself ... :-)

Anyway, instead of delving into theoretical discussions, can you give an
example of when you think that modifying the value of a formal parameter
improves readability and style ?

Since there is no semantic difference between modifying the value of a
parameter in place and copying it to another location, the only possible
reasons that one might prefer one or the other are:
- if it saves some typing,
- if he believes that it improves readability,
- if he doesn't care.

-tzvetan


Stephen Cameron

unread,
Jul 11, 2002, 10:03:28 AM7/11/02
to
On 10 Jul 2002 22:24:55 -0700, Raybert <senorv...@yahoo.com> wrote:
>Hi Steve,
>
>Thanks for sharing your ideas.
>
>scam...@zuul.cca.cpqcorp.net (Stephen Cameron) wrote in message news:
><snip>
>> Articles are not completely useless and you might not want
>> to throw them away. For example, you know that after
>> seeing "a", "an", or "the", you pretty much have to see
>> a noun (or noun phrase at least) before you will see a verb again.
>> (I'm sure counterexamples exist, but it's a useful tactic)
>
>This is a good point. But, considering that articles are optional and
>that most players (with any experience) don't bother to type them, I
>have to wonder if it's worth doing anything with them.

Perhaps if you're like me, and I suspect, lots of people on this list,
and find *programming* games far more entertaining than actually
*playing* them. Making the best parser that you are able to (whatever
"best" means to you) can be it's own reward.

Somebody here recently said writing adventure games was the programming
equivalent of making a ship in a bottle. That really hits the nail
squarely on the head, for me. (Probably this has something to do with
why I never finish my games, I work on them only until they stop being
fun to work on. :-)

-- steve

Dan Schmidt

unread,
Jul 11, 2002, 9:53:09 AM7/11/02
to
buz...@TheWorld.com (Sean T Barrett) writes:

| Actually, though, there's another issue. Most of these languages
| allow the idea that you might say obj->foo and it returns a string,
| but maybe it was a string or maybe it was actually a routine which
| returned a string. This is awfully convenient in IF with all of its
| singleton objects, and doesn't map onto any mainstream languages, as
| far as I know, although I don't think there's any reason it
| couldn't.

Eiffel and Ruby both do this - I don't know how mainstream you'd consider
them. (Bertrand Meyer calls this the Uniform Access Principle and, being
Bertrand Meyer, asserts that all true object-oriented languages must
support it. See <http://www.elj.com/elj/v1/n1/bm/urp/>, for example.)

I like the idea, but the main practical problem I have with it is that
it becomes difficult to refer to functions as first-class objects,
since just naming them will call them by default.

Dan

--
http://www.dfan.org

Will Grzanich

unread,
Jul 11, 2002, 10:35:27 AM7/11/02
to
<delurk>

senorv...@yahoo.com (Raybert) wrote in message news:<c023b4af.02071...@posting.google.com>...



> This is a good point. But, considering that articles are optional and
> that most players (with any experience) don't bother to type them, I
> have to wonder if it's worth doing anything with them. When they're
> there, they can provide good hints about the content. But you'll have
> to have an alternate means of identifying the content anyway when
> they're not present.

Except that occasionally, the articles are *very* important:

You see your cloak and Bob's cloak here.

> TAKE MY CLOAK
Which cloak do you mean, your cloak or Bob's cloak?

I think Inform does a pretty good job of dealing with this, with the
article and articles properties and the ability to simply put the
appropriate articles (in the above case, "my") in the name property of
the object.

-Will

</delurk>

Kevin Forchione

unread,
Jul 11, 2002, 10:40:55 AM7/11/02
to
"Fred the Wonder Worm" <ft...@maths.usyd.edu.au> wrote in message
news:agit9f$31f$1...@spacebar.ucc.usyd.edu.au...

>
> In article <slrnaip7v4....@zuul.cca.cpqcorp.net>,
> Stephen Cameron <steve....@hp.com> wrote:
> > Articles are not completely useless and you might not want to throw
> > them away. For example, you know that after seeing "a", "an", or
> > "the", you pretty much have to see a noun (or noun phrase at least)
> > before you will see a verb again.
>
> Another thing to consider is that "a" or "an" should indicate a
> willingness to choose any of the available matches. e.g.:
>
> You are in a room. There is a red ball and a blue ball here.
> > take the ball
> Which ball do you mean, the red ball or the blue ball?
>
> vs
>
> You are in a room. There is a red ball and a blue ball here.
> > take a ball
> red ball: taken
>
> Not a big point, but the implication seems valid to me.

That's the distinction TADS 2 makes. If these guys work at it hard enough,
they're going to invent the TADS 2 parser...

--Kevin


Kevin Forchione

unread,
Jul 11, 2002, 10:42:34 AM7/11/02
to
"Joao Mendes" <public...@anywhere.invalid> wrote in message
news:Xns92482F778102Ej...@194.65.14.150...

> > You know, this would be awesome to capture somewhere (it its not
> > already), as a series of test cases for adventures. Maybe have
> > different levels of functionality. Could set up a simple specific
> > location, maybe from one of the classic games with a couple of rooms
> > for navigation. It could be like a hello world of IF? Just a
> > thought.
>
> I would presume that the current IF 'hello world' is Cloak of Darkness...

That's the consensus of the community, and why Roger Firth developed it.

--Kevin


OKB (not okblacke)

unread,
Jul 11, 2002, 12:22:41 PM7/11/02
to
Will Grzanich wrote:

> Except that occasionally, the articles are *very* important:
>
> You see your cloak and Bob's cloak here.
>
> > TAKE MY CLOAK
> Which cloak do you mean, your cloak or Bob's cloak?

"my" isn't an article, it's an adjective -- but I agree with what you say, because this example
illustrates that articles are, in a sense, one end of a spectrum of qualifying words. As has been
mentioned, TAKE THE CLOAK and TAKE A CLOAK really mean different things if there's more than
one cloak available; the first implies that a specific cloak is desired, and so the parser should ask ("Which
do you mean, the cloak of darkness or the cloak of light?"), while the second indicates that any cloak is
fine. This is clearly a less "powerful" qualification than an explicit adjective, but I think any good parser
will make use of it.

Eytan Zweig

unread,
Jul 11, 2002, 1:31:32 PM7/11/02
to

"OKB (not okblacke)" <Bren...@aol.com> wrote in message
news:Xns92485D...@12.252.202.62...

> Will Grzanich wrote:
>
> > Except that occasionally, the articles are *very* important:
> >
> > You see your cloak and Bob's cloak here.
> >
> > > TAKE MY CLOAK
> > Which cloak do you mean, your cloak or Bob's cloak?
>
> "my" isn't an article, it's an adjective

Um, what? In what sort of grammar of English? (not a sarcastic question - if
a grammar of English that analyzes "my" to be an adjective exists, I'd be
very interested to know by what criteria).

Eytan


Georgina Bensley

unread,
Jul 11, 2002, 1:05:09 PM7/11/02
to

> > > > TAKE MY CLOAK
> > > Which cloak do you mean, your cloak or Bob's cloak?
> >
> > "my" isn't an article, it's an adjective
>
> Um, what? In what sort of grammar of English? (not a sarcastic question - if
> a grammar of English that analyzes "my" to be an adjective exists, I'd be
> very interested to know by what criteria).

Huh?

www.m-w.com

Main Entry: my
Pronunciation: 'mI, m&
Function: adjective
Etymology: Middle English, from Old English mIn, from mIn, suppletive
genitive of ic I; akin to Old English mE me
Date: 12th century
1 : of or relating to me or myself especially as possessor, agent, or
object of an action <my car> <my promise> <my injuries>


What else would it be?

> Eytan

OKB (not okblacke)

unread,
Jul 11, 2002, 1:17:53 PM7/11/02
to
Eytan Zweig wrote:

>> "my" isn't an article, it's an adjective
>
> Um, what? In what sort of grammar of English? (not a
> sarcastic question - if a grammar of English that analyzes
> "my" to be an adjective exists, I'd be very interested to
> know by what criteria).

Look it up in a dictionary. (I looked in up in the three dictionaries I have and they all list it as an
adjective.) To be more specific, it's a pronominal adjective. The only words that are articles are "a",
"an", and "the". My "Macmillan Handbook of English" says on the subject of articles: "The words A and
AN are the indefinite articles; the word THE is the definite article." (Admittedly, this handbook is from
1947, but a part-of-speech shift from adjective to article isn't the kind of language evolution that tends to
occur within 50 years.)

L. Ross Raszewski

unread,
Jul 11, 2002, 1:36:21 PM7/11/02
to

Sigh. You really can't say anything here without being mind-hurtingly
explicit, can you? I know that DJGPP is 32-bit (in fact, DJGPP is the
only compiler I ever use on my windows machine). But it's hardly
"normal" DOS programming.

Eytan Zweig

unread,
Jul 11, 2002, 3:09:46 PM7/11/02
to

"OKB (not okblacke)" <Bren...@aol.com> wrote in message
news:Xns924867...@12.252.202.62...

> Eytan Zweig wrote:
>
> >> "my" isn't an article, it's an adjective
> >
> > Um, what? In what sort of grammar of English? (not a
> > sarcastic question - if a grammar of English that analyzes
> > "my" to be an adjective exists, I'd be very interested to
> > know by what criteria).
>
> Look it up in a dictionary. (I looked in up in the three dictionaries
I have and they all list it as an
> adjective.) To be more specific, it's a pronominal adjective. The only
words that are articles are "a",
> "an", and "the". My "Macmillan Handbook of English" says on the subject
of articles: "The words A and
> AN are the indefinite articles; the word THE is the definite article."
(Admittedly, this handbook is from
> 1947, but a part-of-speech shift from adjective to article isn't the kind
of language evolution that tends to
> occur within 50 years.)
>

Sorry - the problem with being a linguistics major from a non-English
country is that I tend to forget that linguistics terminology has very
different meanings in very different contexts. Though even in the simplest
grammar of English I'd argue that "my" isn't an adjective in the same sense
that "blue" is - note that you can say "my house is blue" but not "blue
house is my"; you can say "the blue house is big" but not "the my house is
big"

Eytan

Raybert

unread,
Jul 11, 2002, 3:12:56 PM7/11/02
to
ft...@maths.usyd.edu.au (Fred the Wonder Worm) wrote in message news:<agit9f$31f$1...@spacebar.ucc.usyd.edu.au>...

> Another thing to consider is that "a" or "an" should indicate a
> willingness to choose any of the available matches. e.g.:
>
> You are in a room. There is a red ball and a blue ball here.
> > take the ball
> Which ball do you mean, the red ball or the blue ball?
>
> vs
>
> You are in a room. There is a red ball and a blue ball here.
> > take a ball
> red ball: taken
>
> Not a big point, but the implication seems valid to me.

Hmm... I would have to disagree with this. I see the implication that
you're inferring here but I think it's important to be specific. The
game shouldn't make an arbitrary decision like that, even if the game
programmer thinks it's the logical choice. There's no guarantee that
the user who typed that command was really thinking of the same
meaning.

Suppose there was something detrimental about taking the wrong ball:
wouldn't you want to be absolutely certain which ball the user meant?

What you really want here is a special modifier word, "ANY", as in:
"take any ball". But I just can't see the usefulness of that. I
would certainly never use it as a player.

[ray]

Mike Roberts

unread,
Jul 11, 2002, 3:28:52 PM7/11/02
to
"Eytan Zweig" <eyt...@oook.cz> wrote:
> Sorry - the problem with being a linguistics major from
> a non-English country is that I tend to forget that linguistics
> terminology has very different meanings in very different
> contexts. Though even in the simplest grammar of English
> I'd argue that "my" isn't an adjective in the same sense that
> "blue" is - note that you can say "my house is blue" but not
> "blue house is my"; you can say "the blue house is big" but
> not "the my house is big"

Linguists in English-speaking countries make the same kinds of distinctions.
Dictionary writers tend to want to assign every word to one of the eight or
so canonical slots, which are both too coarse and insufficiently exhaustive
to cover all of the special function words in a natural language; as a
result, lots of function words get classified in surprising ways in
dictionaries. Dictionaries classify "my" as an adjective because it's the
best fit of the canonical slots (as you say, one could argue from an
analysis of English syntax that "my" acts more like an article than it does
like an adjective, but I think dictionary writers tend to think of "article"
as "the words a, an, and the," so "my" is excluded by enumeration). Modern
linguists would probably call "my" a determiner, a class of words that also
includes articles, quantifiers, and demonstratives. Determiners aren't
adjectives, but a whole separate category outside of the canonical
dictionary classifications.

--Mike
mjr underscore at hotmail dot com

John Colagioia

unread,
Jul 11, 2002, 5:08:07 PM7/11/02
to
I just want to chime in, briefly, here.

Ed wrote:
[...]


> Inform
> Routine definition, using square brackets, is definitely not C-like.
> Integers appear to be limited to 16 bits.

> The 'for' statement is not C-like.

I find all of this a benefit, rather than a drawback, and not (just)
because I think C is ugly. The semantics of lots of Inform are
subtly different than those in C. The difference in syntax keeps the
important parts of the language straight in my mind.

[...]

Will Grzanich

unread,
Jul 11, 2002, 5:41:40 PM7/11/02
to
"OKB (not okblacke)" <Bren...@aol.com> wrote in message news:<Xns92485D...@12.252.202.62>...

> Will Grzanich wrote:
>
> > Except that occasionally, the articles are *very* important:
> >
> > You see your cloak and Bob's cloak here.
> >
> > > TAKE MY CLOAK
> > Which cloak do you mean, your cloak or Bob's cloak?
>
> "my" isn't an article, it's an adjective

[snip]

You're right, of course. I'll chalk this one up to a combination of
what Mike Roberts says on the subject and the fact that, in Inform,
the "article" property is where you would tell the game to print out
"your" in front of the word "cloak."

IOW, even if "my" isn't an article, I think it's still important to
have something like Inform's "article" property, and to have the
parser not strip out such words as "my," so that this sort of
situation is handled properly.

-Will

Sean T Barrett

unread,
Jul 11, 2002, 10:39:53 PM7/11/02
to
In article <uu1n69...@dfan.thecia.net>, Dan Schmidt <df...@dfan.org> wrote:
>Eiffel and Ruby both do this - I don't know how mainstream you'd consider
>them. (Bertrand Meyer calls this the Uniform Access Principle and, being
>Bertrand Meyer, asserts that all true object-oriented languages must
>support it. See <http://www.elj.com/elj/v1/n1/bm/urp/>, for example.)
>
>I like the idea, but the main practical problem I have with it is that
>it becomes difficult to refer to functions as first-class objects,
>since just naming them will call them by default.

Well, if the latter is true, I think it's a misapplication of the
principle--although every implementation I know of probably works
that way. (For my mud, I had foo.bar return the function instead
of running; foo.bar() would run the function or return the
non-function item. I don't think this was really the right
approach, but at least both things were possible.)

Meyer's page uses such an abstract notation that it's impossible
to see what he thinks should happen for a scenario like obj.foo(1,2).
That's a case that Tads3 doesn't allow; I don't remember what
Inform does.

Anyway, I think it's a misapplication because it shouldn't be
a problem to have first class functions still. If object o offers
feature f, and feature f's type signature is that it *returns*
a first class function that produces a string, then if o.f is a
function that produces a string, return it; if it's a function
that returns a function that produces a string, execute it.

Or, from the other side of the coin, the compiler/language just
needs to offer two different ways of associating functions
with o.f; one means 'run this' and one means 'return this'.

SeanB

Richard Bos

unread,
Jul 12, 2002, 4:44:07 AM7/12/02
to
"OKB (not okblacke)" <Bren...@aol.com> wrote:

> Eytan Zweig wrote:
>
> >> "my" isn't an article, it's an adjective
> >
> > Um, what? In what sort of grammar of English? (not a
> > sarcastic question - if a grammar of English that analyzes
> > "my" to be an adjective exists, I'd be very interested to
> > know by what criteria).

[ Oh, btw, OKB, can you set your line wrapping limit to something
sensible, like 72 characters or so? The way you have it now they come
out as almost illegibly long. ]

> Look it up in a dictionary. (I looked in up in the three dictionaries I have and they all list it as an
> adjective.) To be more specific, it's a pronominal adjective.

That's odd - in Dutch, and in Latin as well[1], "my" is a pronoun. To be
precise, it's a possessive pronoun. I'd assumed it was so in English as
well.

Richard

[1] Comparisons to Latin grammar are odious, I know.

John Colagioia

unread,
Jul 12, 2002, 8:00:40 AM7/12/02
to
Tzvetan Mikov wrote:
[...]

> Anyway, instead of delving into theoretical discussions, can you give an
> example of when you think that modifying the value of a formal parameter
> improves readability and style ?

I won't speak for the original poster, but I think you're trying to
apply C-like semantics to a non-C language, which is what's causing
the problem.

In Inform, it sort of equates to not having parameters; instead, a
routine has local variables, some of which can be initialized by the
calling routine.

In terms of readability, this means that "function calls" only carry
the "parameters" they need, so that you don't have to read through
ugly code like "ret = SomeFunc (obj, routine, 0, 0, nothing, 0,
nothing, 0, 0, 0);" which carries no more useful information than the
two-parameter equivalent, and is harder to grasp because of the extra
(unused) parameters.

> Since there is no semantic difference between modifying the value of a
> parameter in place and copying it to another location, the only possible
> reasons that one might prefer one or the other are:
> - if it saves some typing,
> - if he believes that it improves readability,
> - if he doesn't care.

There's also the rather useful point that this allows parameters to
have convenient default values (also increasing readability over, to
use your example, copying all the parameters to similarly-named
locals).

John W. Kennedy

unread,
Jul 12, 2002, 12:39:00 AM7/12/02
to

>>Will Grzanich wrote:

Because English adjectives are not declined, there is no way to say
whether "my" is a possessive adjective or the genitive of "I". But
in most Indo-European languages, possessive adjectives are used far
more than the genitives of the personal pronoun, so many grammarians
classify "my" as such. Others prefer to call it the genitive of "I"
on the theory that "I" _must_ have a genitive. Either way, it's not an
article. "A"/"an" and "the" are the only articles.

--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html

John W. Kennedy

unread,
Jul 12, 2002, 12:44:43 AM7/12/02
to
Eytan Zweig wrote:
> Sorry - the problem with being a linguistics major from a non-English
> country is that I tend to forget that linguistics terminology has very
> different meanings in very different contexts. Though even in the simplest
> grammar of English I'd argue that "my" isn't an adjective in the same sense
> that "blue" is - note that you can say "my house is blue" but not "blue
> house is my"; you can say "the blue house is big" but not "the my house is
> big"

But in Italian you say, "La mia casa", and, on the other hand, in
German, you say, "Mein Haus".

OKB (not okblacke)

unread,
Jul 12, 2002, 11:17:34 AM7/12/02
to
Richard Bos wrote:

> [ Oh, btw, OKB, can you set your line wrapping limit to
> something
> sensible, like 72 characters or so? The way you have it now
> they come out as almost illegibly long. ]
>

Ah. . . Yes. Someone pointed this out to me a few weeks ago and
I've been piddling around with Xnews trying to find a way to get
word-wrap with a variable-width font. I guess I'll just bite the
bullet and use fixed-width, though, which should make everything wrap
properly. (This post appears to be wrapping correctly as I type it.)
I apologize if this has been an annoyance.

John W. Kennedy

unread,
Jul 12, 2002, 12:24:01 PM7/12/02
to

There is an old tradition of calling these words "pronouns", but the
first thing any Latin or Old English grammar seems to do is explain that
they aren't pronouns, really, but adjectives. They are used in various
Indo-European languages as either demonstrative adjectives or as plain
adjectives. English "my" is never used as a pronoun, and "mine" only
by way of ellipsis. (The distinction between MnE "my" and "mine" does
not have any parallel in other languages that I know of.)

While it is true that "mei" is the genitive of the pronoun "ego", it is
rarely used in Latin; in fact, when it is used, the usual English
translation will use "of me" instead of "my". "Odium mei" -- "hatred of
me".

The normal Latin equivalent of "my" is "meus", a fully declined
adjective:
Singular Plural
Masculine Feminine Neuter Masculine Feminine Neuter
Nominative meus mea meum mei meae mea
Genitive mei meae mei meorum mearum meorum
Dative meo meae meo meis meis meis
Accusative meum meam meum meos meas mea
Ablative meo mea meo meis meis meis
Vocative mi mi mi mei meae mea

Now, I cannot speak to Dutch, but Hochdeutsch is pretty much the same as
Latin, and so was Old English.

Kevin Forchione

unread,
Jul 12, 2002, 8:18:50 PM7/12/02
to
"Tzvetan Mikov" <ce...@jupiter.com> wrote in message
news:agitkb$q...@dispatch.concentric.net...

>
> "L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
> news:656X8.29751$5f3....@nwrddc01.gnilink.net...
> >
> > I'm not sure I understand this. In C, the code
> >
> > x = y+z;
> >
> > doesn't "know where it stands" with regard to local variables. I don't
> > see a fundamental difference between
> >
> > [ foo bar baz zork;
> >
> > and
> >
> > foo(bar, baz)
> > {
> > local zork;
>
> Don't you agree that there is a difference in the ease of understanding
and
> maintaining the code ?

Hmmm. Only if the arguments are by reference, and not by copy. If they're by
copy then the scope of bar, baz, and zork are limited to the method, and
there's no real difference between them.

--Kevin


LizM7

unread,
Jul 12, 2002, 9:05:40 PM7/12/02
to
Ed <e...@mewsic.SPAMGUARD.com> wrote:
> Okay, here's a laundry list of what I don't like about what seems to be
> the "big three" (Inform, TADS and HUGO). I didn't look at any of the
> systems which advertised themselves as being GUI- or forms-driven, or
> sought to minimize "programming".
>
> All three lack support for floating point.
> All three use dynamic rather than static typing.

[snip list]

*frowns, thinks of how to put this properly*

Speaking as a long-time player of IF (though I'm admittedly rather
lacking when it comes to programming skills), it seems to me you've
been focusing a bit too much on one question -- "Does any language out
there fit my needs *as a programmer*?" -- while ignoring the
potentially more important one, which is "Can the language I create
fit anyone's needs *as a player*?"

What I'm concerned about here is that you're thinking of creating a
programming language not because of concerns about the limits of
*gameplay* within any IF language (i.e. because you were running up
against a brick wall attempting to code such-and-such a situation),
but because of concerns about the limits of *programming* within said
language (i.e. because you want a language to have features X, Y, and
Z, and this language only has X and Y, and this one has Y and Z, and
so on.). IOW, you're likely to fall into the same trap that (say)
ADRIFT is caught in -- which is, when you create a language sheerly to
make your life as a programmer a bit nicer, you start ignoring the
features that make my life as a player a bit nicer.

And, when it comes down to it, *your life as a programmer is
irrelevant to the playability of your game*. I don't care how much
hell you had to go through to create a game; when I sit down to play
it, I'm concerned about whether or not it has the features I expect to
find in an IF game -- and the commands I want. It's easy to say you
can duplicate them in your own parser, but that's something few have
succeeded at.

IOW, to me at least, the three or four months you have to take
adjusting to programming in TADS/Inform/Hugo are more than made up for
by the five minutes worth of irritation that I'm spared when I sit
down to play your game.

- Liz

Tzvetan Mikov

unread,
Jul 12, 2002, 10:35:11 PM7/12/02
to

"John Colagioia" <JCola...@csi.com> wrote in message
news:3D2EC4E...@csi.com...

>
> In terms of readability, this means that "function calls" only carry
> the "parameters" they need, so that you don't have to read through
> ugly code like "ret = SomeFunc (obj, routine, 0, 0, nothing, 0,
> nothing, 0, 0, 0);" which carries no more useful information than the
> two-parameter equivalent, and is harder to grasp because of the extra
> (unused) parameters.
>
> There's also the rather useful point that this allows parameters to
> have convenient default values (also increasing readability over, to
> use your example, copying all the parameters to similarly-named
> locals).

There are several aspects of this issue:

- The design of the ZMachine: it allows only 15 locals and doesn't
differentiate between parameters and local variables

- Tradition: AFAIK, the Inform language evolved naturally from a ZMachine
assembler. So, it kept its major conventions - didn't add a distinction
between parameters and locals, where it didn't exist. Nor does it support
more then 15 locals (it would be very hard to do in the ZMachine, anyway)

- Language design

Realizing the first two, let's concentrate on the last one, which is more or
less independant of them. You are saying that the advantage of the current
design is that unused parameters can be omitted and assume default values.
Undoubtedly this is convenient, but it can be achieved with stricter rules,
like for example in C++. There can be required parameters and optional ones.
It would allow to catch errors at compile time, without sacrificing any
flexibility.

Let's, for the sake of this discussion, invent an extension of Inform's
syntax. Required routine arguments (if any), must come first in the argument
list and are distinguished from optional ones by putting them in brackets.
The end of the argument list optionally can be marked with "." .

So, for example a routine with two required arguments and one local will
look like this:

[ func1 (a b) . c;
c = a + b;
return c;
]

(I know that it could return (a+b) directly, but I just wanted to use
another local for the example)

The only valid way to invoke it is "func1(1,2)", which is what we want.

Similarly, a function with two required and two optional arguments:

[ func2 (a b) c d . e ;
e = a + b + c + d;
return e;
]

It can be invoked in any of the following ways:
func2( 1, 2 )
func2( 1, 2, 3 )
func2( 1, 2, 3, 4 )
However it is invalid to use:
func2( 1 ) or func2( 1, 2, 3, 4, 5 ).

Finally, for compatibility's sake, since all these enhancements are
optional, the existing syntax is still valid:

[func3 a b c;
c = a + b;
return c;
]

And it allows all kinds of bad invocations like: func3( 1 ) or func3( 1, 2,
3, 4 ).

So, what do you think ? :-)

-tzvetan


Kevin Forchione

unread,
Jul 13, 2002, 1:50:21 AM7/13/02
to
"Sean T Barrett" <buz...@TheWorld.com> wrote in message
news:Gz2t3...@world.std.com...

> Ed <e...@mewsic.SPAMGUARD.com> wrote:
> >All three use dynamic rather than static typing.
>
> Actually, though, there's another issue. Most of these languages
> allow the idea that you might say obj->foo and it returns a string,
> but maybe it was a string or maybe it was actually a routine which
> returned a string. This is awfully convenient in IF with all of
> its singleton objects, and doesn't map onto any mainstream
> languages, as far as I know, although I don't think there's any
> reason it couldn't. (Self, a Smalltalk-inspired language, is the
> only one I know of offhand besides pretty much every IF language.)

Self is very interesting, but there's no port for it outside of Solaris, is
there?

--Kevin


Kevin Forchione

unread,
Jul 13, 2002, 2:08:23 AM7/13/02
to
"Raybert" <senorv...@yahoo.com> wrote in message
news:c023b4af.02071...@posting.google.com...

> ft...@maths.usyd.edu.au (Fred the Wonder Worm) wrote in message
news:<agit9f$31f$1...@spacebar.ucc.usyd.edu.au>...
> > Another thing to consider is that "a" or "an" should indicate a
> > willingness to choose any of the available matches. e.g.:
> >
> > You are in a room. There is a red ball and a blue ball here.
> > > take the ball
> > Which ball do you mean, the red ball or the blue ball?
> >
> > vs
> >
> > You are in a room. There is a red ball and a blue ball here.
> > > take a ball
> > red ball: taken
> >
> > Not a big point, but the implication seems valid to me.
>
> Hmm... I would have to disagree with this. I see the implication that
> you're inferring here but I think it's important to be specific.

Specific, as in the use of "indefinite article" as opposed to a "definite
article"? Maybe they don't teach grammar the way they used to.

--Kevin


John Colagioia

unread,
Jul 13, 2002, 9:44:41 AM7/13/02
to
"Tzvetan Mikov" <ce...@jupiter.com> wrote:
>"John Colagioia" <JCola...@csi.com> wrote in message
>news:3D2EC4E...@csi.com...
>> In terms of readability, this means that "function calls" only carry
>> the "parameters" they need,
[...]

>There are several aspects of this issue:
>- The design of the ZMachine: it allows only 15 locals

Untrue. It makes no more than 15 locals *convenient*. A
willing compiler-writer could push pointers to activation
records onto the stack, if there were sufficient
motivation to do so.

> and doesn't
>differentiate between parameters and local variables

Nor do most machines, when the system stack is used for
such things. Certainly, neither Intel nor Motorola chips
know the difference.

>- Tradition: AFAIK, the Inform language evolved naturally from a ZMachine
>assembler. So, it kept its major conventions - didn't add a distinction
>between parameters and locals, where it didn't exist. Nor does it support
>more then 15 locals (it would be very hard to do in the ZMachine, anyway)

See above. It wouldn't be all that hard. Add some code
to pack the data into arrays or an Object, and pass the
relevant pointer or handle.

>- Language design
>Realizing the first two, let's concentrate on the last one, which is more or
>less independant of them.

This should be true, yes.

>You are saying that the advantage of the current
>design is that unused parameters can be omitted and assume default values.

That's about the size of it. I'm sure I could think of
other uses, if pressed, but they'd be contrived.

>Undoubtedly this is convenient, but it can be achieved with stricter rules,
>like for example in C++. There can be required parameters and optional ones.
>It would allow to catch errors at compile time, without sacrificing any
>flexibility.

It is, however, ugly and less readable, in my opinion.

>Let's, for the sake of this discussion, invent an extension of Inform's
>syntax.

[...]


>[ func2 (a b) c d . e ;
> e = a + b + c + d;
> return e;
>]

[...]


>However it is invalid to use:
> func2( 1 ) or func2( 1, 2, 3, 4, 5 ).

I have two problems with this. First, it's ugly in the
extreme; not necessarily because of the symbology,
either. The other...well, I'll wait for that.

>Finally, for compatibility's sake, since all these enhancements are
>optional, the existing syntax is still valid:

This sounds like a job for a pre-processor, since it
can take that annotation and stop the compilation if
there's any deviance.

And, now that I give it some thought, a lint-like pre-
processor would probably be quite nice for Inform. And
the good news is that it could do checking like this
without touching the syntax:

1) If a local is unconditionally assigned a value in
the Routine, then it should never be passed as a
parameter.
2) If the local is never initialized, then it should
be passed as a parameter; auto-initialization (a
very bad thing, which I'm surprised nobody has
argued) be damned. OK, *that* was over the top...

Notice that this changes neither the syntax nor the
semantics of Inform. It just applies some heuristics
to see that the code is "probably" right. Any
programmer ignoring such warnings deserves what he
gets, just like in C.

Arguably, if the programmer is willing to do a tiny
bit of the work (say, by using something like
Hungarian Notation for names, which is no more work
than your new function notation, and is far more
general), a lot of the strong-typing that some
people want could be done, as well, and provides a
handy way to bypass it (using non-Hungarian variable
names) on those occasions where strong typing would
be inconvenient.

[...]


>So, what do you think ? :-)

I think it's a nearly reasonable idea, but probably
doesn't belong in the Inform language or mainstream
compiler, itself.

EPerson

unread,
Jul 13, 2002, 11:11:29 AM7/13/02
to
"Tzvetan Mikov" <ce...@jupiter.com> wrote in message news:<ago3kv$q...@dispatch.concentric.net>...

[snip]

> Let's, for the sake of this discussion, invent an extension of Inform's
> syntax. Required routine arguments (if any), must come first in the argument
> list and are distinguished from optional ones by putting them in brackets.
> The end of the argument list optionally can be marked with "." .
>
> So, for example a routine with two required arguments and one local will
> look like this:
>
> [ func1 (a b) . c;
> c = a + b;
> return c;
> ]

Unfortunately, since Inform is weakly-typed, this is not always enforceable.

x = func1;
y = x(1, 2, 3); ! No way to catch

[snip]

Eric Schmidt
------------

>x me
You have Xed yourself. Do you want to restore, restart, quit or read
the disclaimer?

>disclaimer

DISCLAIMER: I do not speak for Frodo's Frill Factory. I do not speak
for your neighbor. Unless you happen to be my neighbor.

Dan Shiovitz

unread,
Jul 13, 2002, 4:17:51 PM7/13/02
to
In article <c023b4af.02071...@posting.google.com>,

Raybert <senorv...@yahoo.com> wrote:
>ft...@maths.usyd.edu.au (Fred the Wonder Worm) wrote in message news:<agit9f$31f$1...@spacebar.ucc.usyd.edu.au>...
>> Another thing to consider is that "a" or "an" should indicate a
>> willingness to choose any of the available matches. e.g.:
>>
>> You are in a room. There is a red ball and a blue ball here.
>> > take the ball
>> Which ball do you mean, the red ball or the blue ball?
>>
>> vs
>>
>> You are in a room. There is a red ball and a blue ball here.
>> > take a ball
>> red ball: taken
>>
>> Not a big point, but the implication seems valid to me.
>
>Hmm... I would have to disagree with this. I see the implication that
>you're inferring here but I think it's important to be specific. The
>game shouldn't make an arbitrary decision like that, even if the game
>programmer thinks it's the logical choice. There's no guarantee that
>the user who typed that command was really thinking of the same
>meaning.

No, but on the other hand, it's a reasonable interpretation of the
command, and if you're consistent about interpreting it that way, the
user will quickly pick it up, and then you've added a useful thing to
the command set.

>Suppose there was something detrimental about taking the wrong ball:
>wouldn't you want to be absolutely certain which ball the user meant?

Well, maybe. For one thing, they can always undo if they don't like
it. But the main point is that "A BALL" has an extra qualifier, since
"TAKE BALL" will also work. In the case of "TAKE BALL", I agree, the
user isn't providing any disambiguating information and you shouldn't
assume anything. But in the case of "TAKE A BALL" they are providing
extra information; if they aren't happy with how the program responds
to it, they can stop providing it, and if they are, they can keep
doing it when appropriate.

>What you really want here is a special modifier word, "ANY", as in:
>"take any ball". But I just can't see the usefulness of that. I
>would certainly never use it as a player.

TADS supports it now; possibly Inform does also. I find it pretty
useful in response to disambiguation questions:

Which ball do you mean, the large ball or the small ball?
> ANY

Generally I don't use it as part of the main command, because I pick
some other non-ambiguous vocab word if I realize it's going to be an
issue (eg, >TAKE SMALL BALL)

--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW


Tzvetan Mikov

unread,
Jul 13, 2002, 10:09:03 PM7/13/02
to
"EPerson" <esch...@safeaccess.com> wrote in message
news:6e5fc465.02071...@posting.google.com...

> Unfortunately, since Inform is weakly-typed, this is not always
enforceable.
>
> x = func1;
> y = x(1, 2, 3); ! No way to catch

Good point. The ZMachine would have to be enhanced to catch this error ar
runtime.

-tzvetan


L. Ross Raszewski

unread,
Jul 13, 2002, 11:01:11 PM7/13/02
to

(A) No it wouldn't. You can catch this error at runtime in the
Z-machine as it stands now.

(B) I'm not sure there's any advantage in doing it. (That is, to say
that there is an inherent advantage in the IF domain to doing it is to
say that statically typed languages are Better than dynamically typed
ones, and this is generally considered to Not Be A Fact)

Tzvetan Mikov

unread,
Jul 14, 2002, 12:39:09 AM7/14/02
to

"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:XP5Y8.7495$IW4....@nwrddc02.gnilink.net...

> On Sun, 14 Jul 2002 02:09:03 GMT, Tzvetan Mikov <ce...@jupiter.com> wrote:
> >"EPerson" <esch...@safeaccess.com> wrote in message
> >news:6e5fc465.02071...@posting.google.com...
> >> Unfortunately, since Inform is weakly-typed, this is not always
> >enforceable.
> >>
> >> x = func1;
> >> y = x(1, 2, 3); ! No way to catch
> >
> >Good point. The ZMachine would have to be enhanced to catch this error ar
> >runtime.
> >
>
> (A) No it wouldn't. You can catch this error at runtime in the
> Z-machine as it stands now.

This is great. I didn't notice an instruction for that but I am not an
ZMachine expert. How can it be done ?

> (B) I'm not sure there's any advantage in doing it. (That is, to say
> that there is an inherent advantage in the IF domain to doing it is to
> say that statically typed languages are Better than dynamically typed
> ones, and this is generally considered to Not Be A Fact)

Of course. But it is a fact that there is at least a set of problems which
benefit from static typing and the example solution I was proposing (well,
not really proposing, but invented for the sake of discussion) allowed for
both.
I also think that weak typing doesn't necessarily mean uncontrollably
variable function arguments.

-tzvetan


Tzvetan Mikov

unread,
Jul 14, 2002, 12:39:09 AM7/14/02
to

"John Colagioia" <JCola...@csi.com> wrote in message
news:3d30...@excalibur.gbmtech.net...

> > and doesn't
> >differentiate between parameters and local variables
>
> Nor do most machines, when the system stack is used for
> such things. Certainly, neither Intel nor Motorola chips
> know the difference.

Sorry, but you are wrong. Most CPUs have an uniform way of accessing
parameters and locals, but it is clear which one is which (to begin with,
parameters are pushed in the stack before the return address, the function
has to allocate space for locals itself, etc).

> >- Tradition: AFAIK, the Inform language evolved naturally from a ZMachine
> >assembler. So, it kept its major conventions - didn't add a distinction
> >between parameters and locals, where it didn't exist. Nor does it support
> >more then 15 locals (it would be very hard to do in the ZMachine, anyway)
>
> See above. It wouldn't be all that hard. Add some code
> to pack the data into arrays or an Object, and pass the
> relevant pointer or handle.

It may be possible (if one jumps through hoops), but it isn't being done in
Inform, which was my point. The limitation in the programming language is a
direct result of the limitation in the ZMachine.

> >Undoubtedly this is convenient, but it can be achieved with stricter
rules,
> >like for example in C++. There can be required parameters and optional
ones.
> >It would allow to catch errors at compile time, without sacrificing any
> >flexibility.
>
> It is, however, ugly and less readable, in my opinion.

I really don't understand how
[ func a b c;
is more readable than, for example
func ( a = 0, b = 0 ) { var c;
It is not a matter of syntax (I deliberately made this example language
neutral). Choose ant notation you like, but in the first case the
information is simply not there, thus it cannot be read or be "readable". Or
is there any other definition of readability ? :-)

> >Let's, for the sake of this discussion, invent an extension of Inform's
> >syntax.
> [...]
> >[ func2 (a b) c d . e ;
> > e = a + b + c + d;
> > return e;
> >]
> [...]
> >However it is invalid to use:
> > func2( 1 ) or func2( 1, 2, 3, 4, 5 ).
>
> I have two problems with this. First, it's ugly in the
> extreme; not necessarily because of the symbology,
> either. The other...well, I'll wait for that.

This is very subjective. While I agree that the notation with the "." really
sucks (I couldn't think of anything better for the example), I believe that
most people find the brackets notation quite good. Probably that's why it is
used in most programming languages in existance, not to mention algebra ...
:-)

> >So, what do you think ? :-)
>
> I think it's a nearly reasonable idea, but probably
> doesn't belong in the Inform language or mainstream
> compiler, itself.

To tell you the truth, we have a too big difference of opinion for this
discussion to come to a constructive end. You and the original poster seem
to support the point that programming in Inform is unlike programming in
other languages - it has a different requirements for readability, style,
notation, etc. If we start with that then all bets are off and I feel that I
am not qualified to argue convincingly about it, since I haven't ever
written a real game in Inform.

-tzvetan


L. Ross Raszewski

unread,
Jul 14, 2002, 1:58:19 AM7/14/02
to
On Sun, 14 Jul 2002 04:39:09 GMT, Tzvetan Mikov <ce...@jupiter.com> wrote:
>
>This is great. I didn't notice an instruction for that but I am not an
>ZMachine expert. How can it be done ?

I don't have the time to look it up, but I think it's called
@chk_arg_count.


>
>Of course. But it is a fact that there is at least a set of problems which
>benefit from static typing and the example solution I was proposing (well,
>not really proposing, but invented for the sake of discussion) allowed for
>both.
>I also think that weak typing doesn't necessarily mean uncontrollably
>variable function arguments.

Mmm. It means that function val -> val -> val and
function val -> val -> val -> val have to be of different types at
compile time. That's not weak typing.

Why, you'd need to introduce a cast operator.

Juho Snellman

unread,
Jul 14, 2002, 2:10:13 AM7/14/02
to
<ke...@lysseus.com> wrote:
>Self is very interesting, but there's no port for it outside of Solaris, is
>there?

There's a Linux version at <http://www.gliebe.de/self/index.html>, but
the optimizing compiler hasn't been ported. As such, the GUI is
unusable. Programming with a normal editor is possible, but rather
unsatisfying. The language just isn't suited to a normal
edit-compile-run-debug cycle. (Then again, "edit-compile-run-debug"
seems terribly unsuited for IF. Perhaps the Self-like exploratory
programming paradigm would be useful for writing IF.)

--
Juho Snellman
"C:stä on kehitetty Massachusettsin teknillisessä korkeakoulussa kieli
nimeltä BCPL."

L. Ross Raszewski

unread,
Jul 14, 2002, 2:14:17 AM7/14/02
to
On Sun, 14 Jul 2002 04:39:09 GMT, Tzvetan Mikov <ce...@jupiter.com> wrote:
>
>"John Colagioia" <JCola...@csi.com> wrote in message
>news:3d30...@excalibur.gbmtech.net...
>> > and doesn't
>> >differentiate between parameters and local variables
>>
>> Nor do most machines, when the system stack is used for
>> such things. Certainly, neither Intel nor Motorola chips
>> know the difference.
>
>Sorry, but you are wrong. Most CPUs have an uniform way of accessing
>parameters and locals, but it is clear which one is which (to begin with,
>parameters are pushed in the stack before the return address, the function
>has to allocate space for locals itself, etc).
>

s/most CPUs/compliant C implementations.

The CPU doesn't have a formal sense of a function parameter at
all.

For that matter, you might as well say that in the Z-machine,
parameters always come before local variables and claim that this
differentiates them.

>
>It may be possible (if one jumps through hoops), but it isn't being done in
>Inform, which was my point. The limitation in the programming language is a
>direct result of the limitation in the ZMachine.

Your honor, I object to the word 'limitation'. Inform is a weakly
typed language. This isn't a limitation based on a limitation of the
Z-machine (since strong typing has nothing to do with the underlying
machine, except for strongly typed assembly languages, which are
Weird.) It's a conscious decision on the part of the language.


>I really don't understand how
> [ func a b c;
>is more readable than, for example
> func ( a = 0, b = 0 ) { var c;
>It is not a matter of syntax (I deliberately made this example language
>neutral). Choose ant notation you like, but in the first case the
>information is simply not there, thus it cannot be read or be "readable". Or
>is there any other definition of readability ? :-)

Because that information is not relevant. Inform has no sense of
"function taking two parameters" because that's a compile-time type,
and Inform is weakly typed.

You claim that it would be useful for you to know that this is a
function taking two parameters -- but that's a *radical change to how
inform works. Because it's *not* a "function taking two
parameters". It's a function. That the function body assumes that a
and b are initialized by the calling context is somethign about the
content of the function -- that's outside the scope of typing, unless
you have soem way that you mandate that foo be called
"function_that_adds_its_parameters" (That is, type syntax is designed
to express how the function looks, not what it does. In inform, there
is only one type of function, so all functions *look* the same. What's
a parameter and what's a local is something about what the function *does*)

You could make similar readability claims -- why not insist that at
the call-site, you say foo(a=1, b=2);, becauase it makes it more
readably clear that a is initialized to 1 and b to 2 (actually,
there's a language that does this... some ada variant I think)

>>
>This is very subjective. While I agree that the notation with the "." really
>sucks (I couldn't think of anything better for the example), I believe that
>most people find the brackets notation quite good. Probably that's why it is
>used in most programming languages in existance, not to mention algebra ...
>:-)
>

It's not used in ML. Or smalltalk.

THough I found the '.' notation to be the least funky part of it.

>
>To tell you the truth, we have a too big difference of opinion for this
>discussion to come to a constructive end. You and the original poster seem
>to support the point that programming in Inform is unlike programming in
>other languages - it has a different requirements for readability, style,
>notation, etc. If we start with that then all bets are off and I feel that I
>am not qualified to argue convincingly about it, since I haven't ever
>written a real game in Inform.
>

My main problem with your argument is that you draw an arbitrary line
and call it readability. There are all sorts of other things that can
be done to a language syntactically to improve readability, but you
seem to have focused only on those which happen to be in C -- and
they're not in C to improve readability; they're in C because of how
the language works.

John Colagioia

unread,
Jul 14, 2002, 8:53:41 AM7/14/02
to
"Tzvetan Mikov" <ce...@jupiter.com> wrote:
>"John Colagioia" <JCola...@csi.com> wrote in message
>news:3d30...@excalibur.gbmtech.net...
>> > and doesn't
>> >differentiate between parameters and local variables
>> Nor do most machines, when the system stack is used for
>> such things. Certainly, neither Intel nor Motorola chips
>> know the difference.
>Sorry, but you are wrong.

You obviously haven't done much assembly-level programming.

>Most CPUs have an uniform way of accessing
>parameters and locals, but it is clear which one is which (to begin with,
>parameters are pushed in the stack before the return address, the function
>has to allocate space for locals itself, etc).

No. Tradition on certain architectures has developed
among programmers, so that code can more easily be used.
The BP/SP on Intel chips is a convenience for finding
the return address, but even it makes no claims about
the memory above and below either pointer.

If you know of a chip which does make an actual
distinction, I'd genuinely like to hear about it; the
propagation of RISC chips throughout the industry
makes that unfortunately pretty unlikely.

>> >- Tradition: AFAIK, the Inform language evolved naturally from a ZMachine
>> >assembler. So, it kept its major conventions - didn't add a distinction
>> >between parameters and locals, where it didn't exist. Nor does it support
>> >more then 15 locals (it would be very hard to do in the ZMachine, anyway)
>> See above. It wouldn't be all that hard. Add some code
>> to pack the data into arrays or an Object, and pass the
>> relevant pointer or handle.
>It may be possible (if one jumps through hoops),

Jump through hoops!? It'd be, at most, a hundred-line or
so change to the compiler: On a Routine call, allocate
some Z-memory, load the parameters into it, and put the
pointer onto the stack; in the Routine, change the access
to use that pointer instead of the stack pointer.

Side note: If the allocated memory is structured like an
Object, you now have convenient dynamic allocation of
Objects, *and* Routines gain a certain first-classness,
in a roundabout way. Not useful, but really nifty.

>but it isn't being done in
>Inform, which was my point.

Arguably, this was a conscious decision to improve
readability by stonewalling programmers who need a Routine
with twenty parameters and fifty local variables; Such
routines are almost certainly overcomplicated, and need
to be decomposed.

>The limitation in the programming language is a
>direct result of the limitation in the ZMachine.

Where, exactly, is the limitation? I see some
inconveniences for people programming fringe cases, but
nothing like a limitation. Unless you definition of
"limitation" is "it's easier in C." I doubt that, though.

>> >Undoubtedly this is convenient, but it can be achieved with stricter
>rules,
>> >like for example in C++. There can be required parameters and optional
>ones.
>> >It would allow to catch errors at compile time, without sacrificing any
>> >flexibility.
>> It is, however, ugly and less readable, in my opinion.
>I really don't understand how
> [ func a b c;
>is more readable than, for example
> func ( a = 0, b = 0 ) { var c;
>It is not a matter of syntax (I deliberately made this example language
>neutral). Choose ant notation you like, but in the first case the
>information is simply not there, thus it cannot be read or be "readable". Or
>is there any other definition of readability ? :-)

It's more syntax to slog through, none of which provides
any semantic information. That is, it's less readable in
the same way that COBOL is less readable.

>> >Let's, for the sake of this discussion, invent an extension of Inform's
>> >syntax.
>> [...]
>> >[ func2 (a b) c d . e ;
>> > e = a + b + c + d;
>> > return e;
>> >]
>> [...]
>> >However it is invalid to use:
>> > func2( 1 ) or func2( 1, 2, 3, 4, 5 ).
>> I have two problems with this. First, it's ugly in the
>> extreme; not necessarily because of the symbology,
>> either. The other...well, I'll wait for that.
>This is very subjective.

To an extent, but to handwave it as such is to simply say
that you don't care.

>While I agree that the notation with the "." really
>sucks (I couldn't think of anything better for the example), I believe that
>most people find the brackets notation quite good. Probably that's why it is
>used in most programming languages in existance, not to mention algebra ...
>:-)

Chicken and egg. I'd argue that the notation is "popular,"
not because it's better, but because programmers are
conditioned to accept it.

>> >So, what do you think ? :-)
>> I think it's a nearly reasonable idea, but probably
>> doesn't belong in the Inform language or mainstream
>> compiler, itself.
>To tell you the truth, we have a too big difference of opinion for this
>discussion to come to a constructive end.

If you want to take your ball and go home, that's
certainly your prerogative, but I think you're
overlooking critical issues, thinking that C (and
its derivatives) are some pinnacle of evolution.

>You and the original poster seem
>to support the point that programming in Inform is unlike programming in
>other languages - it has a different requirements for readability, style,
>notation, etc.

The former is only as true as it is for the difference
between, say, Java and (to use a recent example) Prolog;
the application domains are usually dissimilar, and,
while you can use the same approaches in both ("You can
write your crappy FORTRAN code in any language," as one
of my old professors used to say), each has more
"native" ways of solving most problems.

The last half of that--readability requirements--should
obviously be true. A different sort of person will read
Inform code than will read COBOL code, and the actual
application will (should) have a different goal and a
different sort of design. Therefore, the language should
cause the programmer to emphasize (read as "cause to be
readable") different aspects.

Does that mean that software engineering techniques
shouldn't be used? No. Again, I'd love to see someone
put together a lint-like tool (and I'd be happy to help
out; I just don't have the time to commit to spearhead
such a project at the moment) to do a bit of checking
long before the compiler ever sees my code.

However, what works for C works for C because of the
PDP-like architecture that C assumes (and simulates),
and the common sorts of programs that C programmers
write. Inform has different assumptions, and Inform
programmers tend to write different sorts of things.
To intelligently improve readability (and, honestly,
have you seen much *unreadable* Inform code?), it'd
be a very good idea to observe some Inform
programmers in action, rather than trying to apply
some other language's standards.

>If we start with that then all bets are off and I feel that I
>am not qualified to argue convincingly about it, since I haven't ever
>written a real game in Inform.

I'd heavily suggest checking out a few languages that
don't follow the C vein. It'll give you a better idea
of what I'm talking about (language idioms and changes
in emphasis), and probably give you some good ideas to
bring back to your "normal" programming.

Tell me if that sounds at all condescending; it isn't
meant to be, and I'd like the opportunity to apologize
and clarify, if necessary.

John Colagioia

unread,
Jul 14, 2002, 8:56:12 AM7/14/02
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
[...]

>>I also think that weak typing doesn't necessarily mean uncontrollably
>>variable function arguments.
>Mmm. It means that function val -> val -> val and
>function val -> val -> val -> val have to be of different types at
>compile time. That's not weak typing.
>Why, you'd need to introduce a cast operator.

Unless you take C's approach, and automatically
dereference function pointers. Unless they're already
dereferenced. This way, *f() == f() == &f() == ****f(),
and everything'll be all right...

John Colagioia

unread,
Jul 14, 2002, 9:08:08 AM7/14/02
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
[...]
>You claim that it would be useful for you to know that this is a
>function taking two parameters -- but that's a *radical change to how
>inform works.

Interestingly, though, it's not a radical change to how
Inform is *used*, which is why I suggested putting the
check into a pre-processor.

Local variables come in three varieties, in Inform:
- Uninitialized: These better come first, and they
better have values assigned to them in the Routine's
call.
- Conditionally Initialized: When the first reference
to a local is a check against zero, it's an optional
parameter.
- Unconditionally Initialized: These should never be
passed in by the calling routine, and should be
declared last.

Yes, there "can't" be uninitialized variables, because
the Inform runtime (or is it the Z-Machine?) sets them
all to zero on invocation. Preinitialized variables
are evil, though...

Similarly, it's be fairly easy to check the return
statements of a Routine to make sure they're
consistent (value, no value, or no explicit value),
and that'd probably have saved me a few mistakes I
made just last week.

>Because it's *not* a "function taking two
>parameters". It's a function.

I'd argue that it's a "routine," rather than a
function. "Function" carries an assortment of
connotations, which I think is what brought this
topic to light in the first place. To wit, C has
"functions;" if Inform has "functions," they should
work like C's.

[...]


>You could make similar readability claims -- why not insist that at
>the call-site, you say foo(a=1, b=2);, becauase it makes it more
>readably clear that a is initialized to 1 and b to 2 (actually,
>there's a language that does this... some ada variant I think)

I think it's proper Ada, optionally. One of the
Modulas may have picked it up, as well, but I
don't follow the Modula scene.

Oh, and VB. I think you can have keyword parameters
there, too.

[...]

L. Ross Raszewski

unread,
Jul 14, 2002, 10:14:16 AM7/14/02
to
On Sun, 14 Jul 2002 09:08:08 -0400, John Colagioia <JCola...@csi.com> wrote:
>
>I'd argue that it's a "routine," rather than a
>function. "Function" carries an assortment of
>connotations, which I think is what brought this
>topic to light in the first place. To wit, C has
>"functions;" if Inform has "functions," they should
>work like C's.

Maybe. On the other hand, in lots of languages, the key difference between
a function and a routine is that a function returns a value. All
Inform functions return a value.

John Colagioia

unread,
Jul 14, 2002, 9:02:08 PM7/14/02
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote:

Hm? If you say so, I guess. I've always used the word
"routine" to mean a "thematically consistent" block of
code. That is, C routines are functions, which return
values; Pascal and Ada have both functions and those
non-returning routines they call procedures; Even BASIC
has routines, but nothing more specific (*sub*routines,
if you use GOSUB).

I suppose that could just be my overactive imagination,
though, giving things unnecessary names.

Tzvetan Mikov

unread,
Jul 15, 2002, 4:30:59 AM7/15/02
to

"John Colagioia" <JCola...@csi.com> wrote in message
news:3d31...@excalibur.gbmtech.net...

> You obviously haven't done much assembly-level programming.

First rule of Usenet etiquette: never express opinions about a poster, only
about his ideas. But since you already apologized in the end ... :-)
(The first assembler program I wrote was in the 80-s on an Apple II - it was
a version of Snakebyte. I've also learned a few things since then)

> No. Tradition on certain architectures has developed
> among programmers, so that code can more easily be used.
> The BP/SP on Intel chips is a convenience for finding
> the return address, but even it makes no claims about
> the memory above and below either pointer.

Hm. This has really nothing to do with the subject, but please, demonstrate
how to push function parameters *after* the return address on x86 :-)

> If you know of a chip which does make an actual
> distinction, I'd genuinely like to hear about it; the
> propagation of RISC chips throughout the industry
> makes that unfortunately pretty unlikely.

Sparc ? EPIC ?
Anyway, you have entirely missed my point. On real CPUs the subroutine has
to take explicit steps for allocating space for locals. A compiler (or an
assembly programmer) must posses the knowledge of the locations of input
parameters and locals. In any convention they are allocated to known
locations (registers or stack), which are different (as specified by the
convention) for params and locals. Examples:
- Register calling conventions. Input parameters must be in specific
registers, in specific order. This informatin is fixed *in advance*, before
the routine is invoked.
- Stack calling conventions. For obvious reasons, space for the input
parameters is allocated by the caller. Again for obvious reasons, space for
locals is allocated by the callee.

I am not talking about physical distinction but about conventions which
enforce a logical one. For example, a ZMachine convention could enforce such
a distinction if locals were allocated from the bottom (starting from number
15). Each routine would also have to check at runtime for too many
parameters (more than 15 - number_of_locals), so that they don't overwrite
the locals. Optionally such extra parameters could be ignored.

(Note that I am not actually suggesting such a change in Inform's code
generation - this is just an example.)

> >> > Nor does it support
> >> >more then 15 locals (it would be very hard to do in the ZMachine,
anyway)
> >> See above. It wouldn't be all that hard. Add some code
> >> to pack the data into arrays or an Object, and pass the
> >> relevant pointer or handle.
> >It may be possible (if one jumps through hoops),
>
> Jump through hoops!? It'd be, at most, a hundred-line or
> so change to the compiler: On a Routine call, allocate
> some Z-memory, load the parameters into it, and put the
> pointer onto the stack; in the Routine, change the access
> to use that pointer instead of the stack pointer.

It wouldn't be quite as easy as you make it sound. I don't have the ZMachine
reference handy, but IIRC, indirect addressing with an offset would require
at least one more instruction per access. Naturally,anything is possible,
the ZMachine is Turing-complete after all, but it is clear that it wasn't
designed for that.

> Side note: If the allocated memory is structured like an
> Object, you now have convenient dynamic allocation of
> Objects, *and* Routines gain a certain first-classness,
> in a roundabout way. Not useful, but really nifty.
>
> >but it isn't being done in
> >Inform, which was my point.
>
> Arguably, this was a conscious decision to improve
> readability by stonewalling programmers who need a Routine
> with twenty parameters and fifty local variables; Such
> routines are almost certainly overcomplicated, and need
> to be decomposed.

Why was 15 chosen as the magical number ? Why not 10 or 20 or, even better,
a compiler parameter ? Are you saying that the choice of 15 locals in Inform
had nothing to do with the ZMachine ? I doubt that, so I don't understand
what you are trying to prove. I agree that too many locals in a single
function are often an indication of a programming problem in any language,
but that's another topic.

> >The limitation in the programming language is a
> >direct result of the limitation in the ZMachine.
>
> Where, exactly, is the limitation? I see some
> inconveniences for people programming fringe cases, but
> nothing like a limitation. Unless you definition of
> "limitation" is "it's easier in C." I doubt that, though.

OK, I give up. I never thought that classifying the fact that Inform
supports only 15 locals as a "limitation" would cause such a violent
protective reaction. Man, I wish we could be more objective... Anyway,
forget that I said it. Having 15 locals is in fact a great advantage! :-)
Let's drop that point. We have drifted away from the subject, whatever it
was ...

> >is there any other definition of readability ? :-)
>
> It's more syntax to slog through, none of which provides
> any semantic information. That is, it's less readable in
> the same way that COBOL is less readable.

Of course it provides semantic information. It enforces the number of
parameters, so that when you pass wrong number of parameters, you would get
a compile-time or runtime error, instead of strange undefined behavior.

I get the idea that you don't like any additional characters in the source
:-), but even you have to agree that automatic error checking is a good
thing, especially if it doesn't interfere with weak typing.

> >To tell you the truth, we have a too big difference of opinion for this
> >discussion to come to a constructive end.
>
> If you want to take your ball and go home, that's
> certainly your prerogative, but I think you're
> overlooking critical issues, thinking that C (and
> its derivatives) are some pinnacle of evolution.

Please, don't put words in my mouth. I haven't in a single place in my posts
in this thread expressed an opinion about "C", let alone compare it with
Inform (I used C++ once as an example of default parameters, because that is
the most popular one). It is you, in fact, who is constantly doing that.

(Not that it matters, but my opinion of C is not quite as flattering as you
might think, especially since I am lookng at it from the viewpoint of a
compiler writer)

I think that you are reading negative things between my lines that I just
haven't said, and this prevents you from looking at Inform with an open
mind. Inform is not the pinnacle of evolution either. As anything else, it
can be improved.

> The former is only as true as it is for the difference
> between, say, Java and (to use a recent example) Prolog;
> the application domains are usually dissimilar, and,
> while you can use the same approaches in both ("You can
> write your crappy FORTRAN code in any language," as one
> of my old professors used to say), each has more
> "native" ways of solving most problems.

Aren't you exagerating a little? :-) I mean, Inform is different, but it
isn't that different. By no means it is as different as ML and Prolog are
from Algol, for example. It definitely doesn't require a drastically new way
of thinking or programming.

[snip]


> I'd heavily suggest checking out a few languages that
> don't follow the C vein. It'll give you a better idea
> of what I'm talking about (language idioms and changes
> in emphasis), and probably give you some good ideas to
> bring back to your "normal" programming.
>
> Tell me if that sounds at all condescending; it isn't
> meant to be, and I'd like the opportunity to apologize
> and clarify, if necessary.

Not a problem. I understand what you mean. I have programmed in Prolog (long
time ago), ML (in college) and Lisp (for fun) - not been paid for it, but
enough. I however feel that Inform programming is much closer to "C"-like
languages. The biggest proof of that is the effort that was required on my
part in order to start reading and understanding Inform sources - I just had
to read the manual. It was much harder with Prolog :-)

-tzvetan


John Colagioia

unread,
Jul 15, 2002, 2:09:19 PM7/15/02
to
Tzvetan Mikov wrote:
> "John Colagioia" <JCola...@csi.com> wrote in message
> news:3d31...@excalibur.gbmtech.net...
>>You obviously haven't done much assembly-level programming.
> First rule of Usenet etiquette: never express opinions about a poster, only
> about his ideas. But since you already apologized in the end ... :-)
> (The first assembler program I wrote was in the 80-s on an Apple II - it was
> a version of Snakebyte. I've also learned a few things since then)

Technically, that was a(n apparently) baseless conclusion, rather
than an opinion. Those are almost certainly free game, right...?
Right...?

>>No. Tradition on certain architectures has developed
>>among programmers, so that code can more easily be used.
>>The BP/SP on Intel chips is a convenience for finding
>>the return address, but even it makes no claims about
>>the memory above and below either pointer.
> Hm. This has really nothing to do with the subject, but please, demonstrate
> how to push function parameters *after* the return address on x86 :-)

I don't see how this is a problem. Push the return address, push
parameters, set SP and BP in an intelligent fashion. You probably
can't use CALL and RET, anymore (ick), but that's a side issue.

More in line with modern practices, simply load the parameters into
[SP-2] and so on, then use CALL and RET as usual.

The point, though, is that the CPU knows (and cares) nothing about
parameters and local variables, and the difference between them. It
takes a programmer (human or compiler) to make those distinctions.

As a programmer, I'd be willing to bet that the first parameter in
any given routine is at [BP+2], because most of us were trained in
the same methodology, but that doesn't mean I'm always going to be
right.

>>If you know of a chip which does make an actual
>>distinction, I'd genuinely like to hear about it; the
>>propagation of RISC chips throughout the industry
>>makes that unfortunately pretty unlikely.
> Sparc ? EPIC ?

I'm not familiar with EPIC, but I'm pretty sure that Sparc follows
the Motorola (and other RISC-a-likes) approach of letting the
programmer choose which to push first.

> Anyway, you have entirely missed my point. On real CPUs the subroutine has
> to take explicit steps for allocating space for locals.

This is true.

> A compiler (or an
> assembly programmer) must posses the knowledge of the locations of input
> parameters and locals.

[...]


> I am not talking about physical distinction but about conventions which
> enforce a logical one.

But, then, you shouldn't be talking about "real CPUs." Apparently,
it's a point of confusion...

> For example, a ZMachine convention could enforce such
> a distinction if locals were allocated from the bottom (starting from number
> 15). Each routine would also have to check at runtime for too many
> parameters (more than 15 - number_of_locals), so that they don't overwrite
> the locals. Optionally such extra parameters could be ignored.
> (Note that I am not actually suggesting such a change in Inform's code
> generation - this is just an example.)

And note that this is almost what already happens. N locals are
allocated; the first M are parameters, up to the number that are
passed in (no more than N, though most implementations don't check,
as far as I know). Any parameters can be ignored.

>>>>>Nor does it support
>>>>>more then 15 locals (it would be very hard to do in the ZMachine,
>>>>> anyway)
>>>>See above. It wouldn't be all that hard. Add some code
>>>>to pack the data into arrays or an Object, and pass the
>>>>relevant pointer or handle.
>>>It may be possible (if one jumps through hoops),
>>Jump through hoops!? It'd be, at most, a hundred-line or
>>so change to the compiler: On a Routine call, allocate
>>some Z-memory, load the parameters into it, and put the
>>pointer onto the stack; in the Routine, change the access
>>to use that pointer instead of the stack pointer.
> It wouldn't be quite as easy as you make it sound. I don't have the ZMachine
> reference handy, but IIRC, indirect addressing with an offset would require
> at least one more instruction per access.

I can only assume that there's a "emit local access Z-code" routine,
which localizes such issues.

> Naturally,anything is possible,
> the ZMachine is Turing-complete after all, but it is clear that it wasn't
> designed for that.

I'm not so sure. I rarely pass values. Far more frequently, I pass
(pointers to) objects and routines into my routines. It's not that
much of a conceptual jump to have the function call do this for me.

[...]


> Why was 15 chosen as the magical number ? Why not 10 or 20 or, even better,
> a compiler parameter ? Are you saying that the choice of 15 locals in Inform
> had nothing to do with the ZMachine ?

I assume, as I said before, it's because the Z-Machine makes it
*easiest* to have 15 locals. That's far different than being limited
to that number.

> I doubt that, so I don't understand
> what you are trying to prove.

I wasn't proving anything; I was explaining that "not like I usually
program" isn't necessarily a "limitation" or "bad thing."

> I agree that too many locals in a single
> function are often an indication of a programming problem in any language,
> but that's another topic.

I don't know that they're unrelated. The usual research says that
humans can only keep track of about 3-7 things at a time. I think
it's significant that the earlier Z-Machine could only carry 7 locals
into a call.

Add in a realization (a few years later) that many functions are
pushing the limit, and it's logical to double the value, figuring
that seven locals, plus seven parameters (plus one, just because the
encoding scheme allows it) should still be viable.

Contrast this with C or (shudder) PERL, where "if you can imagine it,
you can program it," no matter how bad an idea it is.

I seem to recall that, back in the mists of time, we were discussing
readability. Which method improves readability?

>>>The limitation in the programming language is a
>>>direct result of the limitation in the ZMachine.
>>Where, exactly, is the limitation? I see some
>>inconveniences for people programming fringe cases, but
>>nothing like a limitation. Unless you definition of
>>"limitation" is "it's easier in C." I doubt that, though.
> OK, I give up. I never thought that classifying the fact that Inform
> supports only 15 locals as a "limitation" would cause such a violent
> protective reaction.

Well, you called it a limitation (which you admit it shouldn't be,
for any sane programmer), and then argued that it harms readability
in some vague way. I think that's what's causing the reaction.

> Man, I wish we could be more objective... Anyway,
> forget that I said it. Having 15 locals is in fact a great advantage! :-)
> Let's drop that point. We have drifted away from the subject, whatever it
> was ...

No, no. I'm not defending my turf or anything. I want to know what
the actual *problem* is that your solution is intended to treat, and
why you think it should be part of the standard Inform language (two
separate questions).

>>>is there any other definition of readability ? :-)
>>It's more syntax to slog through, none of which provides
>>any semantic information. That is, it's less readable in
>>the same way that COBOL is less readable.
> Of course it provides semantic information. It enforces the number of
> parameters, so that when you pass wrong number of parameters, you would get
> a compile-time or runtime error, instead of strange undefined behavior.

> I get the idea that you don't like any additional characters in the source
> :-),

I did spend some time hacking APL programs, but...

No, what I dislike is additional verbiage that either doesn't solve a
problem (i.e., LISP's desire to have even basic math subexpressions
parenthesized, given that a benefit of prefix notation is that you
don't need to explicitly group things) or solves a problem in a
somewhat backwards way (i.e., prototypes in C--the *right* solution
is to build a compiler that's smart enough to look ahead; Hungarian
notation also falls into this category).

The "right" solution to the problem I believe you're pointing out
(compile-time checking of parameter lists) is to semantically analyze
the existing code, rather than adding unnecessary syntax to carry the
same information.

> but even you have to agree that automatic error checking is a good
> thing, especially if it doesn't interfere with weak typing.

I fail to see the connection between this and adding syntax. In
fact, I'm tempted to say that I fail to see the (necessary)
connection between compile-time error checking and altering the
language at all.

>>>To tell you the truth, we have a too big difference of opinion for this
>>>discussion to come to a constructive end.
>>If you want to take your ball and go home, that's
>>certainly your prerogative, but I think you're
>>overlooking critical issues, thinking that C (and
>>its derivatives) are some pinnacle of evolution.
> Please, don't put words in my mouth. I haven't in a single place in my posts
> in this thread expressed an opinion about "C", let alone compare it with
> Inform (I used C++ once as an example of default parameters, because that is
> the most popular one). It is you, in fact, who is constantly doing that.

Your ideas are fairly obviously inspired by C or are mutually
inspired by the same sources. Not that this is a bad thing, per se,
because C has pretty much infiltrated the collective consciousness of
the software industry (and, by "C," I mean pretty much everything
from BCPL to Java and C#, since they all share the same basic
semantic structure). But there's no reason to try to shove them into
another language or claim their readability based on precedent.

> (Not that it matters, but my opinion of C is not quite as flattering as you
> might think, especially since I am lookng at it from the viewpoint of a
> compiler writer)

Heh. What do you mean? C is a compiler-writer's *dream*! Static
scoping, lot's of "implementation's calls" in the standard, and no
intrinsic I/O. Hell, if you're targetting a PDP machine, you're just
about done, right there...

> I think that you are reading negative things between my lines that I just
> haven't said,

Possibly. I also acknowledge that I may have confused your points
with those of others in the same thread.

> and this prevents you from looking at Inform with an open
> mind. Inform is not the pinnacle of evolution either. As anything else, it
> can be improved.

I haven't said otherwise. What I *have* said is that I don't believe
your particular suggestion was worth integrating into the mainline
language, since it (a) can't have a clean syntax, and (b) adds syntax
which doesn't add any semantic information (which isn't already
knowable from existing syntax), and that, if you really thought it
was a necessity, it'd be fairly easy to place in a preprocessor (as
would my syntaxless variation).

>>The former is only as true as it is for the difference
>>between, say, Java and (to use a recent example) Prolog;
>>the application domains are usually dissimilar, and,
>>while you can use the same approaches in both ("You can
>>write your crappy FORTRAN code in any language," as one
>>of my old professors used to say), each has more
>>"native" ways of solving most problems.
> Aren't you exagerating a little? :-) I mean, Inform is different, but it
> isn't that different. By no means it is as different as ML and Prolog are
> from Algol, for example. It definitely doesn't require a drastically new way
> of thinking or programming.

The syntax and low-level semantics are similar. It doesn't take too
much to, for example, rewrite a C (or Algol, or Java) program in
Inform (NB: Only in theory; I haven't bothered to try this). The
higher-level semantics, and the nifty little "fringe" niceties that
make it an IF language, however, aren't as easy to "backport," for
lack of a better term.

I might argue (from what little I know of the language) that it might
actually be easier to move sufficiently Inform-ish Inform code to ML
than it would to C, though, again, that's only a gut feeling.

To give you an example, just this morning, I reinvented the two-way
door (none of the existing versions did what I needed for the game).
It checks found_in pairs, and automates/hides the remainder of the
directional code by doing "weird" things like iterating through the
contents of "Compass" and using compound, dynamically-chosen
properties.

I'd be hard-pressed to move this to Java.

[...]


> The biggest proof of that is the effort that was required on my
> part in order to start reading and understanding Inform sources - I just had
> to read the manual. It was much harder with Prolog :-)

Really? I found Prolog a breeze. A stupid breeze that I didn't
like, I'll grant you (as Joao pointed out, they're just a bunch of
"floating if-thens"), but fairly easy to start. And, once you get
cuts and stuff, you're done with Prolog. Data structures, algorithms
(oh, sorry, they're not "algorithms," they're...uhm...behaviors, or
something, right...?), and whatever else you might want, is based on
the same five or six constructs (in particular, once you understand a
"family tree" example, and can follow the operation of a stack,
you're really just about done).

Inform, I was able to "code in" after skimming the manual, but I
couldn't "write a program" (idea to design to code) in Inform for
quite a few years. Time will only tell if I can do that *now*, to
be honest...

L. Ross Raszewski

unread,
Jul 15, 2002, 4:26:29 PM7/15/02
to
On Mon, 15 Jul 2002 14:09:19 -0400, John Colagioia <JCola...@csi.com> wrote:
>I might argue (from what little I know of the language) that it might
>actually be easier to move sufficiently Inform-ish Inform code to ML
>than it would to C, though, again, that's only a gut feeling.

I've programmed a fair bit of inform and ML (and C, for that matter),
and I think the only way for this claim to be justified is if you mean
"If you took the inform code, you wouldn't even try to translated it
into ML; you'd just start over again"

Tzvetan Mikov

unread,
Jul 15, 2002, 6:45:17 PM7/15/02
to

"L. Ross Raszewski" <lrasz...@loyola.edu> wrote in message
news:%p8Y8.7149$ak5....@nwrddc01.gnilink.net...

> >I also think that weak typing doesn't necessarily mean uncontrollably
> >variable function arguments.
>
> Mmm. It means that function val -> val -> val and
> function val -> val -> val -> val have to be of different types at
> compile time. That's not weak typing.
>
> Why, you'd need to introduce a cast operator.

I wouldn't think of it! :-) Compile time errors will be issued only when a
function is invoked directly. If it is invoked indirectly the function
signature is lost and the check must be done at runtime.

The issue is not weak vs static typing (or whatever) - these are just
overused terms. The issue is to make it easier to catch accidental bugs. If
that means introducing some form of what might be called static typing,
without breaking compatibility with existing code, why not ?

-tzvetan


It is loading more messages.
0 new messages