Inform
bogus6...@mailinator.com
its own) really like?
vaporware
> What is Inform _stripped of its libraries_ (so that I can view it on
> its own) really like?
Like this (Inform 6):
[ Main; print "Hello, world!^"; ];
vw
bogus6...@mailinator.com
What's the caret? A carriage return?
So: is Inform really like C? Why not just write adventure games in C?
Instead of Inform libraries, just have C libraries. Why not? Really,
why not?
Andrew Plotkin
Good idea! Please write it and get back to us.
PS: I bet there's a manual somewhere which describes the Inform
language without its libraries. Maybe even online somewhere.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation,
it's for one reason: they don't feel like it. Not because you're patriotic.
vaporware
> vaporware wrote:
> > bogus6...@mailinator.com wrote:
> > > What is Inform _stripped of its libraries_ (so that I can view it on
> > > its own) really like?
> >
> > Like this (Inform 6):
> >
> > [ Main; print "Hello, world!^"; ];
> >
> > vw
>
> What's the caret? A carriage return?
Yes.
> So: is Inform really like C?
To an extent. It grew out of a Z-machine assembler, IIRC, which has
influenced its current form: there's no type checking, and you can use
assembly opcodes inline. It also has object-oriented features not found
in C, and an object model unlike that of C++ or Java (to match the
Z-machine's underlying object model).
> Why not just write adventure games in C?
> Instead of Inform libraries, just have C libraries. Why not? Really,
> why not?
One reason is that, for historic and portability reasons, a lot of
people like to play IF with a Z-machine interpreter. There is, however,
a C compiler that targets the Z-machine. If you'd like to write a C
library for IF, and use static initializers or macros or whatever to
define your objects, no one will stop you. Good luck!
vw
Jim Aikin
news:1159060811.8...@k70g2000cwa.googlegroups.com...
>
> So: is Inform really like C? Why not just write adventure games in C?
> Instead of Inform libraries, just have C libraries. Why not? Really,
> why not?
Since nobody else has yet answered your question in a serious way (Andrew's
tongue was planted firmly in his cheek), I'll take it on.
The real answer is, you could indeed write your own IF from the ground up in
C, in Java, or basically in any modern general-purpose programming language.
But if you try it, you'll spend MONTHS solving nitpicky little problems that
have been handled for you, more or less elegantly, in specialized IF
languages like Inform, TADS, and Hugo.
By using an existing IF language, you can end up with a very functional game
in a tiny fraction of the time it would take you if you did it from scratch.
The stuff that has been done for you includes...
The parser, which slices the player's text input apart, compares it against
entries in a dictionary, and decides what objects the player is referring
to.
The cross-platform interpreter, which will enable your game to be played
(and look decent) on a bunch of computer OSes, including some that you've
probably never even heard of.
The compiler, which is capable of understanding syntax that is optimized for
IF. For example, in Inform 6, TADS 2, and probably most other IF languages
(I'm not an expert), all of the code for a game object such as a brass
lantern can be typed in one coherent block. In C++, by contrast, you have to
declare an object at the head of the file (in a header) so that the other
objects will know what its public members are, and then put the actual code
for the object in a different place. Maintaining an IF world model in a C++
environment is thus guaranteed to be more work. Now multiply that level of
coding complexity by a factor of five or six.
Still want to try it? If so, you might want to download the publicly
available source code for the Inform 6 and TADS parser and library and see
what sorts of hoops Graham and Mike and the other developers have leaped
through over the years. Lion tamers ain't got nothin' on these guys.
Even if you DO end up writing your own IF engine in C, you'd be well advised
to try writing a game in an existing language first. By doing so, you'll
gain an appreciation for the things that can go wrong when the parser
doesn't understand the player's intentions.
--Jim Aikin
Stebbins
> So: is Inform really like C?
No.
Or I guess you could say that it like C more than it is like, say,
BASIC, or Lisp.
> Why not just write adventure games in C?
> Instead of Inform libraries, just have C libraries. Why not? Really,
> why not?
Hmm, both C and Inform have libraries. Therefore, they must both be
great for writing IF! I'm sure writing a parser in C would be no
problem at all. You should have brought this up 13 years ago. You
could have saved Graham Nelson an awful lot of trouble.
vaporware
I think Mr. Bogus's question is about the advantages of using Inform
and its library instead of some hypothetical IF library written in C.
Writing a parser on the scale of Inform's is a massive undertaking, but
it wouldn't really be any harder in C. Actually using it, however,
would be more difficult, because C's syntax isn't very good for
declaring a world full of objects which freely mix code with static
data - an object in Inform is quite different from a struct value in C
or an instance of a C++ class.
vw
bogus6...@mailinator.com
> I think Mr. Bogus's question is about the advantages of using Inform
> and its library instead of some hypothetical IF library written in C.
>
> Writing a parser on the scale of Inform's is a massive undertaking, but
> it wouldn't really be any harder in C. Actually using it, however,
> would be more difficult, because C's syntax isn't very good for
> declaring a world full of objects which freely mix code with static
> data - an object in Inform is quite different from a struct value in C
> or an instance of a C++ class.
Here are two issues I hate:
Issue #1:
>GET HAMSTER
Which do you mean, the hamster or the bag of hamster food?
For the love of ramen noodles, why was this not fixed a long time ago?
(Or was it fixed and I'm not aware of it?)
Issue #2:
>OPEN DRAWER
Opening the drawer reveals a McGuffin.
>GET ALL
(yadda yadda)
>I
You are carrying (various items, NOT including the McGuffin).
Neil Cerutti
On 2006-09-24, vaporware <jmc...@gmail.com> wrote:
>> Why not just write adventure games in C? Instead of Inform
>> libraries, just have C libraries. Why not? Really, why not?
>
> One reason is that, for historic and portability reasons, a lot
> of people like to play IF with a Z-machine interpreter. There
> is, however, a C compiler that targets the Z-machine. If you'd
> like to write a C library for IF, and use static initializers
> or macros or whatever to define your objects, no one will stop
> you. Good luck!
I haven't looked at the C compiler, but probably it will need to
be hacked to allow compilation of arbitrary Z-code instructions.
Standard C most likely doesn't allow that, and you'll definitely
need this capability to write the next part.
The next thing to do will be to write a C library to interface
with the various Z-machine data objects, e.g., Z-strings,
dictionaries, and so on, using Z-code.
Then write a library containing an extensible and modifiable
parser and world model.
Now write an example game. A port of Collosal Cave or Dungeon is
probably a good bet if you aren't feeling creative enough to
write an original game.
Finally, document how this thing works, and release it into the
if archive.
It'll be weird writing C with no malloc.
--
Neil Cerutti
fel...@yahoo.com
> Here are two issues I hate:
>
> Issue #1:
> >GET HAMSTER
> Which do you mean, the hamster or the bag of hamster food?
>
> For the love of ramen noodles, why was this not fixed a long time ago?
> (Or was it fixed and I'm not aware of it?)
Actually, it was, at least in TADS, Platypus and (IIRC) Hugo. But you
didn't read the manuals, did you? Because In that case, you really
shouldn't be questioning the use of these languages/libraries.
Felix
Neil Cerutti
>
>> I think Mr. Bogus's question is about the advantages of using Inform
>> and its library instead of some hypothetical IF library written in C.
>>
>> Writing a parser on the scale of Inform's is a massive undertaking, but
>> it wouldn't really be any harder in C. Actually using it, however,
>> would be more difficult, because C's syntax isn't very good for
>> declaring a world full of objects which freely mix code with static
>> data - an object in Inform is quite different from a struct value in C
>> or an instance of a C++ class.
>
> Here are two issues I hate:
>
> Issue #1:
>>GET HAMSTER
> Which do you mean, the hamster or the bag of hamster food?
>
> For the love of ramen noodles, why was this not fixed a long
> time ago? (Or was it fixed and I'm not aware of it?)
Graham thought that Infocom (and most other IF programming
language) 'adjective' construct was not necessary. I disagree
with him on that, too. They are not terribly difficult to add to
Inform, functioning in the following way:
>GET HAMSTER
(the hamster)
Taken.
Personally, the parenthetical aside bothers me, but that's really
a nitpick.
> Issue #2:
>>OPEN DRAWER
> Opening the drawer reveals a McGuffin.
>>GET ALL
> (yadda yadda)
>>I
> You are carrying (various items, NOT including the McGuffin).
Check out the ChooseObjects entry point routine for a solution
(at least, I think that'll work). Inform has an algorithm that
decides which objects are included in 'all', but you can easily
override it.
--
Neil Cerutti
vaporware
I look forward to seeing these fixed in your C library for IF.
vw
Stebbins
vaporware wrote:
> I think Mr. Bogus's question is about the advantages of using Inform
> and its library instead of some hypothetical IF library written in C.
>
> Writing a parser on the scale of Inform's is a massive undertaking, but
> it wouldn't really be any harder in C. Actually using it, however,
> would be more difficult, because C's syntax isn't very good for
> declaring a world full of objects which freely mix code with static
> data - an object in Inform is quite different from a struct value in C
> or an instance of a C++ class.
>
> vw
Yes, I agree. My only point is: C has been around longer than TADS or
Inform. If writing IF in C were as simple as Bogus seems to think it
is, people probably wouldn't have developed special IF languages in the
first place. Or at least we'd still see a lot of people using C.
The tone of Bogus's posts makes me believe he isn't asking a serious
question. Rather, he's trying to attack Inform even though he really
doesn't know anything about it.
CobraA1
Neil Cerutti
> I wonder if Java would be a good language for such a thing?
Java is an excellent language for writing an Inform compiler.
--
Neil Cerutti
Poster
Ok, let me get this one straight. You find two things about Inform that
you don't like, and your solution is to whip up a whole new set of
libraries in another language?
That is silly, and you are a troll. *plonk*
-- Poster
www.intaligo.com Building, INFORM, Seasons (upcoming!)
solu...@gmail.com
whether the author chooses to.
Excessus
> Here are two issues I hate:
I'm new to this IF world, because just recently I found the wonderful
Inform 7 which I am using to produce a wonderful game without knowing
how to code. That's great! In some months my game will be hopefully
finished and you will be able to download it --or-- click your way out
of the download link :) But ever since the first day I have found all
your messages to be extremely Inform-bashing. The good news are that
Inform is optional! You dont have to talk about it, you dont have to
use it, you dont have to come here if you doesnt want :)
I hope you feel better now :)
-- Ex
Neil Cerutti
> Yes, I agree. My only point is: C has been around longer than
> TADS or Inform. If writing IF in C were as simple as Bogus
> seems to think it is, people probably wouldn't have developed
> special IF languages in the first place. Or at least we'd
> still see a lot of people using C.
Yes. Finally, if you were going to write a reusable IF system in
C, eventually you'd end up deciding that making it into a
compiler+VM solution would be the best way to make it simple to
use and maximally portable. Natch!
> The tone of Bogus's posts makes me believe he isn't asking a
> serious question. Rather, he's trying to attack Inform even
> though he really doesn't know anything about it.
That's quite possible.
--
Neil Cerutti
After finding no qualified candidates for the position of
principal, the school board is pleased to announce the
appointment of David Steele to the post. --Philip Streifer
Richard Bos
> ["Followup-To:" header set to rec.arts.int-fiction.]
> On 2006-09-24, vaporware <jmc...@gmail.com> wrote:
> >> Why not just write adventure games in C? Instead of Inform
> >> libraries, just have C libraries. Why not? Really, why not?
> >
> > One reason is that, for historic and portability reasons, a lot
> > of people like to play IF with a Z-machine interpreter. There
> > is, however, a C compiler that targets the Z-machine. If you'd
> > like to write a C library for IF, and use static initializers
> > or macros or whatever to define your objects, no one will stop
> > you. Good luck!
>
> I haven't looked at the C compiler, but probably it will need to
> be hacked to allow compilation of arbitrary Z-code instructions.
> Standard C most likely doesn't allow that, and you'll definitely
> need this capability to write the next part.
Not necessarily. A C library, or any library to be used with a C
compiler, does not itself have to be written in C, or compiled with the
same compiler. You could hand-write the libraries, and let the C
compiler just compiler purely C user code with calls to your library.
> It'll be weird writing C with no malloc.
Yup. Of course, you _could_ fake malloc(), but it probably won't be
worth the trouble.
Richard
vaporware
It wouldn't really be fake. The Z-machine has a limited amount of RAM,
but so does any PC - the Z-machine just has a lower limit. You can have
a real malloc(), although it'll be limited to a sub-64k heap size. In
fact, there's already a malloc() implementation for Inform, called
dynmem.h.
vw
Neil Cerutti
> Neil Cerutti <hor...@yahoo.com> wrote:
>
>> ["Followup-To:" header set to rec.arts.int-fiction.]
>> On 2006-09-24, vaporware <jmc...@gmail.com> wrote:
>> I haven't looked at the C compiler, but probably it will need
>> to be hacked to allow compilation of arbitrary Z-code
>> instructions. Standard C most likely doesn't allow that, and
>> you'll definitely need this capability to write the next part.
>
> Not necessarily. A C library, or any library to be used with a
> C compiler, does not itself have to be written in C, or
> compiled with the same compiler. You could hand-write the
> libraries, and let the C compiler just compiler purely C user
> code with calls to your library.
That's when I meant to say, actually. A library of z-code,
callable from C, will need to be written. It might be that vbcc
has got that already. I couldn't figure out the right way to
invoke 'patch' to build the zvbcc sources correctly. My last
attempt ended with no machine/z/ directory or files therein.
>> It'll be weird writing C with no malloc.
>
> Yup. Of course, you _could_ fake malloc(), but it probably
> won't be worth the trouble.
I wrote a malloc in Inform (there's a simple one in K&R C that I
ported). The compiler could be set up to take whatever dynamic
memory is leftover and set it as malloc's memory pool.
At the time Graham wrote Z-spec 1.0, apparently nobody had ever
hit their head on the 64K dynamic memory limit. Since then, it's
happened to quite a fe people. So the latest Inform Designer's
Manual contains a section on hacking around the limitation.
Times change quickly, eh?
--
Neil Cerutti