General language vs. new IF language vs. existing IF system
Benjamin Fan
thinking of creating their own IF system/language. Please note
that I am writing from the viewpoint of someone who:
1) had reasons to create and use a new IF system or language;
2) already knew Java pretty well; and
3) did not already have proficiency in an existing IF language.
Ben
Advantages and disadvantages of creating an IF system using a general
language vs. creating a new a specialized IF language vs. using an
already existing IF system.
JIGSAW uses a general programming language (Java) rather than a
specialized Interactive Fiction language. What are some of the
advantages of creating a new IF system using a general language
vs. creating a new specialized IF language? What are the
disadvantages of creating a new system using a general language rather
than a specific IF language? What are the disadvantages of creating a
new system vs. just using an existing system?
Advantages (general language vs. specialized IF language)
----------
- Ease of creation. Compared with creating a new IF language,
JIGSAW's use of Java eliminated the need to create a new parser,
compiler, interpreter, etc. Instead, I could concentrate on writing
the IF library.
- Availability of pre-existing compilers and interpreters. In the
case of JIGSAW, many different Java compilers and interpreters
already exist, including free ones like Jikes, GNU Classpath, Kaffe,
and gcj. Also, many other programming utilities, editors, and
development tools exist for these languages.
- Portability. Because the C compilers and Java virtual machines
have been ported to many platforms, games can easily be ported to
these platforms. (But see Disadvantages, below.)
- Existing library. Languages like C and Java usually have a large
library including ready-to-use features and data structures. Authors
can concentrate on writing IF games (and the library) rather than
coding generic support objects and routines.
- Rich feature set. General languages tend to have support for many
features that might not be found in other IF languages. In the case
of JIGSAW, the standard Java library comes with support for
multithreading, internationalization, file manipulation, string
library, math library, GUI support, serialization, networking,
in-line documentation, garbage collection, databases,
remote/distributed objects, security, XML, etc.
- Ease of programming. Instead of having to learn yet another
programming language, authors just use the commonly-used general
programming language that (perhaps) they already know.
- Portability/Marketability of skills. The programming skills that
authors learn while creating IF with a general language such as C,
Perl, or Java can be used on other projects. These skills are easily
recognizable by others, and they might be valuable in the job market.
- Dynamically-linked libraries. Libraries and Java class files can
be compiled separately and then used as drop-in replacements. This
allows incremental improvements of components (such as the parser) to
be used with already-compiled games. (Hmmm.... is this really an
advantage?)
Disadvantages (general language vs. specialized IF language)
-------------
- Difficulty of programming. A general programming language such as
JIGSAW's Java is as difficult to learn as any other general
programming language. A specialized IF language (if written
properly) will be easier for authors to learn, at least for basic
games.
- Portability. In the case of Java, although it has been ported to
many platforms, there are compatibility problems which make this less
than perfect. C implementations also can be platform-dependent for
things such as integer size. Specialized IF machines can be truly
standardized.
- Heavyweight virtual machine. In the case of JIGSAW, the Java VM is
heavier than IF virtual machines such as zcode or glulx. This may
prevent games from being ported to lightweight platforms such as
mobile devices.
Disadvantages (of new IF systems):
-------------
- System needs to be created. Not using an existing system requires
that the new system be created. This could be a major obstacle.
- Lack of IF library. Creating JIGSAW required (and still requires)
writing the IF library. Other mature IF systems have had these
libraries developed over the years.
- Crappy games. Until the IF library matures, games will tend to be
crappier than those developed with the mature IF libraries available
for specialized IF languages. As an example, until someone writes a
better parser, JIGSAW games will use its old-fashioned, two-word
parser.
- Lack of support. One of the disadvantages of using a new IF system
is that there is a smaller community to help authors.
--
To get my current email address, concatenate these three strings:
1. "benjamin_fan" 2. "_2002a" 3. "@yahoo.com"
It will look a lot like: xxxxxxxx_yyy_zzzzz @ yahoo . com
L. Ross Raszewski
<junkaccou...@yahoo.com> wrote:
>Disadvantages (general language vs. specialized IF language)
>-------------
One thing you omit is one of the most characteristic features of
IF-oriented languages: orientation toward large amounts of static
data. In most general-purpose languages, the sort of static, one-off
compile-time data entry that goes into the model world of IF is much
clunkier to perform (Prolog and PL/SQL occasionally come to mind as
slightly more mainstream languages which center more around static
data, but each of these raise equally confusing issues for IF
creation.
Daniel Barkalow
> Here are more IF system development notes to help those who are
> thinking of creating their own IF system/language. Please note
> that I am writing from the viewpoint of someone who:
> 1) had reasons to create and use a new IF system or language;
> 2) already knew Java pretty well; and
> 3) did not already have proficiency in an existing IF language.
Comparing Cloak of Darkness implementations and ignoring lines which are
entirely comments or blank:
Inform: 100 lines
Tads: 144 lines
JIGSAW: Cloak.java: 299 lines, Cloak.properties: 39 lines
So JIGSAW requires writing more than 3 times as much code as Inform, and
more than twice as much as TADS.
Furthermore, it doesn't seem like JIGSAW will scale well to larger
games; everything seems to have to be in the one file. Considering that
"Shade", which is a reasonably small game, being a Comp entry, is 5043
(non-trivial) lines of Inform, it's unlikely that a single file consisting
of 15000 lines of Java will be at all managable.
The main advantage of using a specialized language for IF is that it is,
well, specialized for IF, and therefore allows the programmer to express
IF concepts much more easily and compactly.
-Iabervon
*This .sig unintentionally changed*
Sean Don
On 15 Jan 2003 20:30:36 -0800
junkaccou...@yahoo.com (Benjamin Fan) wrote:
> [...]
>
> 3) did not already have proficiency in an existing IF language.
It would probably help a lot if you did; that way you'd know what not to include (or what new things to include) in your new language that you thought were not "well" implemented in previous languages.
Although I really like Inform, I can understand why one would like to develop one's own set of libraries.
> [...]
> Disadvantages (general language vs. specialized IF language)
> -------------
>
> - Difficulty of programming. A general programming language such as
> JIGSAW's Java is as difficult to learn as any other general
> programming language. A specialized IF language (if written
> properly) will be easier for authors to learn, at least for basic
> games.
Yes, and no. For basic games, yes. But, I think I spent just as much time learning all the Inform tricks as I did learning C (and about the use of pointers, etc) way back when I was still in High School.
> - Portability. In the case of Java, although it has been ported to
> many platforms, there are compatibility problems which make this less
> than perfect. C implementations also can be platform-dependent for
> things such as integer size. Specialized IF machines can be truly
> standardized.
>
> - Heavyweight virtual machine. In the case of JIGSAW, the Java VM is
> heavier than IF virtual machines such as zcode or glulx. This may
> prevent games from being ported to lightweight platforms such as
> mobile devices.
> [...]
Furthermore, the Java VM is a real strain on my old machine.
Personally, I don't see that a large number of lines of code would be a real problem; in the case of a Java, once the game is compiled, it doesn't really matter how many lines there were; the only thing that matters then is how big the JAR file winds up being; and, that's only a concern if one is playing on, say, a palm pilot --like you already mentioned.
I'm not a computer scientist --like some of my friends are becoming-- but I wonder if an interpreter language would be a better choice for you --PAWS, for example, used Python.
Maybe I'm wrong about this, but I imagine some interpreter languages are a good deal better at handling loads of static data than other general-purpose languages; I imagine this is especially true if the language has database or dictionary support.
Interpreter languages are still a little heavier than the Z-Machine (and possibly Glulx, or the T3 machine), but one's like Python run a hell of a lot faster than Java does on older machines.
If you like the idea, I can't imagine there's anything that is stopping anybody from writing an alternative to PAWS (or developing PAWS further); alternatively, if you still like the idea, you may wish to check out some other interpreters that are available:
http://packages.debian.org/stable/interpreters/
Just a few thoughts,
Good luck,
Sean
Default User
>
> Here are more IF system development notes to help those who are
> thinking of creating their own IF system/language. Please note
> that I am writing from the viewpoint of someone who:
> 1) had reasons to create and use a new IF system or language;
> 2) already knew Java pretty well; and
> 3) did not already have proficiency in an existing IF language.
Item 3 is key, as that is where I am. I have no knowledge of any of the
basic IF languages used here, but I'm and expert-level C programmer and
a practictioner-level C++ programmer (my current profession). I have
exposure to various other GP languages.
When I was learning C back in the late 80's, I wrote an IF game as a
training project. That worked great and I learned a lot, plus the game
works OK. However, I wasn't devising anything like a system, the game is
basically a one-off. Only a few parts could reused without massive
recoding.
I did some MUD programming (EOTL) and became fairly familiar with LPC.
It's actually pretty nifty for writing games for a C or C++ programmer,
but you need the whole driver infrastructure (as far as I know) to run
anything, so not good for individual games.
When I was in grad school, I did a game system in C++ that had a game
skeleton and a object editor for creating rooms, NPCs and inanimate
objects. It used an object-to-object message passing system for actions,
messages would walk up the inheritance ladder as needed until a handler
was found. I'd like to revisit that project, but I can't find the
fricking fracking disk I stored it on.
Brian Rodenborn
ka...@henchmonkey.org
> Benjamin Fan wrote:
>> 3) did not already have proficiency in an existing IF language.
>
>
> Item 3 is key, as that is where I am. I have no knowledge of any of the
> basic IF languages used here, but I'm and expert-level C programmer and
> a practictioner-level C++ programmer (my current profession). I have
> exposure to various other GP languages.
>
This is all useful, but please people, if you want to write a new
system, look at what else is out there! If you're going to build a
bridge, you probably want to study the Brooklyn Bridge, the Golden gate
Bridge, and the Tocoma Narrows Bridge. If you're building boats, take a
look at that thing the Australians used in the America's cup, and the
Titanic. And please, if you're writing a new IF system, look at Inform,
TADS, Hugo, and the fifty other systems on the archive that no one ever
uses.
katre
Daniel Barkalow
> Benjamin Fan wrote:
> >
> > Here are more IF system development notes to help those who are
> > thinking of creating their own IF system/language. Please note
> > that I am writing from the viewpoint of someone who:
> > 1) had reasons to create and use a new IF system or language;
> > 2) already knew Java pretty well; and
> > 3) did not already have proficiency in an existing IF language.
>
> Item 3 is key, as that is where I am. I have no knowledge of any of the
> basic IF languages used here, but I'm and expert-level C programmer and
> a practictioner-level C++ programmer (my current profession). I have
> exposure to various other GP languages.
I honestly think that Inform would be vastly improved by a C-like syntax
and fewer traps for the unwary. At that point, it would be much like Java,
except without the features you don't need and with the extensions you'd
really like, and furthermore, intuitive to Java programmers and
non-programmers alike.
Stas Starkov
> Advantages (general language vs. specialized IF language)
> ----------
>
> - Rich feature set. General languages tend to have support for many
> features that might not be found in other IF languages. In the case
> of JIGSAW, the standard Java library comes with support for
> multithreading, internationalization, file manipulation, string
> library, math library, GUI support, serialization, networking,
> in-line documentation, garbage collection, databases,
> remote/distributed objects, security, XML, etc.
I'm not sure that it is so much an advantage: what will stop somebody
from creating a "game", that could just format a player hard drive? Or
transfer a private information over Internet to the cracker? Under UNIX
it's quite easy to prevent that (using a user privilege). What about
Windows 9x (not NT)?
--
Stas Starkov (stas_ at mail.rb.ru)
SteveG
<iabe...@iabervon.org> wrote:
>I honestly think that Inform would be vastly improved by a C-like syntax
>and fewer traps for the unwary.
Isn't that called 'Hugo'?
(I'm not being flippant, though maybe stupid. I haven't seriously used
either Hugo or Inform but I do have the impression that they have
similarities in programming but the Hugo syntax is much more
self-consistent and perhaps more 'C-like'.)
>At that point, it would be much like Java,
>except without the features you don't need and with the extensions you'd
>really like, and furthermore, intuitive to Java programmers and
>non-programmers alike.
-- SteveG
remove _X_ from my address to send me email
Default User
> I honestly think that Inform would be vastly improved by a C-like syntax
> and fewer traps for the unwary. At that point, it would be much like Java,
> except without the features you don't need and with the extensions you'd
> really like, and furthermore, intuitive to Java programmers and
> non-programmers alike.
That's why I liked working in LPC. I suspect something like that could
be made to work for creating standalone IF as opposed to MUD code.
Anyone tackling that would have to get familiar with the things the game
driver does for a MUD, and how that would be similar to and different
from standard IF.
The following is a room definition from some of the code I wrote during
my active period on EOTL. Warning, it is fairly lengthy, about 100 lines
or so.
Brian Rodenborn
================================================
#include "/usr/boru/test/paths.h"
inherit RoomPlusCode;
#define MSG \
"Suddenly, a pair of magpies swoops down and lands near the old tree.
They " \
"decide the sticks are perfect nest building material, so they each grab
" \
"one of the sticks and fly off towards the west."
#define CLIMB1 \
"You manage to shinny up the trunk of the tree.\n"
#define CLIMB2 \
" climbs up the tree and out of sight.\n"
#define UP ROOM_PATH + "up_tree"
void extra_create()
{
set( "short", "The Meadow" );
set( "day_long",
"This is an ancient meadow, once rich farmland, but " +
"now overgrown with weeds and wild plants. A gnarled " +
"old tree shades one area, while a large boulder dominates " +
"the northeast corner of the meadow. Lying on the ground " +
"under the tree you see a flat rock." );
set( "exits", ([
"north" : ROOM_PATH + "cabin",
"south" : ROOM_PATH + "forest",
"east" : ROOM_PATH + "riverbank",
"west" : ROOM_PATH + "hillside",
"northeast" : ROOM_PATH + "beside_boulder"
]) );
set( OutsideP, 1 );
set( "descs", ([
"tree" :
"This old oak shades the meadow with its mighty limbs. " +
"It looks as though you may be able to climb it, up " +
"to a point. ",
"boulder" :
"The boulder is a huge piece of granite jutting up from " +
"one corner of the meadow. You are too far away from it to " +
"see much else."
]) );
set( "reset_data", ([
"sticks" : OBJ_PATH + "sticks",
"rock" : OBJ_PATH + "rock"
]) );
}
extra_init()
{
object sticks;
sticks = check_sticks();
if( sticks != 0 )
{
call_out( "remove_sticks", 45 + random( 15 ) );
}
add_action( "do_climb", "climb" );
}
int do_climb( string str )
{
if( str != "tree" )
return 0;
tell_room( THISO,
strformat( PNAME + CLIMB2 ), ({THISP}) );
tell_object( THISP, strformat( CLIMB1 ) );
move_object( THISP, UP );
command( "glance", THISP );
return( 1 );
}
object check_sticks()
{
object *all;
string short;
int i;
all = all_inventory();
for( i = 0; i < sizeof( all ); i++ )
{
short = all[i]->query( "short" );
if( short != 0)
{
if( (strstr( short, "sticks" ) ) != -1 )
{
return all[i];
}
}
}
return 0;
}
void remove_sticks()
{
object sticks;
sticks = check_sticks ();
if( sticks != 0)
{
tell_room( ENV( sticks ), strformat ( MSG ) );
destruct( sticks );
}
while( remove_call_out( "remove_sticks" ) != -1 );
}
Neil Cerutti
> On Thu, 16 Jan 2003 22:56:40 -0500, Daniel Barkalow
><iabe...@iabervon.org> wrote:
>
>>I honestly think that Inform would be vastly improved by a C-like syntax
>>and fewer traps for the unwary.
>
> Isn't that called 'Hugo'?
>
> (I'm not being flippant, though maybe stupid. I haven't seriously used
> either Hugo or Inform but I do have the impression that they have
> similarities in programming but the Hugo syntax is much more
> self-consistent and perhaps more 'C-like'.)
I would call it more TADS-like, actually. I seem to remember the HUGO
manual explaining the way the syntax arose. And anyhow, only a masochist
and math-wizard would ever themselves the task of parsing Inform code.
It seems Graham Nelson was REALLY INTERESTED in compilers -- interested
enough to write his own lexer and parser for a syntax irregular enough to
be impossible(?) to define with Lexx/Yacc.
The only syntax borrowed nearly verbatim from Inform that I'm aware of are
Verb declarations; however they don't have exactly the same semantics.
Writing HUGO actually led me to a greater appreciation of Inform's
irregular syntactical niceties.
--
Neil Cerutti <cer...@trans-video.net>
Daniel Barkalow
> On Thu, 16 Jan 2003 22:56:40 -0500, Daniel Barkalow
> <iabe...@iabervon.org> wrote:
>
> >I honestly think that Inform would be vastly improved by a C-like syntax
> >and fewer traps for the unwary.
>
> Isn't that called 'Hugo'?
I was actually thinking of something feature-for-feature equivalent (and
therefore able to use the Inform library). Hugo is not quite that much the
same. I'm thinking on the order of "uses /* */ and // for comments",
"inequality is !=", "functions are name(args) with braces", "objectloop
over children is called something different", "switch cases start with
case", and so forth. Additionally, I think that targetting Z-machine/GLULX
is a useful feature.
(Oddly, Hugo seems to use line breaks at the ends of statements and
comments with '!', which is very un-C-like)
L. Ross Raszewski
<iabe...@iabervon.org> wrote:
>
>I was actually thinking of something feature-for-feature equivalent (and
>therefore able to use the Inform library). Hugo is not quite that much the
>same. I'm thinking on the order of "uses /* */ and // for comments",
>"inequality is !=", "functions are name(args) with braces", "objectloop
>over children is called something different", "switch cases start with
>case", and so forth. Additionally, I think that targetting Z-machine/GLULX
>is a useful feature.
I don't see why these sorts of C-similarities are important or indeed
useful. (Though C-like switching behaviour would be nice in a few
cases -- the reason C switches aren't identical to nested ifs is
because if they were identical, there'd never be any need to *use*
them). Certainly, no one who doesn't know C is going to be bothered by
it, and I don't see why anyone who knows C would be any more bothered
by it than by the fact that all languages have differences from each
other (On the other hand, I sometimes wish inform was *more* different
from C; I have an easy time not using C-syntax in, say, ML, because it
makes me gear-shift the coding part o' the brain)
Sean Don
Whoops! My sincere apologies; I updated my mail client just a few days
ago and forgot to set it up to wrap text.
Sorry about the mess,
Sean
Daniel Barkalow
In part because Inform is almost-by-not-quite like C, which, like you say,
tends to confuse people who switch back and forth, and in part because the
Inform syntax is somewhat failure prone (Using ! instead of ~~ or !=
instead of ~= is common and mysterious), not terribly consistant (blocks
of code are in braces unless they are functions; function names go instead
the brackets but method names go outside the brackets; colons are used
nowhere other than in for statements), and occasionally quite odd
(objectloop (a in b) vs objectloop (a && (a in b))).
Inform is obviously designed by someone thinking about language features
and library features and not about the language syntax. This was probably
just as well; it might not have been developed at all if Graham had spent
his time learning about the design of programming language syntax, but it
need not retain its current syntax.
katie did.
> On Thu, 16 Jan 2003 22:56:40 -0500, Daniel Barkalow
> <iabe...@iabervon.org> wrote:
>
> >I honestly think that Inform would be vastly improved by a C-like syntax
> >and fewer traps for the unwary.
>
> Isn't that called 'Hugo'?
>
> (I'm not being flippant, though maybe stupid. I haven't seriously used
> either Hugo or Inform but I do have the impression that they have
> similarities in programming but the Hugo syntax is much more
> self-consistent and perhaps more 'C-like'.)
Not quite; Hugo seems to use <newline> for a command break, where Inform uses
";" like C.
Sometimes Hugo is more C-like, but often it is Inform that is more C-like.
>
> >At that point, it would be much like Java,
> >except without the features you don't need and with the extensions you'd
> >really like, and furthermore, intuitive to Java programmers and
> >non-programmers alike.
>
> -- SteveG
> remove _X_ from my address to send me email
And to C/C++ programmers, perhaps, too.
;)
-kd.
Plugh!
> basic IF languages used here, but I'm and expert-level C programmer and
> a practictioner-level C++ programmer (my current profession). I have
> exposure to various other GP languages.
Yes, I must admit that I want classes/objects in TADS/Inform to behave
like classes/objects in C++ and they simply don't. I want true
multiple inheritance, polymorphism, etc and the best way to get that
seems to be C++ (maybe java?).
Plugh!
> from creating a "game", that could just format a player hard drive? Or
> transfer a private information over Internet to the cracker?
Wasn't that called AmissVille ?
John W. Kennedy
Java does not have true multiple inheritance, although it has a limited
mechanism called "interfaces". A class can "extend" only one parent
class, but it can "implement" any number of interfaces. An interface
is like a class, except that it can have only class data (called
"static" in both languages), and all methods must be abstract.
--
John W. Kennedy
"The poor have sometimes objected to being governed badly;
the rich have always objected to being governed at all."
-- G. K. Chesterton, "The Man Who Was Thursday"
Neil Cerutti
There's nothing "true" about the way C++ works.
However, Inform and TADS are both written in C; you may be able
to call Inform and/or TADS from C++ code, and get a combination
that works just the way you want it too. ;-)
--
Neil Cerutti <cer...@trans-video.net>
Magnus Olsson
Plugh! <pl...@plugh.info> wrote:
>Yes, I must admit that I want classes/objects in TADS/Inform to behave
>like classes/objects in C++ and they simply don't. I want true
>multiple inheritance, polymorphism, etc
In what way does TADS not support true multiple inheritance and
polymorphism?
--
Magnus Olsson (m...@df.lth.se)
PGP Public Key available at http://www.df.lth.se/~mol
Adam Thornton
Stas Starkov <st...@mail.rb.ruANTISPAM> wrote:
>I'm not sure that it is so much an advantage: what will stop somebody
>from creating a "game", that could just format a player hard drive? Or
>transfer a private information over Internet to the cracker? Under UNIX
>it's quite easy to prevent that (using a user privilege). What about
>Windows 9x (not NT)?
There was a hideous, hideous game in the Comp a couple years back,
called "The Commute."
It was a DOS game.
What it did was to reset your system clock to either 8:00 or 9:00 AM
when it ran, for, uh, verisimilitude or something.
Words could not then, and cannot now, express how rude, inappropriate,
and aggravating I found this. I couldn't forgive that even in a *good*
game--which this assuredly was *not*.
For a while I had planned to do a Comp entry, "Commute II: The
Reckoning"--and who knows, I still might--as an Apple ][ .DSK format
game. Its big gimmick would be that, when you died (this would be a
real-old-sk00l, instant-death-for-going-through-the-wrong-door kinda
game), it would reformat the floppy disk image, which I figured would
get the point across without actually damaging the user's computer.
Adam
Nikos Chantziaras
> Yes, I must admit that I want classes/objects in TADS/Inform
> to behave
> like classes/objects in C++ and they simply don't. I want true
> multiple inheritance, polymorphism, etc and the best way to
> get that seems to be C++ (maybe java?).
Polymorphism isn't needed in Tads (for example, function/method parameters
aren't checked anyway) and multiple inheritance is supported. Maybe you
misunderstood something?
-- Niko
Mike Roberts
> > Yes, I must admit that I want classes/objects in TADS/Inform
> > to behave like classes/objects in C++ and they simply don't.
>
> Polymorphism isn't needed in Tads (for example, function/method
> parameters aren't checked anyway) and multiple inheritance is
> supported.
How are you defining polymorphism that it isn't needed in TADS? The way I
define it, which is the way I think most people define it, TADS wouldn't
work at all without polymorphism. My definition is that you can use an
object reference knowing only the base class at compile-time, but
nonetheless receive at run-time the services of the actual subclass when
calling the object's methods. In other words, the same code will work when
handed any subclass of the base class which the code is written to expect,
and whenever that code invokes methods on those objects, it will invoke the
subclassed methods for the objects it's actually handed. The lack of
compile-time type declaration syntax only makes this more important, because
as far as the compiler is concerned, every object is of the root object
type; if there were no polymorphism, you couldn't invoke anything but the
methods provided by the root object class, which in TADS 2 would mean you
couldn't call any methods or properties at all.
--Mike
mjr underscore at hotmail dot com
Joe Mason
A big advantage of Inform's objects over C++ is that you can define and
instantiate them in one block instead of needing to make separate class
definitions. This works well for IF, which tends to have a lot of
fixed, unique objects instead of lots of clones generated by factories.
(Of course, there is the napkin dispenser as well - the best IF language
would be able to do both. Which Inform is, with a bit of ugly hackery.)
Joe
Nikos Chantziaras
> "Nikos Chantziaras" <for....@manager.de> wrote:
> > > Yes, I must admit that I want classes/objects in TADS/Inform
> > > to behave like classes/objects in C++ and they simply don't.
> > > I want true multiple inheritance, polymorphism, etc [...]
> >
> > Polymorphism isn't needed in Tads (for example, function/method
> > parameters aren't checked anyway) and multiple inheritance is
> > supported.
>
> How are you defining polymorphism that it isn't needed in TADS?
Oops, sorry. What I should write is actually "C++-like polymorphism isn't
needed in Tads". Of course there's polymorphism in Tads, or else you
couldn't override the methods of a base class. My point was that you can
pass everything as a parameter, since formal and actual parameters aren't
checked for "compatibilty"; not possible in C++.
-- Niko
Magnus Olsson
But that's not what's normally called polymorphism; it's a matter of
typing (C++ has strong, compile-time typing; TADS hasn't, and Inform
is almost typeless).
Mike Roberts
> What I should write is actually "C++-like polymorphism
> isn't needed in Tads". Of course there's polymorphism in
> Tads, or else you couldn't override the methods of a base
> class. My point was that you can pass everything as a
> parameter, since formal and actual parameters aren't
> checked for "compatibilty"; not possible in C++.
Again, it really is exactly the same kind of polymorphism that C++ has. I
get the impression you might be thinking along that there can't be
polymorphism if you don't have types at all, but remember that tads *is* (at
least[1]) as strongly typed as C++ - but only at run-time, not at
compile-time.
Consider this thought experiment: suppose that you *could* declare variable
types in tads, so that you could define a method like this:
myMethod(Thing foo) { foo.someMethod(); }
Now we have the functional equivalent of the C++ you're talking about,
right? The compiler will enforce this type declaration by allowing only
Thing and subclasses of Thing to be passed for 'foo'. In C++, and now in
our modified tads, the polymorphism comes from the language's ability to
figure out at run-time whether to call Thing::someMethod(),
Actor::someMethod(), Room::someMethod(), or whatever, based on the actual
run-time class of the object we pass for 'foo'. In our hypothetical
tads-with-declarations, we have the same meaning as we would in C++,
essentially the same syntax, and I think you'll agree that we have exactly
the same variety of polymorphism. Right?
But now take away the type declaration, and we have the actual tads syntax.
Everything else remains the same; we can still pass in a Thing or any
subclass of Thing for 'foo', and we'll still call Thing.someMethod or
Actor.someMethod or Room.someMethod, or whatever, based on the actual
run-time type of the value we pass in. It happens that we can also pass in
some unrelated class for 'foo', but that's beside the point; that's just
something *extra* that C++ can't do.
--Mike
mjr underscore at hotmail dot com
[1] In a sense, tads is actually more strongly typed than C++, in that tads
simply doesn't provide any type conversions that remove abstractness, such
as C++'s ability to convert a pointer to an integer. In tads, an object
reference is just that, and has no lower-level representation that a program
can access.
Nikos Chantziaras
> "Nikos Chantziaras" <for....@manager.de> wrote:
> > What I should write is actually "C++-like polymorphism
> > isn't needed in Tads". Of course there's polymorphism in
> > Tads, or else you couldn't override the methods of a base
> > class. My point was that you can pass everything as a
> > parameter, since formal and actual parameters aren't
> > checked for "compatibilty"; not possible in C++.
>
> Again, it really is exactly the same kind of polymorphism
> that C++ has. I get the impression you might be thinking
> along that there can't be polymorphism if you don't have
> types at all, but remember that tads *is* (at least[1]) as
> strongly typed as C++ - but only at run-time, not at
> compile-time.
>
Mike, thanks for the detailed explanation. Now I understand better the
relation between runtime-typing and polymorphism.
Now go on and implement Tads4, which has compile-time type-checks! <grin>
-- Niko
David Thornley
Nikos Chantziaras <for....@manager.de> wrote:
>
>Now go on and implement Tads4, which has compile-time type-checks! <grin>
>
some don't, and the people who use them don't seem to miss it.
Partly, it's not all that important. Most people really don't seem
to make all that many type errors that aren't fairly quickly caught
by other means (including run-time checks - the language I'm most
familiar with that lacks compile-time checks, Common Lisp, is also
known for the ease of running small sections of code, eliminating
the need for scaffolding).
There's another issue, also. In languages with compile-time checking,
it is customary to assign each object a fixed type, and after that
it becomes very difficult to change it. This means that the developer
has to guess ahead of time what type will be appropriate, which is
easy in most cases and difficult in some. If you find that a value
you had assumed to take integer values should take other values,
you're better off if all your routines are expecting a number rather
than if they're all expecting a 32-bit integer.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Mark 'Kamikaze' Hughes
> In article <b19gt8$111vdd$1...@ID-151409.news.dfncis.de>,
> Nikos Chantziaras <for....@manager.de> wrote:
>>Now go on and implement Tads4, which has compile-time type-checks! <grin>
> Most languages do have some sort of compile-time type-checking, but
> some don't, and the people who use them don't seem to miss it.
> Partly, it's not all that important. Most people really don't seem
> to make all that many type errors that aren't fairly quickly caught
> by other means (including run-time checks - the language I'm most
> familiar with that lacks compile-time checks, Common Lisp, is also
> known for the ease of running small sections of code, eliminating
> the need for scaffolding).
Languages without static typing are great for fast development, and
work very well on small projects. On larger programs, however, it
becomes harder and harder to work without making API errors. Typos in
method names, incorrect method arguments, and variable references are
merely bad, and they'll blow up when you hit that line. Typos in
variable assignments are disastrous, because they don't blow up, they
just leave you with wrong values.
Python's a beautiful language, and I love working in it, but I'll
never use it for another large project, after my Umbra CRPG:
<http://kuoi.asui.uidaho.edu/~kamikaze/Umbra/>. The debugging and
testing phase was just too difficult.
Using Extreme Programming techniques, like writing code test-first,
can mitigate some of that problem, but it's a hard discipline to keep.
I'd like to see a language with dynamic typing that requires initial
declarations of variables in a class to have a special syntax. Like
this pseudo-Python:
class Foo:
var a=0
var b=0
foo = Foo()
foo.a = 1 # okay
foo.b = 2 # okay
foo.c = 3 # blows up
You can sort of simulate that in Python by hacking getattr and
setattr, but it's an ugly trick.
--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"We remain convinced that this is the best defensive posture to adopt in
order to minimize casualties when the Great Old Ones return from beyond
the stars to eat our brains." -Charlie Stross, _The Concrete Jungle_
Neil Cerutti
'Kamikaze' Hughes wrote:
> I'd like to see a language with dynamic typing that requires
> initial declarations of variables in a class to have a special
> syntax. Like this pseudo-Python:
>
> class Foo:
> var a=0
> var b=0
>
> foo = Foo()
> foo.a = 1 # okay
> foo.b = 2 # okay
> foo.c = 3 # blows up
>
> You can sort of simulate that in Python by hacking getattr and
> setattr, but it's an ugly trick.
Object foo with
a 0,
b 0;
[ Main;
foo.a = 1; ! Okay
foo.b = 2; ! Okay
foo.c = 3; ! Compile-time error.
];
Maybe Inform isn't such a bad language after all! ;-)
If c is declared as a Common Property, or if c is an Individual
Property of another Object, then it is a run-time error instead.
--
Neil Cerutti <cer...@trans-video.net>
boa13
>
> I'd like to see a language with dynamic typing that requires
> initial declarations of variables in a class to have a
> special syntax.
> Like this pseudo-Python:
>
> class Foo:
> var a=0
> var b=0
>
> foo = Foo()
> foo.a = 1 # okay
> foo.b = 2 # okay
> foo.c = 3 # blows up
>
> You can sort of simulate that in Python by hacking getattr and
> setattr, but it's an ugly trick.
What do you think of the following transcript? :-)
bash-2.05$ python
Python 2.2.1 (#1, Jun 2 2002, 12:10:09)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class Foo(object):
... __slots__ = ('a', 'b')
...
>>> foo = Foo()
>>> foo.a = 1
>>> foo.b = 2
>>> foo.c = 3
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'Foo' object has no attribute 'c'
>>>
I wish I could leave you with just that, but I feel compelled to
add that:
1. This only works in Python 2.2 and greater
2. We are subclassing "object", so we are a "new-style class"
3. New-style classes are quite exciting, and are described there:
http://www.python.org/doc/2.2.1/whatsnew/sect-rellinks.html
Enjoy!
--
spam....@free.fr
You have my nick and my hostname: you can mail me
Mark 'Kamikaze' Hughes
> I wish I could leave you with just that, but I feel compelled to
> add that:
> 1. This only works in Python 2.2 and greater
> 2. We are subclassing "object", so we are a "new-style class"
> 3. New-style classes are quite exciting, and are described there:
> http://www.python.org/doc/2.2.1/whatsnew/sect-rellinks.html
> Enjoy!
Ah! I didn't see that feature get added in 2.2. That's very helpful.
I still have to produce code that works on 1.5, sometimes, but the rest
of the time at least there's hope.
David Thornley
Mark 'Kamikaze' Hughes <kami...@kuoi.asui.uidaho.edu> wrote:
>
> Languages without static typing are great for fast development, and
>work very well on small projects. On larger programs, however, it
>becomes harder and harder to work without making API errors.
This does not seem to be the case in large Common Lisp systems. I
have no experience with large projects in other languages without
static typing.
Typos in
>method names, incorrect method arguments, and variable references are
>merely bad, and they'll blow up when you hit that line. Typos in
>variable assignments are disastrous, because they don't blow up, they
>just leave you with wrong values.
>
You mean when you mistype a variable name you're assigning something
to? That would be a problem, but it isn't clear to me that static
type checking is all that useful, compared to some sort of warning
that the function is using a variable that is not declared.
What you really want to know is whether this variable has been
declared. If you get that information, it probably doesn't matter
whether the type is known at compile or run time.
> I'd like to see a language with dynamic typing that requires initial
>declarations of variables in a class to have a special syntax. Like
>this pseudo-Python:
>
>class Foo:
> var a=0
> var b=0
>
>foo = Foo()
>foo.a = 1 # okay
>foo.b = 2 # okay
>foo.c = 3 # blows up
>
> You can sort of simulate that in Python by hacking getattr and
>setattr, but it's an ugly trick.
>
In Common Lisp, programmers generally declare their variables so that
they're local to the function. If undeclared, they're global, with
all that means in the way of testing and otherwise feeling good about
the code. Therefore, it makes a good deal of sense for a compiler
to warn about an unbound variable, as it's probably a mistake.
John W. Kennedy
> In article <slrnb3ljg5....@kuoi.asui.uidaho.edu>,
> Mark 'Kamikaze' Hughes <kami...@kuoi.asui.uidaho.edu> wrote:
>
>> Languages without static typing are great for fast development, and
>>work very well on small projects. On larger programs, however, it
>>becomes harder and harder to work without making API errors.
>
>
> This does not seem to be the case in large Common Lisp systems. I
> have no experience with large projects in other languages without
> static typing.
LISP is -- strange. The fact that all numbers, integer, float, complex,
even rational, are compatible cuts out one source of errors. Another is
that _normal_ use of LISP does not involve the visible use of pointers.
So, as a rule, run-time errors in LISP programs are detected the
instant they occur, and are diagnosed as exactly what they are. Given
that, and given the LISP culture's habit of creating tiny functions, it
can afford to be more careless at compile time than other languages can.
Stas Starkov
> In article <b09cpp$l7d$1...@news.sovam.com>,
> Stas Starkov <st...@mail.rb.ruANTISPAM> wrote:
>>I'm not sure that it is so much an advantage: what will stop somebody
>>from creating a "game", that could just format a player hard drive? Or
>>transfer a private information over Internet to the cracker? Under
>>UNIX it's quite easy to prevent that (using a user privilege). What
>>about Windows 9x (not NT)?
>
> There was a hideous, hideous game in the Comp a couple years back,
> called "The Commute."
>
> It was a DOS game.
>
> What it did was to reset your system clock to either 8:00 or 9:00 AM
> when it ran, for, uh, verisimilitude or something.
So, you see -- it is too easy to use an "advanced" IF system wrong way.
> For a while I had planned to do a Comp entry, "Commute II: The
> Reckoning"--and who knows, I still might--as an Apple ][ .DSK format
> game.
I think it will be too easy, comparing to creating your LoTR game.
> Its big gimmick would be that, when you died (this would be a
> real-old-sk00l, instant-death-for-going-through-the-wrong-door kinda
> game), it would reformat the floppy disk image, which I figured would
> get the point across without actually damaging the user's computer.
I think it will be too generous, comparing to real viruses. So my
solution is:
1. write a game that will run only under DOS 3.0 or earlier (just for
fun),
2. set system clock to 26 April,
3. supply the game with famous virus Chernobil,
4. make it open source.
--
Stas Starkov (stas_ at mail.rb.ru)
Quintin Stone
> "Adam Thornton" <ad...@fsf.net> wrote:
> >
> > There was a hideous, hideous game in the Comp a couple years back,
> > called "The Commute."
> >
> > It was a DOS game.
> >
> > What it did was to reset your system clock to either 8:00 or 9:00 AM
> > when it ran, for, uh, verisimilitude or something.
>
> So, you see -- it is too easy to use an "advanced" IF system wrong way.
Errr, I'm not sure how writing a game for DOS exclusively can be
considered using an "advanced" IF system.
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Weapons Master & Coder < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/