Re: Developer's Question: Which Tool?
David Fisher
news:dq3lg1$blm$1...@ss405.t-com.hr...
> On 2006-01-11 00:37:26 +0100, "David Fisher" <da...@hsa.com.au> said:
>
>> There is a useful comparison of popular IF languages at
>> http://www.firthworks.com/roger/cloak/index.html
>
> I really enjoyed examining the comparison of various languages. I find
> them all to be rather odious, unfortunately. Most of them seem to try to
> be both C and Lisp at the same time. As a result, they capture none of the
> beauty of one nor the effectiveness of the other. Determining which of the
> two is beautiful and which effective is left as an exercise for the
> reader. :-)
Could you describe what your ideal IF language might look like ?
BTW, your statement reminded me of a quote about C: "C is a medium-level
language combining the power of assembly language with the readability of
assembly language" :-)
David Fisher
(Follow-up set to rec.arts.int-fiction)
richard develyn
IF language, and the approach I took then was to build a pre-processor
in front of C. TADS3 is 'C' / C++ like, but not as well thought out (as
you would expect) and somewhat based around the author's particular
programming style.
My ideal IF language would be an extension to a mainstream language,
probably Java or maybe something like Ruby.
Richard
Ivan Stojic
> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> news:dq3lg1$blm$1...@ss405.t-com.hr...
>> On 2006-01-11 00:37:26 +0100, "David Fisher" <da...@hsa.com.au> said:
>>
>>> There is a useful comparison of popular IF languages at
>>> http://www.firthworks.com/roger/cloak/index.html
>>
>> I really enjoyed examining the comparison of various languages. I find
>> them all to be rather odious, unfortunately. Most of them seem to try
>> to be both C and Lisp at the same time. As a result, they capture none
>> of the beauty of one nor the effectiveness of the other. Determining
>> which of the two is beautiful and which effective is left as an
>> exercise for the reader. :-)
>
> Could you describe what your ideal IF language might look like ?
Hm... now we're threading of soft ground. I am going to start by saying
that I'm just learning about Inform right now and I've also been poking
around TADS, Hugo and ALAN. Here's a list of thiings that are confusing
to me, and then, after a while, a list of properties that I think a
modern IF language should have:
My first reaction to Inform was "oh, cool!" That was while I was
reading the first few chapters of the Designer's manual, all was well.
After the start of the Ruins came into light I could say that I
understood the programming language.
Then several new (language?) constructs appear and my understanding
dies a quick and painful death. There's the whole before [; SomeAction:
... ]; thing. The syntax is confusing. It looks like a routine but it's
actually an object property. And routines themselves are objects.
That's somehow cool and smells of Python. But then, what's with the
(string) casting silliness. A language as simple as Inform shouldn't
need to worry about these things. I believe that the problems of Inform
are somehow rooted in the design of the Z-Code backend. I'm seriousely
looking forward to reading more about it!
As far as TADS and Hugo are concerned my knowledge is even smaller.
I've studied the code to the Cloak of Darkness in both systems. What
strikes me as seriousely odd is the fact that both of these languages
are seriousely uninspired. Why are you trying to emulate C preprocessor
directives in both TADS and Hugo? Sticking hashes in front of keywords
isn't going to make me feel any better about writing them, particularly
when they no longer represent the same concepts that they did in C.
Then again, there are some things which have become so ingrained in
programmers today that it seems strange to find the rules have shifted.
It may be that I've learned wrong rules. Hey Hugo: why is the
exclamation mark still used to comment to the end of line? As a
consequence, you write not-equal as ~= which makes my C++, Java and
Python trained brain twich. Why are languages being so messed up with
grammar rules? I'm never sure if I need to end my statement without
anything tagged onto the end, with a colon or a comma. I can only
imagine that writing a parser for any one of these programming
languages is a pain.
ALAN got me interested. I think it's very clean implementation. I'll
definitely be working with it more often in future, if nothing else,
then to see if it's as good as I think it is.
I could probably go on for hours. The sad point is that there is no
perfect programming language. There isn't one when we're talking about
general programming tasks, and there isn't one that satisfies
everyone's needs for IF development. First off, I thought that I want a
well known language adapted to IF usage. After thinking about it, I
know that's a crappy idea. However, some of the stranger programming
languages might be worth examining for ideas: Forth, Prolog and
Smalltalk come to mind.
Basically, I'd want the language to be:
- Essentially it should be an imperative, object oriented language. I
want the concept of class versus instance. I want inheritance,
polymorphism, closures and such. It should have a clean and easy syntax
comparable to modern general purpose programming languages.
- It doesn't need graphics, sound or rich formatting as far as I'm
concerned, but I do want the input file to be parsed as an UTF file.
Typing @:o to get an umlaut in the 21st century is seriousely wrong.
- The library should be closely integrated with the language itself. I
don't need the library to be editable, I need it to be extendable and
overridable.
- I want to have identically or close to identically feature rich
interpreters/runners for the game for at least these three platforms:
Windows, Mac OS (8, 9 and X versions. No Classic allowed for OS X
version), and a Java runner which can be used standalone or as an
applet.
That's it. Now fire away and kill me dead. I know that I'm not happy
with what we have right now, even to the point where I'd write a new IF
language/system just for the kicks of it if I could find some active
users and authors :-)
Sincerely yours,
Ivan
David Fisher
> On 2006-01-11 23:54:08 +0100, "David Fisher" <da...@hsa.com.au> said:
>>
>> Could you describe what your ideal IF language might look like ?
>
> My first reaction to Inform was "oh, cool!" That was while I was reading
> the first few chapters of the Designer's manual, all was well. After the
> start of the Ruins came into light I could say that I understood the
> programming language.
>
> Then several new (language?) constructs appear and my understanding dies a
> quick and painful death. There's the whole before [; SomeAction: ... ];
> thing. The syntax is confusing. It looks like a routine but it's actually
> an object property. And routines themselves are objects.
Might be more accurate to say that a property (of an object or class) can be
a routine.
> That's somehow cool and smells of Python. But then, what's with the
> (string) casting silliness.
Hmmm, a definite disadvantage of Inform is having to keep track of the type
of everything yourself ... it feels more a "type hiding" than "typeless"
language, since there really are different types (strings, numbers, boolean
flags, etc) but there are no (compile time) checks to see if you are using a
variable the right way or not.
...
> As far as TADS and Hugo are concerned my knowledge is even smaller. I've
> studied the code to the Cloak of Darkness in both systems.
Being a programmer-type, you might also want to have a look at TADS 3 - it
has a different approach again: http://www.tads.org/t3dl.htm
...
> ALAN got me interested. I think it's very clean implementation. I'll
> definitely be working with it more often in future, if nothing else, then
> to see if it's as good as I think it is.
I haven't tried Alan, but I have read that it is a bit hard to stretch it
beyond its normal limits.
Take a look at this page for some past discussions on this news group about
various authoring systems:
http://www.ifwiki.org/index.php/Past_raif_topics%3A_Development%3A_part_1
> ... some of the stranger programming languages might be worth
> examining for ideas: Forth, Prolog and Smalltalk come to mind.
... further down the above mentioned page:
David Fisher
ready, so here is part 2) ...
> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> news:dq6jrl$pnp$1...@ss405.t-com.hr...
> As far as TADS and Hugo are concerned my knowledge is even smaller. I've
> studied the code to the Cloak of Darkness in both systems.
Being a programmer-type, you might also want to have a look at TADS 3 - it
has a different approach again: http://www.tads.org/t3dl.htm
...
> ALAN got me interested. I think it's very clean implementation. I'll
> definitely be working with it more often in future, if nothing else, then
> to see if it's as good as I think it is.
I haven't tried Alan, but I have read that it is a bit hard to stretch it
beyond its normal limits.
Take a look at this page for some past discussions on this news group about
various authoring systems:
http://www.ifwiki.org/index.php/Past_raif_topics%3A_Development%3A_part_1
> ... some of the stranger programming languages might be worth
> examining for ideas: Forth, Prolog and Smalltalk come to mind.
... further down the above mentioned page:
> - Essentially it should be an imperative, object oriented language. I want
> the concept of class versus instance. I want inheritance, polymorphism,
> closures and such. It should have a clean and easy syntax comparable to
> modern general purpose programming languages.
TADS and Inform both have object oriented facilities (if you haven't
discovered them yet).
Which (programming) language's syntax do you like ?
> - The library should be closely integrated with the language itself. I
> don't need the library to be editable, I need it to be extendable and
> overridable.
The libraries for both TADS and Inform (don't know about any others) have
been deliberately written to be extendible and / or overridable, and there
was a choice in both systems to expose the parser to the programmer (rather
than making it part of the interpreter and hiding its implementation).
> - I want to have identically or close to identically feature rich
> interpreters/runners for the game for at least these three platforms:
> Windows, Mac OS (8, 9 and X versions. No Classic allowed for OS X
> version), and a Java runner which can be used standalone or as an applet.
All imaginable platforms are already supported (one of my main motivations
for sticking to an existing language - or at least to target an existing
machine code: Z Code, Glulx or TADS2/T3 - if I ever design a new IF
language).
> That's it. Now fire away and kill me dead. I know that I'm not happy with
> what we have right now, even to the point where I'd write a new IF
> language/system just for the kicks of it if I could find some active users
> and authors :-)
I would recommend reading those past RAIF topics about designing a new
authoring system before heading too far in that direction - not to doubt
your ability, but there are major complications :-)
David Fisher
Kevin Venzke
> What strikes me as seriousely odd is the fact that both of these languages are
> seriousely uninspired. Why are you trying to emulate C preprocessor directives
> in both TADS and Hugo? Sticking hashes in front of keywords isn't going to
> make me feel any better about writing them, particularly when they no longer
> represent the same concepts that they did in C.
Do you have trouble feeling good about using preprocessor directives?
> Then again, there are some things which have become so ingrained in
> programmers today that it seems strange to find the rules have shifted. It may
> be that I've learned wrong rules. Hey Hugo: why is the exclamation mark still
> used to comment to the end of line? As a consequence, you write not-equal as
> ~= which makes my C++, Java and Python trained brain twich.
I like <> . It is easier to type.
> Why are languages being so messed up with grammar rules? I'm never sure if I
> need to end my statement without anything tagged onto the end, with a colon or
> a comma. I can only imagine that writing a parser for any one of these
> programming languages is a pain.
What do you mean by this? In TADS 2, statements always end
in a semicolon. (So do object definitions.) If it's not a statement
or object definition, no semicolon:
startroom: room
sdesc = "Start Room" //not a statement
ldesc = {
if(self.onfire) //not a statement
"The room is on fire! ";
else //not a statement
"This room is not on fire. ";
}
; //end of object definition
> Basically, I'd want the language to be:
>
> - The library should be closely integrated with the language itself. I don't
> need the library to be editable, I need it to be extendable and overridable.
What are you going to gain by having a non-editable library?
> That's it. Now fire away and kill me dead. I know that I'm not happy with what
> we have right now, even to the point where I'd write a new IF language/system
> just for the kicks of it if I could find some active users and authors :-)
It sounds like your complaints are about punctuation. So just write
a program that translates your preferred punctuation scheme into
Inform or TADS source. That would be easy, and it would be useful
to you even if no one else wanted to use it.
Kevin Venzke
Timofei Shatrov
tried to confuse everyone with this message:
>On 2006-01-11 23:54:08 +0100, "David Fisher" <da...@hsa.com.au> said:
>
>> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
>> news:dq3lg1$blm$1...@ss405.t-com.hr...
>>> On 2006-01-11 00:37:26 +0100, "David Fisher" <da...@hsa.com.au> said:
>>>
>>>> There is a useful comparison of popular IF languages at
>>>> http://www.firthworks.com/roger/cloak/index.html
>>>
>>> I really enjoyed examining the comparison of various languages. I find
>>> them all to be rather odious, unfortunately. Most of them seem to try
>>> to be both C and Lisp at the same time.
Writing IF in Lisp may be a reality in the near future ;)
>>> As a result, they capture none
>>> of the beauty of one nor the effectiveness of the other. Determining
>>> which of the two is beautiful and which effective is left as an
>>> exercise for the reader. :-)
>>
>> Could you describe what your ideal IF language might look like ?
>
>Hm... now we're threading of soft ground. I am going to start by saying
>that I'm just learning about Inform right now and I've also been poking
>around TADS, Hugo and ALAN. Here's a list of thiings that are confusing
>to me, and then, after a while, a list of properties that I think a
>modern IF language should have:
>
>My first reaction to Inform was "oh, cool!" That was while I was
>reading the first few chapters of the Designer's manual, all was well.
>After the start of the Ruins came into light I could say that I
>understood the programming language.
>
>Then several new (language?) constructs appear and my understanding
>dies a quick and painful death. There's the whole before [; SomeAction:
>... ]; thing. The syntax is confusing. It looks like a routine but it's
>actually an object property.
What's wrong with functions as object properties? How else would you
implement before? The autoswitch thing may be confusing, but you always
can write this switch yourself instead.
> And routines themselves are objects.
>That's somehow cool and smells of Python. But then, what's with the
>(string) casting silliness. A language as simple as Inform shouldn't
>need to worry about these things. I believe that the problems of Inform
>are somehow rooted in the design of the Z-Code backend.
Well, it's better than some languages where you actually have to declare
the type of each variable. But yes, the implementation of strings in
Inform is closely tied to the way they're stored in Z-machine.
<snip about other languages>
>Basically, I'd want the language to be:
>
>- Essentially it should be an imperative, object oriented language. I
>want the concept of class versus instance. I want inheritance,
>polymorphism, closures and such. It should have a clean and easy syntax
>comparable to modern general purpose programming languages.
Well, my lIFp library would certainly feature all of the above :)
>- It doesn't need graphics, sound or rich formatting as far as I'm
>concerned, but I do want the input file to be parsed as an UTF file.
>Typing @:o to get an umlaut in the 21st century is seriousely wrong.
No, it's not. I don't know about you, but my keyboard doesn't have
umlaut o, so typing @:o is easier for me.
>- The library should be closely integrated with the language itself. I
>don't need the library to be editable, I need it to be extendable and
>overridable.
That's what you get in any IF language.
>- I want to have identically or close to identically feature rich
>interpreters/runners for the game for at least these three platforms:
>Windows, Mac OS (8, 9 and X versions. No Classic allowed for OS X
>version), and a Java runner which can be used standalone or as an
>applet.
Hmm, Java applet for lIFp may be beyond me...
--
|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
| m"a ||FC AMKAR PERM|| mail: grue at mail.ru http://grue3.tripod.com |
| k || PWNZ J00 || Kingdom of Loathing: Grue3 lvl 18 Seal Clubber |
`-----'`-------------'`-------------------------------------------[4*72]
Nick.B...@gmail.com
yourself in the foot with it.
Of course, C++ gives you a nuclear missle.....
In anycase, having played around with a few of the languages myself, I
don't think the comparison to C and Lisp is particularly there. Sure,
there are features of both that can be seen in these languages but
thats probably more due to a desire to stay within comfort zones and
build on what has come before rather than an attempt to replicate
either language. Remember, these languages are designed primarily for
IF and all of them, to a lesser or greater degree, implement a lot of
features to support that and leave out a lot of features you might be
used to that arn't as useful.
One coder to another, you're unlikely to find an IF language that feels
as good to you coding as your personal language of choice at the
moment. The only way you'll do that is to actually program -in- your
personal language of choice - which many people have done. Keep in mind
that you would then be required to implement a parser and language
library - which is all provided very well and modern by the main
languages used today. That feature alone makes up for superficial
shortcomings of the language itself - in my humble opinion.
Samwyse
> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> news:dq6jrl$pnp$1...@ss405.t-com.hr...
>
>>quick and painful death. There's the whole before [; SomeAction: ... ];
>>thing. The syntax is confusing. It looks like a routine but it's actually
>>an object property. And routines themselves are objects.
>
> Might be more accurate to say that a property (of an object or class) can be
> a routine.
I suspect that Ivan is referring to the fact that Inform lets you do
this sort of stuff:
x = some_function;
y = x.call();
x = "hello world";
x.print();
Methinks that Graham probably went a bit overboard when he added
object-oriented features to Inform.
BTW, it took me a while to wrap my head around the differences in the
way that routines get named inside vs outside of objects:
hello_property [ ; "hello, world!"; ],
versus
[ hello_routine ; "hello, world!"; ];
Samwyse
> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> news:dq6jrl$pnp$1...@ss405.t-com.hr...
>
>>What strikes me as seriousely odd is the fact that both of these languages are
>>seriousely uninspired. Why are you trying to emulate C preprocessor directives
>>in both TADS and Hugo? Sticking hashes in front of keywords isn't going to
>>make me feel any better about writing them, particularly when they no longer
>>represent the same concepts that they did in C.
>
>
> Do you have trouble feeling good about using preprocessor directives?
I can't speak about TADS or Hugo, but Inform does this as well.
Unfortunately, "#If" and all it's friends aren't implemented in a
preprocessor, which gives them all sorts of quirks as compared to a true
preprocessor. In fact, in Inform the hash marks are frequently optional.
Neil Cerutti
> David Fisher wrote:
>> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
>> news:dq6jrl$pnp$1...@ss405.t-com.hr...
>>
>>>Then several new (language?) constructs appear and my
>>>understanding dies a quick and painful death. There's the
>>>whole before [; SomeAction: ... ]; thing. The syntax is
>>>confusing. It looks like a routine but it's actually an object
>>>property. And routines themselves are objects.
>>
>> Might be more accurate to say that a property (of an object or
>> class) can be a routine.
Yup.
> I suspect that Ivan is referring to the fact that Inform lets you do
> this sort of stuff:
> x = some_function;
> y = x.call();
> x = "hello world";
> x.print();
>
> Methinks that Graham probably went a bit overboard when he
> added object-oriented features to Inform.
I don't think that was the particular confusion. Inform isn't
much different than Perl in the way its type system works; I
think it's neat. It is most useful in the standard library
properties when, e.g, short_name may be a string or a routine.
> BTW, it took me a while to wrap my head around the differences
> in the way that routines get named inside vs outside of
> objects:
> hello_property [ ; "hello, world!"; ],
> versus
> [ hello_routine ; "hello, world!"; ];
That's a seemingly gratuitous difference in notation. But I think
the following just looks "wrong":
Object Snort
has animate
with
name 'snort',
description "It's not your mommy, it's a snort!",
[ before;
"Snort!";
],
;
Compared to this:
Object Snort "Snort"
has animate
with
name 'snort',
description "It's not your mommy, it's a snort!",
before [;
"Snort!";
],
;
In other words, the definition of property routines is
inconsistent with the definition of file-scope routines, but it's
consistent with the definition of other properties. File-scope
routines could not be declared the same way, probably due to
parsing problems at file scope between object definitions and
routine declarations. But maybe it was an unhappy accident.
I found the Inform object declaration syntax to be hard to learn,
but it *looks* very nice once it's been written. It's hard to
write syntactically correct Inform objects without a lot of
practice, but they are easy to scan, since syntactic cruft is at
a minimum. I think authors eventually appreciate the terse
notation.
One yucky part of Inform are arrays. I wish Graham had restrained
himself from providing access to so many different kinds, and
with such eccentric syntax. I suppose the z-machine demanded, but
what a confusion. Are the same gaggle of constructs available
explicitly in ZIL?
But language design is hard. Even teams of academics make
mistakes in language design. Ocaml's block-comment syntax (*
comment *) may seem like a big step up from /* */ until you try
to de-infix *, with (*). And then there's C++'s attempt to nest
angle-brackets in templates: vector<list<int>>. In the same way,
Graham chose [ ] as delimiters for function blocks, and was thus
stuck without using them for array indexing.
Incidentally, anyone interested in IF language design could start
(and possibly finish) with an Inform or TADS pre-processor. Want
to make it more like Python? More like C? Have it at! No parser
or world-model building necessary.
--
Neil Cerutti
samwyse
Neil Cerutti wrote:
> On 2006-01-13, Samwyse <sam...@gmail.com> wrote:
> > David Fisher wrote:
> >> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> >> news:dq6jrl$pnp$1...@ss405.t-com.hr...
> >>> And routines themselves are objects.
I'd say that's a pretty definite reference to the section of DM4 that
talks about Metaclasses. GN himself says, at the top of page 49, "And
although you almost never need to know or care, routines as in §1 are
internally considered as a kind of object, of class Routine; while
strings in double-quotes are likewise of class String."
> >> Might be more accurate to say that a property (of an object or
> >> class) can be a routine.
>
> Yup.
That's very true, but it's not what is being talked about. Unless Ivan
says that he mistyped something, the fact that what he said matches the
above quote is, IMHO, pretty strong evidence concerning his intent.
Unhappy accident. Inform version 1 was an assembly language. Each
subsequent version turned it a bit more into a high-level language, but
a desire to maintain some degree of compatibility with previous version
led to a bunch of odd syntax rules. The fact that you can say either
of these:
Constant a_number 10;
Constant a_string "hello";
means that you should be able to say this as well:
Constant a_routine [ ; "snort!"; ];
Inform may even let you do that, but if it doesn't it would be a
trivial patch; you just recognize this syntax: statement ::=
"Constant" name ["="] property_value ";"
(Of course, 'self' might get mangled, but it's implementation is a bit
of a hack anyway.)
> One yucky part of Inform are arrays. I wish Graham had restrained
> himself from providing access to so many different kinds, and
> with such eccentric syntax. I suppose the z-machine demanded, but
> what a confusion. Are the same gaggle of constructs available
> explicitly in ZIL?
I've not looked that closely at ZIL, but the entire -> versus --> is
rooted in the way the Z-machine works; it has two separate addressing
modes for one-byte and two-byte indexing operations, so the Inform
syntax has reflected that going back to the assemebler days.
Default User
> Hahaha that's pretty much true. C gives you a gun and lets you shoot
> yourself in the foot with it.
I've never liked this analogy, because it doesn't really reflect the
nature of C. A better one would be, "C gives a power saw with a number
of different blades, which work amazingly well if you are very careful
and know what you are doing, but lets you cut your hand off if you
don't.
> Of course, C++ gives you a nuclear missle.....
I don't even understand this. C++ has more safety features than C and
it certainly isn't more powerful in any meaningful sense.
Brian
--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Mr & Jozo
>> - Essentially it should be an imperative, object oriented language. I
>> want the concept of class versus instance. I want inheritance,
>> polymorphism, closures and such. It should have a clean and easy syntax
>> comparable to modern general purpose programming languages.
>
> TADS and Inform both have object oriented facilities (if you haven't
> discovered them yet).
>
> Which (programming) language's syntax do you like ?
I like Java, but that's beside the point. I don't want the language to
be a clone of something else. I don't want the language to try to be
something else. I want it to express what it's made for: interactive
fiction creativity.
> I would recommend reading those past RAIF topics about designing a new
> authoring system before heading too far in that direction - not to
> doubt your ability, but there are major complications :-)
Somehow I believe that we've gotten seriousely off track.
I'm not saying "hey, I'll write a new IF language because all of the
current ones suck dead bats." I'm merely saying that they all feel
inconsistent. Possibly it's because they aren't even programming
languages - they are expert systems :-)
Ivan Stojic
Ivan Stojic
Thanks! I thought I was the only one seeing this :-)
Ivan Stojic
> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> news:dq6jrl$pnp$1...@ss405.t-com.hr...
>> What strikes me as seriousely odd is the fact that both of these
>> languages are seriousely uninspired. Why are you trying to emulate C
>> preprocessor directives in both TADS and Hugo? Sticking hashes in front
>> of keywords isn't going to make me feel any better about writing them,
>> particularly when they no longer represent the same concepts that they
>> did in C.
>
> Do you have trouble feeling good about using preprocessor directives?
Not at all. However, TADS (and I'm pretty sure that it's valid for Hugo
as well) doesn't have a traditional preprocessor. It's "preprocessor"
is embedded into the compiler, so you can't really call it a
preprocessor.
The #include is parsed and executed by the compiler and calling it
"#include" instead of "include" doesn't really have any syntactic
value. The hash in front is just a lump of sugar.
>> Then again, there are some things which have become so ingrained in
>> programmers today that it seems strange to find the rules have shifted.
>> It may be that I've learned wrong rules. Hey Hugo: why is the
>> exclamation mark still used to comment to the end of line? As a
>> consequence, you write not-equal as ~= which makes my C++, Java and
>> Python trained brain twich.
>
> I like <> . It is easier to type.
Yes, but then again, let's think of what <> means. It transfers or
"bounces" execution from one action to another, effectively changing
the state of the game state machine. So, what is (functionally
speaking) the <> operator? It's not a return. It's not a goto either.
It's not a routine call. It looks somewhat like what you get with
coroutines. And then, there's the whole "before/after [;" issue where
you have a whole switch command an an input parameter that you
basically don't see. The language hides it from you for this one
special case.
Sure. <> is easier to type, but behind the simple syntax there's a
whole boatload of things happening that are really complex and that are
only partially visible through the language features.
>> Why are languages being so messed up with grammar rules? I'm never sure
>> if I need to end my statement without anything tagged onto the end,
>> with a colon or a comma. I can only imagine that writing a parser for
>> any one of these programming languages is a pain.
>
> What do you mean by this? In TADS 2, statements always end
> in a semicolon. (So do object definitions.) If it's not a statement
> or object definition, no semicolon:
>
> startroom: room
> sdesc = "Start Room" //not a statement
> ldesc = {
> if(self.onfire) //not a statement
> "The room is on fire! ";
> else //not a statement
> "This room is not on fire. ";
> }
> ; //end of object definition
Here's an exception for you again.
sdesc = "Start Room"
is not a statement, but
"The room is on fire!";
is a statement. Why would self.sdesc = "foo"; written inside the ldesc
routine BE a statement? If it's a statement inside a routine, but not a
statement outside a routine, it's a pretty shifty grammar.
>> Basically, I'd want the language to be:
>>
>> - The library should be closely integrated with the language itself. I
>> don't need the library to be editable, I need it to be extendable and
>> overridable.
>
> What are you going to gain by having a non-editable library?
I'm not going to gain anything by a non editable library per se. I just
don't want to have the need to edit it. It should let me extend it and
control it via "plugin points" where my code can catch events as they
proceed. I shouldn't need to hack around the library just because I
want to add a feature or two.
>> That's it. Now fire away and kill me dead. I know that I'm not happy
>> with what we have right now, even to the point where I'd write a new IF
>> language/system just for the kicks of it if I could find some active
>> users and authors :-)
>
> It sounds like your complaints are about punctuation. So just write
> a program that translates your preferred punctuation scheme into
> Inform or TADS source. That would be easy, and it would be useful
> to you even if no one else wanted to use it.
Uhm... Kevin, with all due respect to you, I think you are missing the
point. It's not about the punctuation. It's about the ideas behind the
punctuation: for instance how does the output format to which you are
compiling the game influence the features that a language can support?
Can you see features of the interpreter in the compiler features and
the language syntax?
And once again... I'm not trying to diss anybody's work here. All of
the systems that I've talked about represent a huge amount of time
invested into design, programming and debugging. I'm merely trying to
reach better understanding of it myself by trying to figure out why
things are done the way they are. By trying to understand the
advantages and disadvantages.
Sincerely,
-i
Ivan Stojic
>> Then several new (language?) constructs appear and my understanding
>> dies a quick and painful death. There's the whole before [; SomeAction:
>> ... ]; thing. The syntax is confusing. It looks like a routine but it's
>> actually an object property.
>
> What's wrong with functions as object properties? How else would you
> implement before?
In a true object oriented environment, your before and after would be
methods in the base class that do nothing by default. You would
implement them as needed for your objects using closures.
> The autoswitch thing may be confusing, but you always
> can write this switch yourself instead.
Really? How? I didn't find that documented anywhere!
>> Basically, I'd want the language to be:
>>
>> - Essentially it should be an imperative, object oriented language. I
>> want the concept of class versus instance. I want inheritance,
>> polymorphism, closures and such. It should have a clean and easy syntax
>> comparable to modern general purpose programming languages.
>
> Well, my lIFp library would certainly feature all of the above :)
What;s the IIFP library? :-)
>> - It doesn't need graphics, sound or rich formatting as far as I'm
>> concerned, but I do want the input file to be parsed as an UTF file.
>> Typing @:o to get an umlaut in the 21st century is seriousely wrong.
>
> No, it's not. I don't know about you, but my keyboard doesn't have
> umlaut o, so typing @:o is easier for me.
Caveat emptor :-) Those people who often type such characters (for
instance, because their language needs them) would benefit a lot from
having the glypths natively available in their games. And it would be
more native for them because with a decent set of tools, the Unicode
characters would flow from the operating system, to the text editor, to
the compiler, to the interpreter. For those users who are keyboard or
operating system or editor challanged, they could still use the \u
escape sequences that most other programming languages know and love.
>> - The library should be closely integrated with the language itself. I
>> don't need the library to be editable, I need it to be extendable and
>> overridable.
>
> That's what you get in any IF language.
So, how do you feel if you read the technical description of a game and
find written there that the game uses a patched library?
>> - I want to have identically or close to identically feature rich
>> interpreters/runners for the game for at least these three platforms:
>> Windows, Mac OS (8, 9 and X versions. No Classic allowed for OS X
>> version), and a Java runner which can be used standalone or as an
>> applet.
>
> Hmm, Java applet for lIFp may be beyond me...
Oh, crock. I just figured it out. It's not IIFP, it's L-I-F-P... or
Lisp-Fiction-something... Right? I could probably produce an applet
based interpreter for it, if there's any interest!?
Ivan Stojic
> David Fisher wrote:
>> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
>> news:dq6jrl$pnp$1...@ss405.t-com.hr...
>>
>>> Then several new (language?) constructs appear and my understanding
>>> dies a quick and painful death. There's the whole before [; SomeAction:
>>> ... ]; thing. The syntax is confusing. It looks like a routine but it's
>>> actually an object property. And routines themselves are objects.
>>
>> Might be more accurate to say that a property (of an object or class)
>> can be a routine.
>
> I suspect that Ivan is referring to the fact that Inform lets you do
> this sort of stuff:
> x = some_function;
> y = x.call();
> x = "hello world";
> x.print();
Nope, that's not what I had in mind. Function pointers are nothing too strange.
> Methinks that Graham probably went a bit overboard when he added
> object-oriented features to Inform.
>
> BTW, it took me a while to wrap my head around the differences in the
> way that routines get named inside vs outside of objects:
> hello_property [ ; "hello, world!"; ],
> versus
> [ hello_routine ; "hello, world!"; ];
However, anonymous routines / closures are a bit harder to wrap one's
head around. There's also another thing that creeps me out. The
before/after properties have the implicit switch or something inside
there. The part that handles the "Take: ...; TurnOn: ...;" and so on.
How is that actually implemented? Is it a library feature or a feature
of the language?
-i
Ivan Stojic
<Snip of a lot of stuff I really liked>
Neil, I'm in love. I think you captured the essence of a lot of things
I wanted to say without getting lost in, well, lots of things :-)
Thanks,
-i
Ivan Stojic
>
> Neil Cerutti wrote:
>> On 2006-01-13, Samwyse <sam...@gmail.com> wrote:
>>> David Fisher wrote:
>>>> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
>>>> news:dq6jrl$pnp$1...@ss405.t-com.hr...
>
>>>>> And routines themselves are objects.
>
> I'd say that's a pretty definite reference to the section of DM4 that
> talks about Metaclasses. GN himself says, at the top of page 49, "And
> although you almost never need to know or care, routines as in §1 are
> internally considered as a kind of object, of class Routine; while
> strings in double-quotes are likewise of class String."
>
>>>> Might be more accurate to say that a property (of an object or
>>>> class) can be a routine.
>>
>> Yup.
>
> That's very true, but it's not what is being talked about. Unless Ivan
> says that he mistyped something, the fact that what he said matches the
> above quote is, IMHO, pretty strong evidence concerning his intent.
I think Neil (or whoever) has lost a part of my meaning there. I've
said it like this:
It looks like a routine but it's actually an object property. And
routines themselves are objects.
So, the quote above from DM4 stands as such, but what David Fisher
wrote is also true, just related to my other sentence :-)
Ivan Stojic
> Nick.B...@gmail.com wrote:
>
>> Hahaha that's pretty much true. C gives you a gun and lets you shoot
>> yourself in the foot with it.
>
> I've never liked this analogy, because it doesn't really reflect the
> nature of C. A better one would be, "C gives a power saw with a number
> of different blades, which work amazingly well if you are very careful
> and know what you are doing, but lets you cut your hand off if you
> don't.
I find the following strange: It's quite common for people to
understand that a power-saw can cut off their hand and nobody makes
comments that this is a negative feature of the saw. However, a
programming language that behaves in a similar manner when
misunderstood is considered to be a poor product.
It's irritating that people don't understand that computer systems have
effects on real world and as such, they can never be assumed to be less
intrusive than (for instance) power tools. If you cut off your foot,
you've cut it off, no matter how much you cry about wanting to cut off
something else. It's not the power saw. It's you.
>
>> Of course, C++ gives you a nuclear missle.....
>
> I don't even understand this. C++ has more safety features than C and
> it certainly isn't more powerful in any meaningful sense.
I concur. What most probably don't understand is that if you are
perverted enough and have a C compiler, a preprocessor and lots of free
time, you could write something that theoretically feels like C++.
Sophie Fruehling
> On 2006-01-13 09:03:24 +0100, gr...@mail.ru (Timofei Shatrov) said:
>>> Typing @:o to get an umlaut in the 21st century is seriousely wrong.
>>
>> No, it's not. I don't know about you, but my keyboard doesn't have
>> umlaut o, so typing @:o is easier for me.
>
> Caveat emptor :-) Those people who often type such characters (for
> instance, because their language needs them) would benefit a lot from
> having the glypths natively available in their games.
FWIW, you can type umlauts directly into the source code if you use
the German Inform library. It would be awfully inconvenient otherwise.
--
Sophie Frühling
The cube tastes like sugar. You are suddenly surrounded by a herd
of moose. They start talking to you about a moose-load of things.
James Mitchelhill
> On 2006-01-13 21:01:23 +0100, "Default User" <defaul...@yahoo.com> said:
>
>> Nick.B...@gmail.com wrote:
>>
>>> Hahaha that's pretty much true. C gives you a gun and lets you shoot
>>> yourself in the foot with it.
>>
>> I've never liked this analogy, because it doesn't really reflect the
>> nature of C. A better one would be, "C gives a power saw with a number
>> of different blades, which work amazingly well if you are very careful
>> and know what you are doing, but lets you cut your hand off if you
>> don't.
>
> I find the following strange: It's quite common for people to
> understand that a power-saw can cut off their hand and nobody makes
> comments that this is a negative feature of the saw. However, a
> programming language that behaves in a similar manner when
> misunderstood is considered to be a poor product.
To push the metaphor too far:
Sometimes you need a power-saw that's light and maneuverable. In order
to make this, though, the manufacturer had to strip it down. Now the
engine's exposed and there's no hand-guard at all. Woodchips have a way
of becoming a lethal shower of splinters if you cut into things wrong.
Other times you don't need something so powerful and dangerous. You can
afford the luxury of a hand-guard, a proper engine casing and so on.
Nails embedded in trees can't phase this thing, never mind splinters.
In some situations the powerful and yet dangerous power-saw will win. In
most situations the safer one will, simply because you won't injure
yourself so much along the way.
> It's irritating that people don't understand that computer systems have
> effects on real world and as such, they can never be assumed to be less
> intrusive than (for instance) power tools. If you cut off your foot,
> you've cut it off, no matter how much you cry about wanting to cut off
> something else. It's not the power saw. It's you.
Or, it's your choice of the wrong tool.
--
James Mitchelhill
ja...@disorderfeed.net
http://disorderfeed.net
Samwyse
> On 2006-01-13 14:05:17 +0100, Samwyse <sam...@gmail.com> said:
>> I suspect that Ivan is referring to the fact that Inform lets you do
>> this sort of stuff:
>> x = some_function;
>> y = x.call();
>> x = "hello world";
>> x.print();
>
> Nope, that's not what I had in mind. Function pointers are nothing too
> strange.
Sigh. I was refering to the ".call()" and ".print()" bits (which are
method invocations on the thing pointed to by "x"), not the ability to
get a pointer to a function or a string. Being able to invoke a method
on something is a pretty good indicator that the something has
object-like characteristics.
>> BTW, it took me a while to wrap my head around the differences in the
>> way that routines get named inside vs outside of objects:
>> hello_property [ ; "hello, world!"; ],
>> versus
>> [ hello_routine ; "hello, world!"; ];
>
> However, anonymous routines / closures are a bit harder to wrap one's
> head around. There's also another thing that creeps me out. The
> before/after properties have the implicit switch or something inside
> there. The part that handles the "Take: ...; TurnOn: ...;" and so on.
> How is that actually implemented? Is it a library feature or a feature
> of the language?
A little bit of both. When the compiler sees an action name (i.e. Take
or TurnOn) followed by a colon, it magically inserts a switch statement
which is driven by a global variable whose name escapes me at the
moment. Of course, that variable is also magically allocated by the
compiler as well. Then, when the library is about to invoke, say, a
before method, it assigns the value in 'action' to the magic variable.
The really fun bit is that 'self' is implemented in a very similar way;
it's a global variable that get overwritten every time a method gets
invoked, which allows you to do fun things like this:
x = this_object.hello_property;
self = that_object;
x.call();
Needless to say, don't try that without adult supervision. ;-)
Kevin Venzke
>>> Then again, there are some things which have become so ingrained in
>>> programmers today that it seems strange to find the rules have shifted. It
>>> may be that I've learned wrong rules. Hey Hugo: why is the exclamation mark
>>> still used to comment to the end of line? As a consequence, you write
>>> not-equal as ~= which makes my C++, Java and Python trained brain twich.
>>
>> I like <> . It is easier to type.
>
> Yes, but then again, let's think of what <> means. It transfers or "bounces"
> execution from one action to another, effectively changing the state of the
> game state machine. So, what is (functionally speaking) the <> operator?
I guess you're talking about Inform. I meant <> for the meaning of
"not equal to."
> Here's an exception for you again.
>
> sdesc = "Start Room"
>
> is not a statement, but
>
> "The room is on fire!";
>
> is a statement. Why would self.sdesc = "foo"; written inside the ldesc routine
> BE a statement?
Of course that's a statement. What do you say a statement is?
>> It sounds like your complaints are about punctuation. So just write
>> a program that translates your preferred punctuation scheme into
>> Inform or TADS source. That would be easy, and it would be useful
>> to you even if no one else wanted to use it.
>
> Uhm... Kevin, with all due respect to you, I think you are missing the point.
> It's not about the punctuation. It's about the ideas behind the punctuation:
> for instance how does the output format to which you are compiling the game
> influence the features that a language can support? Can you see features of
> the interpreter in the compiler features and the language syntax?
What kind of features do you mean?
Kevin Venzke
Dan Shiovitz
Ivan Stojic <ivas...@ordecon.com> wrote:
>
[..]
>Not at all. However, TADS (and I'm pretty sure that it's valid for Hugo
>as well) doesn't have a traditional preprocessor. It's "preprocessor"
>is embedded into the compiler, so you can't really call it a
>preprocessor.
>
>The #include is parsed and executed by the compiler and calling it
>"#include" instead of "include" doesn't really have any syntactic
>value. The hash in front is just a lump of sugar.
As a minor point of order, TADS *does* have a traditional preprocessor.
Yes, it's executed by the same program that does the rest of the
compilation, but since it's happening before the compiler's parsing
stage, it's a preprocessor. Inform, on the other hand, doesn't have a
real preprocessor and handles its Include and If statements as part of
the parsing stage. I'm not sure what Hugo does in this area.
[..]
>Sure. <> is easier to type, but behind the simple syntax there's a
>whole boatload of things happening that are really complex and that are
>only partially visible through the language features.
Yeah, but on the other hand, this is a feature that people find really
useful and need to do frequently, so why not build it into the
language? It wouldn't be as useful for a general-purpose language, but
in the case of IF, it really is something that people need to do a
lot. The same applies to shortcuts with "" used to print strings -- IF
games print a lot more text, proportionately, than most pieces of code
do, and a shortcut is handy.
>Here's an exception for you again.
>
>sdesc = "Start Room"
>
>is not a statement, but
>
>"The room is on fire!";
>
>is a statement. Why would self.sdesc = "foo"; written inside the ldesc
>routine BE a statement? If it's a statement inside a routine, but not a
>statement outside a routine, it's a pretty shifty grammar.
It's pretty usual for languages to have some grammar construct line
ExpressionStatement := <expr> <semicolon>
C, for instance, has an example of this with "x = 7;"
[..]
>I'm not going to gain anything by a non editable library per se. I just
>don't want to have the need to edit it. It should let me extend it and
>control it via "plugin points" where my code can catch events as they
>proceed. I shouldn't need to hack around the library just because I
>want to add a feature or two.
Well, sure, this is pretty much the ideal of all library design. But
it's an ideal -- there's no way anyone can anticipate everything you
might possibly want to do in your game and not require you to edit the
library at all.
I think people are generally in agreement with you that language
syntax should be regular, that it's helpful for them to be similar to
C-like languages that many people are familiar with, and that libraries
should be easily overridable by the user. But there are other demands
on IF systems also -- most notably, for the language and library to
make commonly-done tasks easy, and provide useful building blocks for
doing more complex things. What languages and libraries end up as tend
to be, naturally, some compromise between all the various demands.
>-i
--
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
Kevin Venzke
>>> need the library to be editable, I need it to be extendable and overridable.
>>
>> That's what you get in any IF language.
>
> So, how do you feel if you read the technical description of a game and find
> written there that the game uses a patched library?
Do you mean that there were bugs in the library, and the author had
no choice but to edit the library (not simply override something)?
Kevin Venzke
Ivan Stojic
>
> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> news:dq98uj$ddt$1...@ss405.t-com.hr...
>>>> Then again, there are some things which have become so ingrained in
>>>> programmers today that it seems strange to find the rules have shifted.
>>>> It may be that I've learned wrong rules. Hey Hugo: why is the
>>>> exclamation mark still used to comment to the end of line? As a
>>>> consequence, you write not-equal as ~= which makes my C++, Java and
>>>> Python trained brain twich.
>>>
>>> I like <> . It is easier to type.
>>
>> Yes, but then again, let's think of what <> means. It transfers or
>> "bounces" execution from one action to another, effectively changing
>> the state of the game state machine. So, what is (functionally
>> speaking) the <> operator?
>
> I guess you're talking about Inform. I meant <> for the meaning of
> "not equal to."
Arrrr! The problems that arise when you post to usenet late, late at night :-)
>
>> Here's an exception for you again.
>>
>> sdesc = "Start Room"
>>
>> is not a statement, but
>>
>> "The room is on fire!";
>>
>> is a statement. Why would self.sdesc = "foo"; written inside the ldesc
>> routine BE a statement?
>
> Of course that's a statement. What do you say a statement is?
I'd say that the statement is the minimal unit of structure in a
programming language. Everything else is composed of statements.
If the assignment above IS a statement inside the ldesc routine is a
statement, how can it not be outside of a routine?
Contrast that with other languages:
C's "int a = 3;" is always a statement, inside functions or not. Java's
'String myString = "blah";' is a statement wherever it is.
>>> It sounds like your complaints are about punctuation. So just write
>>> a program that translates your preferred punctuation scheme into
>>> Inform or TADS source. That would be easy, and it would be useful
>>> to you even if no one else wanted to use it.
>>
>> Uhm... Kevin, with all due respect to you, I think you are missing the
>> point. It's not about the punctuation. It's about the ideas behind the
>> punctuation: for instance how does the output format to which you are
>> compiling the game influence the features that a language can support?
>> Can you see features of the interpreter in the compiler features and
>> the language syntax?
>
> What kind of features do you mean?
Taken from DM4, Chapter 1, Section 7: Arguments and Return Values
[ Weather called force;
print "I forecast a ", (string) called, " measuring force ",
force, " on the Beaufort scale.^";
];
Weather("hurricane", 12);
In the example above, you see that the interpreter obviously cannot
determine the contents of the "called" variable. The way this works I
suppose is that the word "hurricane" ends up in some sort of a string
pool, and the variable "called" is just a pointer to a constant pool
item.
That's what I mean by interpreter features that shine through to the language.
Here's a counter-example of a fictional language based on Perl that
tracks it's types and does the right thing all the time:
sub Weather {
my $called = shift;
my $force = shift;
print("I forecast a $called measuring force $force on the beaufort scale.\n");
}
Notice how the language knows what's in the variables and knows how to
print them out the right way without being helped along. Seriously, did
you ever want to print out an index of the string constant?
Ivan Stojic
Meaning that the author had to hack apart the innards of the library to
get some kind of functionality he wanted (See Andrew Plotkin's Shade).
Ivan Stojic
:-))))))))
You guys are all great!
I think I'll have lots of fun with IF, if you don't mind my occasional
harping about the religion of language design :-)
Timofei Shatrov
tried to confuse everyone with this message:
>On 2006-01-13 09:03:24 +0100, gr...@mail.ru (Timofei Shatrov) said:
>
>>> Then several new (language?) constructs appear and my understanding
>>> dies a quick and painful death. There's the whole before [; SomeAction:
>>> ... ]; thing. The syntax is confusing. It looks like a routine but it's
>>> actually an object property.
>>
>> What's wrong with functions as object properties? How else would you
>> implement before?
>
>In a true object oriented environment, your before and after would be
>methods in the base class that do nothing by default. You would
>implement them as needed for your objects using closures.
Then you lose the ability to modify before at run-time. Of course now
that you mentioned it, I discovered that in my library before and after
are implemented as methods
>
>> The autoswitch thing may be confusing, but you always
>> can write this switch yourself instead.
>
>Really? How? I didn't find that documented anywhere!
>
>>> Basically, I'd want the language to be:
>>>
>>> - Essentially it should be an imperative, object oriented language. I
>>> want the concept of class versus instance. I want inheritance,
>>> polymorphism, closures and such. It should have a clean and easy syntax
>>> comparable to modern general purpose programming languages.
>>
>> Well, my lIFp library would certainly feature all of the above :)
>
>What;s the IIFP library? :-)
Hmm, I need to invent a different spelling. Something like L(IF)P. Lots
of Interactive Fiction Parentheses!
>>> - The library should be closely integrated with the language itself. I
>>> don't need the library to be editable, I need it to be extendable and
>>> overridable.
>>
>> That's what you get in any IF language.
>
>So, how do you feel if you read the technical description of a game and
>find written there that the game uses a patched library?
Since the library is generally open-source, there is nothing wrong with
editing it. Most IF languages provide a way to replace any function from
the library, so most of the time editing the library itself is not
needed. There are some large chunks of code in Inform library that deal
with low-level stuff, so if one wants to make some changes in that code
he needs to hack the library. Generally if you don't understand some
part of the library, you probably don't need to modify it.
>>> - I want to have identically or close to identically feature rich
>>> interpreters/runners for the game for at least these three platforms:
>>> Windows, Mac OS (8, 9 and X versions. No Classic allowed for OS X
>>> version), and a Java runner which can be used standalone or as an
>>> applet.
>>
>> Hmm, Java applet for lIFp may be beyond me...
>
>Oh, crock. I just figured it out. It's not IIFP, it's L-I-F-P... or
>Lisp-Fiction-something... Right? I could probably produce an applet
>based interpreter for it, if there's any interest!?
It has to be completed first...
John Connors
> On Thu, 12 Jan 2006 23:05:41 +0100, Ivan Stojic <ivas...@ordecon.com>
> tried to confuse everyone with this message:
>
>
>>
>>
>>>"Ivan Stojic" <ivas...@ordecon.com> wrote in message
>>>
>>>>On 2006-01-11 00:37:26 +0100, "David Fisher" <da...@hsa.com.au> said:
>>>>
>>>>
>>>>>There is a useful comparison of popular IF languages at
>>>>>http://www.firthworks.com/roger/cloak/index.html
>>>>
>>>>I really enjoyed examining the comparison of various languages. I find
>>>>them all to be rather odious, unfortunately. Most of them seem to try
>>>>to be both C and Lisp at the same time.
>
>
> Writing IF in Lisp may be a reality in the near future ;)
>
>
Why the near future? Why not now :)
<SNIPPUS, MAXIMUS>
Kevin Venzke
I don't know the facts about Shade, but do you know for certain
that the innards of the library needed to be hacked, and that there
was no way to override the inadequate code with some kind of
"replace" keyword? If the necessary changes are substantial, it
might simply be easier to directly modify a copy of the library.
I don't feel anything *about the library* to read that a game's author
has modified it for some purpose. It's not a secret that standard
libraries have not been written to anticipate everything an author
might want to do.
Some libraries are better than others, though.
Kevin Venzke
Timofei Shatrov
tried to confuse everyone with this message:
>Timofei Shatrov wrote:
>> On Thu, 12 Jan 2006 23:05:41 +0100, Ivan Stojic <ivas...@ordecon.com>
>> tried to confuse everyone with this message:
>>
>>
>>>On 2006-01-11 23:54:08 +0100, "David Fisher" <da...@hsa.com.au> said:
>>>
>>>
>>>>"Ivan Stojic" <ivas...@ordecon.com> wrote in message
>>>>news:dq3lg1$blm$1...@ss405.t-com.hr...
>>>>
>>>>>On 2006-01-11 00:37:26 +0100, "David Fisher" <da...@hsa.com.au> said:
>>>>>
>>>>>
>>>>>>There is a useful comparison of popular IF languages at
>>>>>>http://www.firthworks.com/roger/cloak/index.html
>>>>>
>>>>>I really enjoyed examining the comparison of various languages. I find
>>>>>them all to be rather odious, unfortunately. Most of them seem to try
>>>>>to be both C and Lisp at the same time.
>>
>>
>> Writing IF in Lisp may be a reality in the near future ;)
>>
>>
>
>Why the near future? Why not now :)
>
Actually there is already one IF game written in Lisp (Emacs Lisp to be
precise) called Dunnet, that comes with Emacs distribution. It's source
code doesn't look very expandable though.
Dan Shiovitz
Timofei Shatrov <gr...@mail.ru> wrote:
[..]
>
>Actually there is already one IF game written in Lisp (Emacs Lisp to be
>precise) called Dunnet, that comes with Emacs distribution. It's source
>code doesn't look very expandable though.
In late 2004, someone posted about their scheme-based IF system. The
url in the post is gone, but the post itself is at
http://groups.google.com/group/rec.arts.int-fiction/msg/cdd12ab4e0c443ce
and has a few more details. Also, I forget if anyone has mentioned
Advsys yet, but its syntax is very lisp-like, I believe.
>|a\o/r|,-------------.,---------- Timofei Shatrov aka Grue ------------.
David Thornley
Ivan Stojic <ivas...@ordecon.com> wrote:
>On 2006-01-13 21:01:23 +0100, "Default User" <defaul...@yahoo.com> said:
>
>> Nick.B...@gmail.com wrote:
>>
>>> Of course, C++ gives you a nuclear missle.....
>>
>> I don't even understand this. C++ has more safety features than C and
>> it certainly isn't more powerful in any meaningful sense.
>
If I write "a + b" or "a->foo(x)" in C, it's easy to understand.
In C++, you don't know what the first thing means necessarily,
or where to look for the definition of foo.
In a well-written C++ program, you don't need to worry about things
like that, because the "+" will be used for addition or concatenation
in some form or other, and "foo" will do conceptually the same
thing wherever it is defined.
And C++ is more powerful in meaningful senses, in that it contains
abstractions that C simply cannot handle.
>I concur. What most probably don't understand is that if you are
>perverted enough and have a C compiler, a preprocessor and lots of free
>time, you could write something that theoretically feels like C++.
>
If you're willing to write your own preprocessor, and make it fancy
enough to be something of a compiler, you could write "cfront".
That's the program that went in the front of the early C++ compiler
batch file.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
John W. Kennedy
A non-trivial exercise. cfront was a full-blown compiler; it merely
happened to produce C instead of object code as its output, for
bootstrapping reasons.
--
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
-- Charles Williams. "Judgement at Chelmsford"
Uli Kusterer
"John W. Kennedy" <jwk...@attglobal.net> wrote:
> >> I concur. What most probably don't understand is that if you are
> >> perverted enough and have a C compiler, a preprocessor and lots of free
> >> time, you could write something that theoretically feels like C++.
> >>
> > If you're willing to write your own preprocessor, and make it fancy
> > enough to be something of a compiler, you could write "cfront".
> > That's the program that went in the front of the early C++ compiler
> > batch file.
>
> A non-trivial exercise. cfront was a full-blown compiler; it merely
> happened to produce C instead of object code as its output, for
> bootstrapping reasons.
You wouldn't need a compiler. All you'd need is a parser. This is a
non-trivial exercise because C++ is such a complex language. But
strictly spoken, everything C++ does could be achieved in most
Touring-complete lower-level languages. That's obvious, because the
limit what those languages can do is effectively what the computer
they're running on can do.
So, semantically, the OP was right: C++ isn't really more powerful, as
it is also limited by the machine it's running on. However, if power
equates to how much you can do per line of code, or how easy it is to
write correct code, then correctly-used C++ is more powerful. After all,
it's a superset of C (well, almost, but I don't want to bore you any
more).
Bottom line: You have different definitions of the word "power". Agree
on a meaning, and you can continue this discussion. Otherwise, happy
flamewar :-)
Cheers,
-- Uli
http://www.zathras.de
Neil Cerutti
>>> - The library should be closely integrated with the language
>>> itself. I don't need the library to be editable, I need it to
>>> be extendable and overridable.
>>
>> That's what you get in any IF language.
>
> So, how do you feel if you read the technical description of a
> game and find written there that the game uses a patched
> library?
I think it's overly optimistic to think anyone can design an IF
library that never needs to be patched or hacked for any game.
The attempt would be noble. But we mustn't pretend this is a new
idea. Inform and TADS (to mention the ones I'm most familiar
with) all contain extensible, flexible libraries for IF.
--
Neil Cerutti
Neil Cerutti
That's not the only way to define it.
> If the assignment above IS a statement inside the ldesc routine
> is a statement, how can it not be outside of a routine?
>
> Contrast that with other languages:
>
> C's "int a = 3;" is always a statement, inside functions or
> not. Java's 'String myString = "blah";' is a statement wherever
> it is.
Pedantically,
int a = 3;
is not a statement in C.
But ignoring that ponit, C makes a similar compromise to
terseness:
struct foo { char *sdesc; };
int foo(struct foo) { foo.sdesc = "Start Room"; }
> Taken from DM4, Chapter 1, Section 7: Arguments and Return Values
>
> [ Weather called force;
> print "I forecast a ", (string) called, " measuring force ",
> force, " on the Beaufort scale.^";
> ];
>
> Weather("hurricane", 12);
This function call may only be made inside another function. In
Inform and TADS, statements may only appear at function scope.
[ Main;
Weather("hurricane", 12);
];
> In the example above, you see that the interpreter obviously
> cannot determine the contents of the "called" variable. The way
> this works I suppose is that the word "hurricane" ends up in
> some sort of a string pool, and the variable "called" is just a
> pointer to a constant pool item.
In the code above, "hurricane" is encoded into a 5-bit string and
stored in the read-only part of the z-machine. At run-time,
weather is passed a number that references that string as its
first parameter, and the number 12 as its second. The print rule
(string), which is the same thing as an io-manipulator in C++ (a
hidden function call), knows how to look up that string in the
string-table of the z-machine, and print its contents. If you're
expecing an Object instead of a String, you use the (name) print
rule.
> That's what I mean by interpreter features that shine through
> to the language.
>
> Here's a counter-example of a fictional language based on Perl
> that tracks its types and does the right thing all the time:
>
> sub Weather {
> my $called = shift;
> my $force = shift;
>
> print("I forecast a $called measuring force $force on the beaufort scale.\n");
> }
RTTI is very rarely needed in Inform code, but it is possible to
do it if you really want to, using the ofclass predicate
operator. You could implement your print routine in Inform,
though you obviously can't call it print.
Bummer how the print line stretches off the end of my screen.
You'll want a syntax that doesn't inflict pain when you need to
do that, since IF games need to contain large blocks of text.
Inform didn't have that feature until Inform 6, by the way. You
used to need to glue line-spanning strings together by escaping
the newline with \.
> Notice how the language knows what's in the variables and knows
> how to print them out the right way without being helped along.
> Seriously, did you ever want to print out an index of the
> string constant?
I haven't needed to in a game, though the debugging wing of
Inform does it all the time.
You will not be able to completely do away with
print-rules/io-manipulators in your hypathetical language, due to
the need to print proper articles and other conjugations.
--
Neil Cerutti
Andrew Plotkin
>
> "Ivan Stojic" <ivas...@ordecon.com> wrote in message
> news:dqammj$hd0$2...@ss405.t-com.hr...
> > On 2006-01-14 02:41:29 +0100, "Kevin Venzke" <step...@yahooo.frr> said:
> >
> >>>>> - The library should be closely integrated with the language itself. I
> >>>>> don't need the library to be editable, I need it to be extendable and
> >>>>> overridable.
> >>>>
> >>>> That's what you get in any IF language.
> >>>
> >>> So, how do you feel if you read the technical description of a game and find
> >>> written there that the game uses a patched library?
> >>
> >> Do you mean that there were bugs in the library, and the author had
> >> no choice but to edit the library (not simply override something)?
> >
> > Meaning that the author had to hack apart the innards of the library to get
> > some kind of functionality he wanted (See Andrew Plotkin's Shade).
>
> I don't know the facts about Shade, but do you know for certain
> that the innards of the library needed to be hacked, and that there
> was no way to override the inadequate code with some kind of
> "replace" keyword? If the necessary changes are substantial, it
> might simply be easier to directly modify a copy of the library.
To answer this: there is a small library patch in Shade. It addresses
a feature (not bug) that I wanted in the library code; it was a
low-level enough feature that it was easier to do it by patching
library files than by replacing them.
(Specifically, I wanted to modify the list-writer: to provide an
option for serial commas, and to customize lists that didn't use
FULLINV_BIT. These features have since been adopted by the standard
library. If I were writing Shade today, I wouldn't have had to
customize anything.)
I *could* have done that customization with a Replace statement; it
was just fewer lines of code (in my source directory) to keep it as a
patch file. (The patch file would also made it easier to pull in a
later library update. But that wound up not being important,
obviously.)
The interpretation here is that, from a design standpoint, there is no
difference between "editing" a library and "overriding" it. IF
requires that all aspects of the library be customizable (even the
parts that the creator didn't foresee having to customize). Different
IF systems provide different mechanisms for doing this.
Inform provides, well, uncomfortably many of them -- that's due to its
history. It started with one very crude and powerful customization
mechanism: editing the library source. This is so effective a model
that it's hard to imagine a new IF system that doesn't allow it.
Inform later acquired the "Replace" statement, which is nearly as
powerful and somewhat less crude. Then there's the whole motley array
of higher-level customizations: library properties, before/after,
LibraryMessages. At this point in Inform's evolution, "Replace" is as
far as just about anyone needs to go -- I did no patching for
_Dreamhold_, for example.
If I were redesigning Inform from scratch, I would happily rip out all
the customization models -- up to Replace -- and invent a new one
which was more powerful and more precise than all of them. Indeed, I'd
say that this is *the* problem which any new IF system needs to
address. (Parser, schmarser.) But I still wouldn't try to take away
the editable-library model. It's too important an escape valve.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison
without trial, it's for one reason: they don't feel like it. Not
because of the Fifth Amendment.
Samwyse
>
> Inform later acquired the "Replace" statement, which is nearly as
> powerful and somewhat less crude. Then there's the whole motley array
> of higher-level customizations: library properties, before/after,
> LibraryMessages. At this point in Inform's evolution, "Replace" is as
> far as just about anyone needs to go -- I did no patching for
> _Dreamhold_, for example.
>
> If I were redesigning Inform from scratch, I would happily rip out all
> the customization models -- up to Replace -- and invent a new one
> which was more powerful and more precise than all of them. Indeed, I'd
> say that this is *the* problem which any new IF system needs to
> address. (Parser, schmarser.) But I still wouldn't try to take away
> the editable-library model. It's too important an escape valve.
What I'd like most is is some way to perform source-level editing of the
library. For example, one of my WIPs uses a lot of line-of-sight
calculations, i.e.
> LOOK NORTH
You see the dining room (where Carl is standing), the kitchen (where
Sheen is standing) and finally the patio (where Jimmy is standing).
The easiest way for me to implement this was to place multiple objects
in the 'n_to' property:
Room LivingRoom with
n_to DiningRoom Kitchen Patio;
Unfortunately, there's one line in the library where this causes
problems. In almost the exact center of GoSub, there's this line:
j = i.thedir;
which causes a run-time warning. The fix is to change it to read:
j = (i.&thedir)-->0;
The "problem" is that GoSub is one of the larger routines in verblibm,
so I really hate to Replace the whole thing. What I'd like to see is
something like this:
Replace GoSub s/i.thedir/(i.&thedir)-->0/;
That would let me reach into a routine and make small changes which
would have a chance of compatibility with library upgrades.
Andrew Plotkin
>
> What I'd like most is is some way to perform source-level editing of the
> library. For example, one of my WIPs uses a lot of line-of-sight
> calculations, i.e.
>
> > LOOK NORTH
> You see the dining room (where Carl is standing), the kitchen (where
> Sheen is standing) and finally the patio (where Jimmy is standing).
>
> The easiest way for me to implement this was to place multiple objects
> in the 'n_to' property:
> Room LivingRoom with
> n_to DiningRoom Kitchen Patio;
>
> Unfortunately, there's one line in the library where this causes
> problems. In almost the exact center of GoSub, there's this line:
> j = i.thedir;
> which causes a run-time warning. The fix is to change it to read:
> j = (i.&thedir)-->0;
>
> The "problem" is that GoSub is one of the larger routines in verblibm,
> so I really hate to Replace the whole thing. What I'd like to see is
> something like this:
> Replace GoSub s/i.thedir/(i.&thedir)-->0/;
Wow. I've pretty comfortable with the C preprocessor. I'm also pretty
comfortable with the idea that it was a bad idea and it causes a lot
of headaches. Your suggestion is the first language construct I've
seen which is scarier. :)
From a design standpoint, the right answer is to break the library
down into smaller pieces, so replacing (or customizing, or whatever)
one piece is easier. If a system is truly fluent in customization, it
would support a library written in very tiny pieces -- one line or a
few lines per piece -- with no loss of efficiency and minimal loss of
readability.
(In other words, allow that kind of one-line editing, but with
programmatic recognition and replacement instead of blind text
matching. I'm thinking some notation that lets you name individual
lines or stanzas of code -- including named lines nesting inside named
stanzas. As opposed to the current norm of naming functions, which
never nest.)
From a using-Inform-today standpoint, I'd recommend setting up a
framework that uses sed/awk/perk as a preprocessor. Copy the library
files to a build directory, run your regexps over them, and then hand
them off to the Inform compiler. Building the regexp functionality
into the compiler itself would be both painful and kind of nasty.
(This does leave you with the problem of explaining your framework to
anyone else who wants to compile your code. A minor issue for a game;
a larger issue for a library extension. I have no bright idea about
this.)
--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 of the Eighth Amendment.
Andrew Plotkin
> Here, Samwyse <sam...@gmail.com> wrote:
> >
> > The "problem" is that GoSub is one of the larger routines in verblibm,
> > so I really hate to Replace the whole thing. What I'd like to see is
> > something like this:
> > Replace GoSub s/i.thedir/(i.&thedir)-->0/;
>
> Wow. I've pretty comfortable with the C preprocessor. I'm also pretty
> comfortable with the idea that it was a bad idea and it causes a lot
> of headaches. Your suggestion is the first language construct I've
> seen which is scarier. :)
And yes, Adam, I am *including* Intercal constructs.
Andrew Clover
> 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 of the Eighth Amendment.
I am reminded of the passage in Matthew about hypocrites praying aloud.