Class library by community design
James Taylor
"class library" and the only similar post I found was back in 1996:
http://groups.google.com/groups?th=942974647a381247
It occurred to me that the various IF programming languages each
come with their own class libraries and, indeed, that a good
library would seem to be *the* critical part of any IF authoring
system. The problem is that constructing a reasonably complete
library is a huge undertaking, and it is arguable that no single
language designer could ever hope to perfect such a thing. I've
certainly heard people gripe about library limitations, and the
wealth of third party additions underlines those shortcomings.
Furthermore, the existing libraries are not interchangeable.
There are various people working on new languages or environments
for creating/running IF and, like general programming languages,
this is a mixed blessing but, on balance, I see it as a good
thing for people to progress the tools we have at our disposal.
However, I believe that the design of languages and class
libraries should be separated so that neither is encumbered by
the need to build the other. New languages, compilers, runtime
environments, and the like should be able to come (and maybe go)
without the need for whole new class hierarchies to be designed.
Similarly, promising class libraries should not stagnate due to
their ties to a particular language that just happens to be
infrequently used.
This got me thinking. There is a venerable pool of expertise in this
newsgroup in areas such as IF theory, mimesis, design, and coding.
I very much expect that there would be a fairly common consensus
about what should be in a class library. Do you think it would be
a good idea to do a community project to design the perfect class
hierarchy, preferably in a language independent way? This would
include careful choice of the default behaviour and descriptive
text so that maximal mimesis is achieve with minimal coding or
alteration required by authors. It should probably also have
core support for difficult notions such as distance, time,
quantity, size, etc. It could even be extended to include a
specification of the standard verb set, synonyms, pronouns, etc.
I realise that Usenet may not be the best forum for a project that
would require such a long term effort, but perhaps a wiki would be.
The project would probably not come to fruition for a year or more,
but the end result would be a library design freed from the
myopic viewpoint of any particular language, and which could then
be implemented by future languages, and perhaps also existing ones.
Of course, people will always find new types of object that they
feel should be part of the library - and that's not a problem.
The library could grow over time to meet everyone's needs, and
there should never be a need to write yet another water class.
I see two fairly intimidating challenges: 1) How to write a class
hierarchy in a language independent way which is nevertheless
relatively easy to cross compile into various real implementation
languages. 2) How to manage the overall inheritance structure so
that everything benefits from inheritance in the best possible
way rather than just becoming a flat sprawl of largely unrelated
classes. Perhaps we'd have to appoint specific people to
administer certain major branches of the class tree.
This might seem like too big a project to take on, but I was
inspired by the progress of the Perl 6 redesign by its community
and felt that this could hardly be a bigger challenge than that.
Please let me know your thoughts. Am I barking mad, or is this
kind of project as important to the future of IF as the current
apocalypse in the Perl community is to the future of Perl? :-)
--
James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
To protect against spam, the address in the "From:" header is not valid.
In any case, you should reply to the group so that everyone can benefit.
If you must send me a private email, use james at oakseed demon co uk.
James Taylor
Usenet correctly. I'm not sure why. Apologies if you get it twice.
Maybe someone could put my mind at ease by indicating you've seen it.
Thanks.
---------------------
Uli Kusterer
James Taylor <spam-block-@-SEE-MY-SIG.com> wrote:
> Do you think it would be
> a good idea to do a community project to design the perfect class
> hierarchy, preferably in a language independent way? This would
> include careful choice of the default behaviour and descriptive
> text so that maximal mimesis is achieve with minimal coding or
> alteration required by authors. It should probably also have
> core support for difficult notions such as distance, time,
> quantity, size, etc. It could even be extended to include a
> specification of the standard verb set, synonyms, pronouns, etc.
Hi,
I think there's a couple of significant practical problems with your
idea
1) You're assuming that there's some sort of "one size fits all"
"perfect" class library. There isn't. TADS 2, which has been lauded as
having a good library, still got WorldClass (or whatever it was called)
as an alternative. Different game authors have different ideas about
different aspects of their games, the most notorious example being
conversation systems.
You could argue that it would just require a library that is large
enough and flexible enough to do *all* the different options, and I
think that's exactly the direction Mike is taking TADS 3 in. However, if
you've tried TADS yet, you'll notice it adds a lot of complexity to what
was once a fairly simple design. Which is exactly the reason why I've
given up on T3. It felt like by the time it'd take me to learn the inner
workings of adv3, I could've written my entire game and written some
code that takes care of the stuff adv.t is missing for my game.
2) You're assuming that a library is fundamentally independent from its
language. IMHO, a good library makes extensive use of language features.
If a language supports OO principles like classes and methods and
multiple inheritance, its library will look completely different than
that of a procedural language that only supports data structures, which
will in turn look different.
> I see two fairly intimidating challenges: 1) How to write a class
> hierarchy in a language independent way which is nevertheless
> relatively easy to cross compile into various real implementation
> languages.
Not to mention that it has to be able to take advantage of
language-specific features, work around languages that have no way of
dynamically dispatching method calls etc.
You'd basically have to implement a code generator that takes design
patterns and compiles them into a working program. I guess this could be
done, just like GCC has a front-end and a back-end so each programming
language can be written in a generic way, and the work that's been done
for getting it to compiler C on Red Hat can be leveraged to compile
Pascal and Forth as well, or whatever...
> 2) How to manage the overall inheritance structure so
> that everything benefits from inheritance in the best possible
> way rather than just becoming a flat sprawl of largely unrelated
> classes. Perhaps we'd have to appoint specific people to
> administer certain major branches of the class tree.
You're assuming that every programming language using this library
supports inheritance. Do they?
> This might seem like too big a project to take on, but I was
> inspired by the progress of the Perl 6 redesign by its community
> and felt that this could hardly be a bigger challenge than that.
> Please let me know your thoughts. Am I barking mad, or is this
> kind of project as important to the future of IF as the current
> apocalypse in the Perl community is to the future of Perl? :-)
Actually, I think you have the wrong impression here. Perl is *one*
language (though, agreed, it is sort of a mix between several languages
in its design, but that's beside the point). Which has a relatively
specific audience. You, so far, want to generate a library for a whole
flurry of languages, all of which have different strengths and
weaknesses and feature sets, for an theretofore unspecified audience.
I think, what you should do is start making some choices:
-> What languages (what kinds of languages?) do you want to support?
-> What kinds of games do you want to support? Which ones have you
forgotten, and what will you do when you find out about a forgotten one
that needs significant changes to the library to support?
-> Who is your audience? Programmers? Authors? Script kiddies?
Programmers will typically require a lot of flexibility, which usually
increases the abstractness and complexity of a library. Authors will
usually prefer a library that "just works" and is simple and easy to
overlook, which usually means reduced complexity, more concrete designs
and less flexibility.
These are just some examples. Your idea does have merit, but you have a
number of pitfalls just waiting for you.
E.g. if you want to somehow automate translation of the library design
into different programming languages, you could easily generate code
that is horribly ineffective and slow, or very complicated to write
because it tries to fake language features that don't exist in the
particular language you're using. A good (i.e. bad) example of such a
program was Microsoft Word 6.0 for Macintosh.
It all depends on the decisions you make during the design or
prototyping process of your library.
Cheers,
-- M. Uli Kusterer
James Taylor
Uli Kusterer <wit...@t-online.de> wrote:
>
> In article <ant14152...@nospam.demon.co.uk>,
> James Taylor <spam-block-@-SEE-MY-SIG.com> wrote:
> >
> > Do you think it would be
> > a good idea to do a community project to design the perfect class
> > hierarchy, preferably in a language independent way?
>
Hello Uli, and thanks for responding to what might have seemed,
at first sight, to be a silly idea of mine.
> I think there's a couple of significant practical problems with
> your idea
I think the issues you raise could be thrashed out by the group
and workable solutions found. At the very least, many heads
together would, most likely, produce a better thought out and
more complete design than a single author could. I also think the
very act of trying would bring benefits in deeper understanding
of the IF creation process.
> 1) You're assuming that there's some sort of "one size fits all"
> "perfect" class library. There isn't.
Well, I see a great deal of commonality between all the languages
and IF genres. That's not to say that authors shouldn't break
*some* of those expectations *some* of the time, because that's
part of pushing the boundaries of our medium. However, a work of IF
that broke them all at once wouldn't be recognisable as a work of IF.
Therefore, I believe we could produce a library design which made
the common things easy and the unusual things possible. There
would obviously need to be a simple means of overriding the
library when desired, but that is not a new idea, of course.
> You could argue that it would just require a library that is large
> enough and flexible enough to do *all* the different options,
Actually, I was rather thinking that the community could find a class
hierarchy which along with carefully chosen library initialisation
procedures would allow for radically altering certain aspects as
desired by each prominent school of IF authoring. So, for instance,
I could imagine selecting 1st person, 2nd person, present tense,
past tense, menu conversation, ask/tell conversation, etc, as
simply as saying "SetTense first_person;" or whatever. Maybe whole
collections of stylistic decisions could be packaged under the
names of existing works so that "SetStyles Muse;" or perhaps a more
general "SetStyles Romance;" would be all that needed to be said.
Clearly, it seems that we're going to need a preprocessing stage
which takes all the stylistic selections of an author and generates
a one-off library distillation in their chosen implementation language.
I'm just thinking off the top of my head here but perhaps this
preprocessing stage need not be software running on their local machine.
It could be done by a web service interface to the project's wiki
server. The prospective author would simply browse the web interface
indicating their chosen programming language, natural language,
and style choices, then they would click the download button to
collect the library distillation. The distillation would not
contain anything they did not require in order to keep the size
of the finished works down. Using this technique it wouldn't even
be necessary to say things like "SetStyles Muse;" because those
selections would already have been made before the distilled
library was installed alongside the author's work in progress.
Yes, that sounds feasible. Also, language designers would be
given the ability to modify the backend translation layer for
their particular language so that they can make new versions
whenever they wish and immediately be able to add support for
those new language versions to the library server.
> However, if you've tried TADS yet, you'll notice it adds a lot
> of complexity to what was once a fairly simple design. Which is
> exactly the reason why I've given up on T3. It felt like by the
> time it'd take me to learn the inner workings of adv3, I could've
> written my entire game and written some code that takes care of
> the stuff adv.t is missing for my game.
Growing complexity is certainly a risk, but it is my hope that a
class design can be made to do The Right Thing for mainstream
games if you simply accept the defaults. This way, new authors
will not have a great deal to learn; certainly not the whole
library at once. Later, when an author decides to try their hand
at something more unusual requiring more work on their part
(eg. modelling distances, NPC emotions, etc) all they should need
to do is look at the particular section of the library that
handles that, select it when distilling/translating the library
and read the docs on the wiki (which, being a wiki, would
probably also include a discussion of exactly how best to use
it). All this would ensure a fairly shallow learning curve.
> 2) You're assuming that a library is fundamentally independent
> from its language.
Well, perhaps we need to distinguish between libraries that
are necessarily language dependent, and this meta-library that
I'm proposing. The meta-library would be written in a very high
level meta-language that described things at a conceptual level
rather than at a nitty-gritty implementation level.
> IMHO, a good library makes extensive use of language features.
Well, a good translator can make extensive use of language
features. There's no reason for the meta-library to preclude
very clever language specific code being output by a translator.
The meta-language would be sufficiently high level that it would
not require or conflict with any individual implementation language
features. I expect the first few months of the project would be
spent brainstorming what precise form this meta-language would
take. In the end, I imagine that it would be integral to the
hierarchical structure of the wiki, and eminently human readable
whilst also being sufficiently machine readable for the distiller
and translators to work on.
> If a language supports OO principles like classes and methods and
> multiple inheritance, its library will look completely different
> than that of a procedural language that only supports data structures,
> which will in turn look different.
It would be down to the translator to accomplish best use of the
actual target language. So what if the target language doesn't
support certain features? After all, an 8086 CPU doesn't support
inheritance, or even something as fundamental as strings, but
that doesn't matter because it's the compiler's job to generate
code to make it work. Another example is the CFront translator
which takes C++ as input and generates straight C as output.
Anything's possible.
> > I see two fairly intimidating challenges: 1) How to write a class
> > hierarchy in a language independent way which is nevertheless
> > relatively easy to cross compile into various real implementation
> > languages.
>
> Not to mention that it has to be able to take advantage of
> language-specific features, work around languages that have
> no way of dynamically dispatching method calls etc.
CFront manages it.
> You'd basically have to implement a code generator that takes design
> patterns and compiles them into a working program. I guess this could be
> done, just like GCC has a front-end and a back-end so each programming
> language can be written in a generic way, and the work that's been done
> for getting it to compiler C on Red Hat can be leveraged to compile
> Pascal and Forth as well, or whatever...
Exactly. Okay, so it's by no means trivial, but that shouldn't stop us.
> > 2) How to manage the overall inheritance structure so
> > that everything benefits from inheritance in the best possible
> > way rather than just becoming a flat sprawl of largely unrelated
> > classes. Perhaps we'd have to appoint specific people to
> > administer certain major branches of the class tree.
>
> You're assuming that every programming language using this library
> supports inheritance.
No, I'm assuming that this can be overcome. Actually, quite why
anyone would want to write IF in anything other than an OO
language beats me, but that's a whole other discussion. :-)
> Actually, I think you have the wrong impression here. Perl is *one*
> language (though, agreed, it is sort of a mix between several languages
> in its design, but that's beside the point). Which has a relatively
> specific audience.
Err... I like Perl very much, but I'm not saying anything specific
about Perl in this context. I'm just trying to get people to look
beyond their favourite language to the bigger picture.
> You, so far, want to generate a library for a whole flurry of
> languages, all of which have different strengths and weaknesses
> and feature sets, for an theretofore unspecified audience.
Yes! And why not? It's a worthy goal that would help the entire
community move forward. I think people are getting blinkered by
language details instead of looking at the bigger picture.
If the combined expertise of this beautiful community could put
their heads together and come up with a class design to encompass
the state of the art in world modelling, and free themselves
from the confines of particular languages and their particular
libraries, then the whole field could move rapidly forward.
Not only would a great deal be learned in the process but,
once the design was more or less complete, and the meta-language
tried and tested, then new implementation languages could be
designed to take full advantage of the meta-library. Eventually,
little or no translation from the meta-language would be required
because implementation languages would have caught up with the
higher level concepts that the meta-library deals in.
> I think, what you should do is start making some choices:
>
> -> What languages (what kinds of languages?) do you want to support?
All of them, but let's start with the most popular ones and add
PDP-10 assembly at a later date. ;-)
> -> What kinds of games do you want to support?
Any that the community wishes to support. Someone, probably the
proponent, would simply write the relevant part of the meta-library.
In the case of a new genre, for instance, a parallel set of text
could be written for the default responses. This would obviously
mean that the text itself would need to be factored out into
separate modules which the authors could select at the
distillation phase.
> Which ones have you forgotten, and what will you do when you
> find out about a forgotten one that needs significant changes to
> the library to support?
The meta-library would have to be designed with abstract base
classes that could be overridden to support anything which the
community would collectively regard as within the scope of what
we understand as "Interactive Fiction".
In the *unlikely* event that something so radically different
comes along that we all decide should be within the scope of the
project, but which would require a total reworking of the existing
library, then a separate class hierarchy could be designed into
the library. The distillation process would, of course, just select
that separate class tree when an author chooses to distil an
implementation library to support that type of game.
None of this presents an insurmountable obstacle.
> -> Who is your audience? Programmers? Authors? Script kiddies?
> Programmers will typically require a lot of flexibility, which usually
> increases the abstractness and complexity of a library. Authors will
> usually prefer a library that "just works" and is simple and easy to
> overlook, which usually means reduced complexity, more concrete designs
> and less flexibility.
As I mentioned above, I think the default distillation of the
library would support competent mainstream games in an extremely
simple manner. More sophisticated programmers could select more
sophisticated features at distillation time. Everyone could find
a level of complexity to suit their needs. Furthermore, everyone
could select a language or visual authoring environment as suits
their abilities independently of their choice of library
distillation. Another benefit is that when a someone decides to
move up to a more sophisticated authoring system they won't have
to learn yet another library at the same time.
> E.g. if you want to somehow automate translation of the library design
> into different programming languages, you could easily generate code
> that is horribly ineffective and slow, or very complicated to write
> because it tries to fake language features that don't exist in the
> particular language you're using.
Yes, that might be an issue. However, this is dependent upon the
quality of the translators and is not inherent in the meta-library
itself. The meta-library encodes the kind of high level concepts that
every IF author might wish to use such as rooms, doors, objects,
NPCs, etc, then the translator merely chooses the most efficient
way to implement this in the target language. I see no inherent
reason why the translator cannot produce code to the same quality
that an expert in the target language would produce to implement
those same concepts. Indeed, I rather expect the translators to
draw upon language specific code templates written by just such
experts to implement the high level concepts of the meta-library.
Any other objections?
Any support?
...Anyone?
David Thornley
James Taylor <spam-block-@-SEE-MY-SIG.com> wrote:
>In article <witness-2D808D...@news.t-online.com>,
>Uli Kusterer <wit...@t-online.de> wrote:
>>
>> In article <ant14152...@nospam.demon.co.uk>,
>> James Taylor <spam-block-@-SEE-MY-SIG.com> wrote:
>> >
>> > Do you think it would be
>> > a good idea to do a community project to design the perfect class
>> > hierarchy, preferably in a language independent way?
>>
>> I think there's a couple of significant practical problems with
>> your idea
>
>I think the issues you raise could be thrashed out by the group
>and workable solutions found. At the very least, many heads
>together would, most likely, produce a better thought out and
>more complete design than a single author could.
One reason I think it too ambitious is that it is too demanding on
the community. This is not a large community, and people have their
own ideas of what they want to do. This is not good ground for
supporting mass projects.
Moreover, the community (along with most other software communities
on the net I've seen) has experienced lots of people coming along
with grand projects to be worked on by unspecified other people,
and is resistant to such suggestions.
If you are going to be successful in getting a project going, you have
to do two things.
1. You have to decide that the project is well worth doing, and will
get done.
2. You have to put in a good deal of work before expecting other people
to join you.
If you're not going to do this, for lack of time, will, or expertise,
your project is not going to happen.
I also think the
>very act of trying would bring benefits in deeper understanding
>of the IF creation process.
>
Other people have other ideas here. You may be correct, of course,
but the only way to convince people is to start something and show
people some new insight.
>> 1) You're assuming that there's some sort of "one size fits all"
>> "perfect" class library. There isn't.
>
>Well, I see a great deal of commonality between all the languages
>and IF genres. That's not to say that authors shouldn't break
>*some* of those expectations *some* of the time, because that's
>part of pushing the boundaries of our medium.
This is another reason I doubt this project is practical: we don't
know enough yet to codify a standard library design. TADS 3 isn't
up to 1.0 yet, and people are working on library extensions. This
is very healthy in a field at this stage of maturity, but it means
that there is no shared expectation of exactly what a library should
be. I think this project would be a case of premature standardization.
>Therefore, I believe we could produce a library design which made
>the common things easy and the unusual things possible. There
>would obviously need to be a simple means of overriding the
>library when desired, but that is not a new idea, of course.
>
Right. In what way is this an improvement over what we've got,
aside from the fact that it would be multi-language?
Right now, it is possible to translate library additions into
other languages, and people have done that. That's a certain amount
of work. Making the library multi-language would be a lot of work.
Where's the break-even point?
>> You could argue that it would just require a library that is large
>> enough and flexible enough to do *all* the different options,
>
>Actually, I was rather thinking that the community could find a class
>hierarchy which along with carefully chosen library initialisation
>procedures would allow for radically altering certain aspects as
>desired by each prominent school of IF authoring. So, for instance,
>I could imagine selecting 1st person, 2nd person, present tense,
>past tense, menu conversation, ask/tell conversation, etc, as
>simply as saying "SetTense first_person;" or whatever. Maybe whole
>collections of stylistic decisions could be packaged under the
>names of existing works so that "SetStyles Muse;" or perhaps a more
>general "SetStyles Romance;" would be all that needed to be said.
>
Most object-using IF languages have such library hierarchies. What
would making another, incompatible with what we've got, accomplish?
Moreover, remember that "SetTense first_person;" is not a valid
statement in all IF programming languages. This means that the
library has to be written in some different language that can be
compiled to Inform *and* TADS 2 *and* TADS 3 *and* Hugo *and* ....
This is hardly a trivial project, and it leads to another problem.
If an author were to use this library and want to change anything,
the author would perforce be working in two programming languages,
one for the game and one for the library. I have never seen a
compiler compiling into a target high-level language in which I'd
like to try maintaining the compiled code. I'm sure some exist, but
they can't be easy to write.
Given a choice, most people will prefer to work in one programming
language rather than be required to work in two. This in itself means
that the library you propose will often not be used, reducing its
utility.
>> However, if you've tried TADS yet, you'll notice it adds a lot
>> of complexity to what was once a fairly simple design. Which is
>> exactly the reason why I've given up on T3. It felt like by the
>> time it'd take me to learn the inner workings of adv3, I could've
>> written my entire game and written some code that takes care of
>> the stuff adv.t is missing for my game.
>
>Growing complexity is certainly a risk, but it is my hope that a
>class design can be made to do The Right Thing for mainstream
>games if you simply accept the defaults.
Certainly. That's the idea behind the TADS 3 classes, which Uli seems
to find too complicated to use at the moment. Actually, that's the
idea behind most of the IF libraries.
This way, new authors
>will not have a great deal to learn; certainly not the whole
>library at once.
If they use the library as is. Some authors have commented that they
usually can't use the library as is; at some point, they have to change
it. We're back to the "two-language" problem again, with newbies.
Later, when an author decides to try their hand
>at something more unusual requiring more work on their part
>(eg. modelling distances, NPC emotions, etc) all they should need
>to do is look at the particular section of the library that
>handles that, select it when distilling/translating the library
>and read the docs on the wiki (which, being a wiki, would
>probably also include a discussion of exactly how best to use
>it). All this would ensure a fairly shallow learning curve.
>
I don't think the learning curve would be all that easy, and
this assumes a lot of cooperative work on the library.
>> 2) You're assuming that a library is fundamentally independent
>> from its language.
>
>Well, perhaps we need to distinguish between libraries that
>are necessarily language dependent, and this meta-library that
>I'm proposing. The meta-library would be written in a very high
>level meta-language that described things at a conceptual level
>rather than at a nitty-gritty implementation level.
>
Perhaps you should give an example of such a meta-language that
has achieved success in any field requiring general-purpose
programming. I fear you are dramatically underestimating the
difficulty of this project.
>> IMHO, a good library makes extensive use of language features.
>
>Well, a good translator can make extensive use of language
>features. There's no reason for the meta-library to preclude
>very clever language specific code being output by a translator.
Which means several high-quality optimizing back ends being
developed for the translator. That, once more, is a lot of work.
>The meta-language would be sufficiently high level that it would
>not require or conflict with any individual implementation language
>features. I expect the first few months of the project would be
>spent brainstorming what precise form this meta-language would
>take.
What you need to do to get this project started is come up with
at least a good sketch of what this meta-language would look like.
Define the 0.1 version of the language, write a few classes in
it, and describe how they will be translated into, at a minimum,
Inform and TADS 2. Don't worry that you'll get it wrong: this
sort of thing will require multiple design cycles to get it right,
and there's no reason you can't do the first few yourself.
>> If a language supports OO principles like classes and methods and
>> multiple inheritance, its library will look completely different
>> than that of a procedural language that only supports data structures,
>> which will in turn look different.
>
>It would be down to the translator to accomplish best use of the
>actual target language.
Again, you're assuming that the translator is a decent-quality
compiler. These aren't as big a deal as they used to be, but
they're still a great deal of work.
>> > I see two fairly intimidating challenges: 1) How to write a class
>> > hierarchy in a language independent way which is nevertheless
>> > relatively easy to cross compile into various real implementation
>> > languages.
>>
>> Not to mention that it has to be able to take advantage of
>> language-specific features, work around languages that have
>> no way of dynamically dispatching method calls etc.
>
>CFront manages it.
>
CFront compiles into precisely one real implementation language, not
several. (Unless it's been changed since I last looked.) Moreover,
CFront was a *lot* of work. Get a copy of Stroustrup's "Design and
Evolution of C++". It's a great book, even if you dislike C++.
That should give you some idea how hard it would be.
And, of course, this is only part of the project.
Perhaps what you should try doing is first designing a very-high-level
IF language, and implementing it. For your purposes, you'd have to
make sure it compiles well to other IF languages.
>> You'd basically have to implement a code generator that takes design
>> patterns and compiles them into a working program. I guess this could be
>> done, just like GCC has a front-end and a back-end so each programming
>
>Exactly. Okay, so it's by no means trivial, but that shouldn't stop us.
>
At this point, I'm inclined to ask who "us" is. If you're not willing
to put in real work, nobody else will. If you don't have the
determination to make your ideas work, nobody else will. If you don't
have the skill, then you really don't know what you're talking about
and there's no point in trying to follow your ideas.
Write a design document, and a sketch of non-obvious implementation
details. Come back with it and ask for comments and assistance.
That's the best advice I can give.
>> You, so far, want to generate a library for a whole flurry of
>> languages, all of which have different strengths and weaknesses
>> and feature sets, for an theretofore unspecified audience.
>
>Yes! And why not? It's a worthy goal that would help the entire
>community move forward.
So you say. You may be right, but I personally think that the
community would do better moving forward in other ways. I suspect
that there are a lot of people who agree with me. Convince us.
I think people are getting blinkered by
>language details instead of looking at the bigger picture.
I've seen too many "bigger picture" projects fizzle. Projects that
attempt to be all things to all people frequently fail and often
do not live up to expectations. I'd have to consider IBM's PL/I
language a relative success in doing that - and how often do you
see that in use? In contrast, Perl does some things extremely
well, and works well with other things, and is more successful
than PL/I ever was.
>If the combined expertise of this beautiful community could put
>their heads together and come up with a class design to encompass
>the state of the art in world modelling,
By the time the class design was done, the state of the art would
have changed. As long as people still kept pushing it, anyway,
rather than trying to freeze it.
and free themselves
>from the confines of particular languages and their particular
>libraries,
However, the languages and libraries are practical things that
do what people want them to do right now. Freeing people from
that means stripping them of their ability to do anything, in
the hope that what follows will be enough of an improvement.
People find this very scary.
The way to get around that is to offer them something that is
clearly a possible big improvement.
then the whole field could move rapidly forward.
>Not only would a great deal be learned in the process but,
>once the design was more or less complete, and the meta-language
>tried and tested, then new implementation languages could be
>designed to take full advantage of the meta-library. Eventually,
>little or no translation from the meta-language would be required
>because implementation languages would have caught up with the
>higher level concepts that the meta-library deals in.
>
You seem to be differentiating between the meta-language and the
implementation language. In actual fact, the meta-language
has to have the same capabilities as any implementation language,
and so if it existed there should be no difficulty with just
writing IF in it. Look at some existing libraries: they have
lots of specific code in them, and therefore a language that is
too high-level to write IF in would be too high-level to write
a good library in.
>> I think, what you should do is start making some choices:
>>
>> -> What languages (what kinds of languages?) do you want to support?
>
>All of them, but let's start with the most popular ones and add
>PDP-10 assembly at a later date. ;-)
>
A project this size needs phased implementation. "All of them"
is not a useful answer at this time.
>> -> What kinds of games do you want to support?
>
>Any that the community wishes to support. Someone, probably the
>proponent, would simply write the relevant part of the meta-library.
Right. You're the proponent here. Write part of it.
>In the case of a new genre, for instance, a parallel set of text
>could be written for the default responses. This would obviously
>mean that the text itself would need to be factored out into
>separate modules which the authors could select at the
>distillation phase.
>
One issue here is that a new genre would not be ripe for standardization.
You seem to be asking somebody who breaks new ground to write it up
neatly in a standard language, thus increasing the amount of work
involved. The abilities necessary to go out and do neat new things
are not really the abilities necessary to wrap things up in a neat
package. Consider the division between the "neats" and the "scruffies"
in artificial intelligence.
>> Which ones have you forgotten, and what will you do when you
>> find out about a forgotten one that needs significant changes to
>> the library to support?
>
>The meta-library would have to be designed with abstract base
>classes that could be overridden to support anything which the
>community would collectively regard as within the scope of what
>we understand as "Interactive Fiction".
>
This seems to me more of a pious wish than a design plan.
Moreover, the words "would have to be" do not necessarily imply
"can be". I seriously doubt that anybody knows how to design
the meta-language you keep talking about, and I'm not limiting
myself to the IF community.
>None of this presents an insurmountable obstacle.
>
However, I personally haven't seen people surmounting comparable
obstacles.
>Any other objections?
>
I've been giving them.
>Any support?
>
How about advice?
It seems to me that the critical part of this project is what you
call the meta-language. We have class libraries already, so we
know that's possible. Writing them in a meta-language as you
describe looks impossible to me.
So, what you need to do is work on the meta-language enough to
show that it is both possible and desirable.
At a minimum, do the following:
1. Write a proposed definition of such a language, or at least
enough of the language to get a feel for it.
2. Write part of a library in it. Give a rough sketch of how you
expect it to compile into at least two halfway popular IF languages.
3. Write "Cloak of Darkness" in it.
It would be nice to have a compiler of sorts for it, but that's not
strictly necessary for laying out the concepts.
Once you have that, post here again (at least if you still think it's
worth doing).
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Uli Kusterer
James Taylor <spam-block-@-SEE-MY-SIG.com> wrote:
> I think the issues you raise could be thrashed out by the group
> and workable solutions found. At the very least, many heads
> together would, most likely, produce a better thought out and
> more complete design than a single author could.
Which is exactly what is already happening with the TADS 3 library.
They have a mailing list set apart for discussion of library changes.
Even though Mike does most of the implementation (with folks like Kevin
supplying alternate implementation suggestions as needed), he has
constant feedback from people actually writing new games with adv3.
And Mike is proof of what David suggested. The beginnings of TADS lie
in one lone person sitting down and writing a new TADS, and a new
library. And that's why it works, even though there are hundreds of
other languages lying dead in the water on sourceforge.net
> Actually, I was rather thinking that the community could find a class
> hierarchy which along with carefully chosen library initialisation
> procedures would allow for radically altering certain aspects as
> desired by each prominent school of IF authoring.
Who would do this? Why?
Keep in mind that open source projects are hardly ever done just for
the fun of it. Most people create open source software because they need
a particular piece of software. This usually implies that there are much
more open-source tools for programmers, simply because programmers are
the people who are able to write this software themselves.
People who don't have this ability usually bite the bullet and buy a
piece of software.
Essentially, this means that you would need people willing to write the
different parts of the library. Now, why would they reinvent the wheel
in your language when there are almost complete languages which already
do what they want? What unique characteristics do you offer that
justifies re-implementing an existing library before they get to write
their extension?
> So, for instance,
> I could imagine selecting 1st person, 2nd person, present tense,
> past tense, menu conversation, ask/tell conversation, etc, as
> simply as saying "SetTense first_person;" or whatever.
TADS 3 does all of that already. Or at least there's support for that
in adv3. It even supports localization of the library and the parser.
> Clearly, it seems that we're going to need a preprocessing stage
> which takes all the stylistic selections of an author and generates
> a one-off library distillation in their chosen implementation language.
Whoa, don't get ahead of yourself! First you'd need a modular library.
You can manually package the most commonly used parts, and tell people
what's required for it all to run, and what can safely be deleted if
they're not using it. You don't need that automated until you've got a
huge library.
> Growing complexity is certainly a risk, but it is my hope that a
> class design can be made to do The Right Thing for mainstream
> games if you simply accept the defaults.
Finally a target audience: Mainstream games. Though it's still vague,
it's a good beginning. Trust me, you'll fall flat on your nose if you
don't know who your users will be. The most important thing in software
engineering is a list of the requirements. And these requirements come
from your potential users.
What benefit would your users have from using your library? So far, the
two target audiences I see, would be
1) people who want to switch between languages. They wouldn't have to
re-learn the library, if all that bothers them is the language's syntax.
But how many people really do that?
2) language authors. They could simply implement a couple of patterns in
the backend using their language, run the "library generator" and that's
it. They wouldn't have to come up with a library of their own.
However, do they really want to do that? Most languages are essentially
the same today. It's simply a matter of personal preference. Pros like
terse, logical languages that are similar to what they know (e.g. Pascal
or C), while beginners often want something a little more verbose and
friendly-looking, more english-like so they don't have to remember too
much domain knowledge. How will your library cope with that? A newbiie
might want to have UnmovableOpenableBox, while a pro may prefer
FixOpenCont because it's less to write, and it's really just a container
and not necessarily a box, and can also be used for bags, and thus the
name is more precise. Or even worse, if you want to port to ObjC, what
was game.userEntered( user, room ) suddenly becomes [game user: user
enteredRoom: room]; which can be a mess to properly auto-generate for
four or five parameters.
So, whatever you choose, half the language authors will turn away from
your library and roll their own *on principle* because your design
doesn't fit their target audience, or works badly with their language
syntax. Or your project's members will have to write each identifier in
a dozen different styles, which would mean the structure is the same,
but users would still have to re-learn.
And those authors who find your library would fit their choices? They
will realize that, if they choose your library, their unimportant
language will be the only thing that differentiates their development
system from others. Which may just spell the death sentence to their
language.
> This way, new authors
> will not have a great deal to learn;
Well, as David said, new authors will not want to learn two languages
at once.
> Well, a good translator can make extensive use of language
> features. There's no reason for the meta-library to preclude
> very clever language specific code being output by a translator.
There isn't? First and foremost, who's going to write that clever
logic? In the end, that may be just as much effort as just taking the
design of e.g. adv3 and porting it to compile on the Inform compiler.
So, we already have time and manpower constraints (and womanpower, if
you're so inclined), and motivation. But I'm repeating myself.
> take. In the end, I imagine that it would be integral to the
> hierarchical structure of the wiki, and eminently human readable
> whilst also being sufficiently machine readable for the distiller
> and translators to work on.
I don't really get what the Wiki has to do with this. A Wiki is a tool,
like Instant Messages, E-Mail and such stuff. It lends itself to
enforcing modularity, but hierarchical is the least I'd characterize it
as (cross-referenced would be more like it). I think you're getting
sidetracked here.
> Another example is the CFront translator
> which takes C++ as input and generates straight C as output.
> Anything's possible.
You may have read about CFront's shortcomings, and why Mr. Stroustrup
decided to implement it as a compiler in the end. Not to mention David's
arguments about C only being one language.
> > Not to mention that it has to be able to take advantage of
> > language-specific features, work around languages that have
> > no way of dynamically dispatching method calls etc.
>
> CFront manages it.
Yes, but nobody actually has to maintain the code CFront generates. The
user only sees the C++ code, just like users of a C compiler never get
to see the assembly-language code, and few people voluntarily compile C
code to assembler to then change around or work with the assembly
instructions. Keep in mind that machine-generated code in general has
the habit of becoming rather unreadable.
If you were simply writing your own IF IDE, this wouldn't be a problem,
because the game would be written in your meta-language, but then I'd
wonder why you're not just targeting the Z-Machine or the T3 VM directly?
> Yes! And why not? It's a worthy goal that would help the entire
> community move forward.
You think it's a step forward. Playing the devil's advocate, I would
say it's a radical step backward. It sacrifices diversity. If I don't
like the "community IF library", there may be no other alternative for
me. If someone writes a virus that uses "community IF library" classes,
it would quickly spread across all languages and interpreters. (okay,
that last one's a bad example)
For more arguments, look at any Microsoft anti-trust argumentation ;-)
> If the combined expertise of this beautiful community could put
> their heads together and come up with a class design to encompass
> the state of the art in world modelling, and free themselves
> from the confines of particular languages and their particular
> libraries, then the whole field could move rapidly forward.
But who would write interactive fiction then?
> Eventually,
> little or no translation from the meta-language would be required
> because implementation languages would have caught up with the
> higher level concepts that the meta-library deals in.
What for? Why is an abstract meta-language better for game authors than
the current ones? (I'm not being snide, this is a genuine question)
There have been many attempts at creating more high-level languages.
What would the advantages of going via the meta-library be over starting
with a clean slate and designing one of those?
> All of them, but let's start with the most popular ones and add
> PDP-10 assembly at a later date. ;-)
Ok, the most popular ones. Then *limit yourself to those* at first.
There's nothing wrong with looking at other languages (especially the
more arcane ones) to ensure you don't do anything to prohibit
translation to those, but you have to set short-term goals for such a
large project. Start with a generic framework and implement it for one
language. Implement the hardest stuff for that language, then pick a
second one. After you've tried three representative examples, go back
and pick the one that promises to be the most trouble and finish your
project for that. Then move on and finish a second language.
Go on, step by step, define milestones. Once you have a working
prototype with two rather different languages, people will see what it
is, that it works and you have a chance of people actually joining.
> NPCs, etc, then the translator merely chooses the most efficient
> way to implement this in the target language. I see no inherent
> reason why the translator cannot produce code to the same quality
> that an expert in the target language would produce to implement
> those same concepts. Indeed, I rather expect the translators to
> draw upon language specific code templates written by just such
> experts to implement the high level concepts of the meta-library.
The problem is that it's much harder for a pro to write a template
based on a solution than to actually implement the solution himself. Not
all algorithms are easily adapted by doing a search-and-replace.
Yes, it is possible. But ask yourself: Is it worth it? Do we really
need another level of indirection? If you think so, by all means, go
ahead.
But especially after your comment of eventually turning the
meta-language into a real one, I'm not sure I understand where you're
headed, what you want to do.
I hope I've helped give you a better picture of what you're about to get
yourself into & Cheers,
-- M. Uli Kusterer
http://www.zathras.de/
Kevin Forchione
news:3f69f520$0$42047$a186...@newsreader.visi.com...
> So you say. You may be right, but I personally think that the
> community would do better moving forward in other ways. I suspect
> that there are a lot of people who agree with me. Convince us.
I'm in agreement with David.
Better yet, people that want to develop a "better mousetrap" should first
write a replacement library for TADS 2 or Inform. If you can't do that, then
you're certainly talking through your hat. Sure, the library won't be your
dream language, but it'll earn you some credibility, give you a working
platform to prototype a few of your ideas, get a feel for the size of the
beast, and a feel for what kind of user base you might have.
Roll up your sleeves. IF is still a hobbyists ambition. Be a pioneer, but
realize you'll have to be a Thomas Edison, not an IBM.
--Kevin
Uli Kusterer
James Taylor <spam-block-@-SEE-MY-SIG.com> wrote:
> If the combined expertise of this beautiful community could put
> their heads together and come up with a class design to encompass
> the state of the art in world modelling, and free themselves
> from the confines of particular languages and their particular
> libraries, then the whole field could move rapidly forward.
James,
I forgot to mention: I don't agree with your assessment that there is a
need to 'free ourselves from the confines of particular languages and
their libraries'. I see it as an advantage.
For years, everyone had to reinvent the wheel when they wanted to write
an adventure. Now, we have the choice. We can use Inform, TADS, Hugo,
ALAN, ADRIFT and a whole slew of other systems, all of which already
take care of the basic world model, and each of them has an advantage
the others don't have. And depending on the game I'm writing, the
confines are usually hardly noticeable, and if they are I can choose
another language.
Cheers,
-- Uli
http://www.zathras.de
David A. Cornelson
news:ant14152...@nospam.demon.co.uk...
> Forgive me if this is an oft repeated suggestion. I had a google for
> "class library" and the only similar post I found was back in 1996:
>
> http://groups.google.com/groups?th=942974647a381247
>
> It occurred to me that the various IF programming languages each
> come with their own class libraries and, indeed, that a good
> library would seem to be *the* critical part of any IF authoring
> system. The problem is that constructing a reasonably complete
> library is a huge undertaking, and it is arguable that no single
> language designer could ever hope to perfect such a thing. I've
> certainly heard people gripe about library limitations, and the
> wealth of third party additions underlines those shortcomings.
> Furthermore, the existing libraries are not interchangeable.
>
One of the things I'd like to architect into IF# would be the ability to
create the library in such a way that there is clear separation between
everything, yet a definition exists that makes the various parts function
together.
So James has a cool idea here that I would take a different direction.
Is there a way to develop the _design_ of an IF library that is wholly
separate from any implementation and that meets a wide range of criteria?
I'm not talking UML diagrams but simple process diagrams that show the inner
workings of the parser and library...
Just a thought.
Dave
Kevin Forchione
message news:1eucnfiP0vW...@speakeasy.net...
> Is there a way to develop the _design_ of an IF library that is wholly
> separate from any implementation and that meets a wide range of criteria?
>
> I'm not talking UML diagrams but simple process diagrams that show the
inner
> workings of the parser and library...
An interesting question, requirements vs implementation details, but the
inner workings of the parser and library would seem to require some level of
implementation detail. As soon as we start looking into modeling game
objects we are dealing with implementation details: certain languages are
better suited than others; certain datastructures are better suited than
others.
There are other issues as well. The breadth of the spectrum between the
simulation and exception nature of the interactive fiction probably mean
that we're going to be hard pressed to position a library that meets the
needs of most authors, without it being fairly basic in nature. TADS 3 is
far more sophisticated than TADS 2. In order to make a modification to the
basic library of TADS 3 more must be understood in order to achieve a smooth
and efficient integration. And there will be certain desired effects that
will be incompatible with the specific details of an implementation, no
matter how flexible or modular that implementation is. You run up against
the most powerful psychological issue -- IF as an art form must always be
pushing the envelop -- and to do that, as an artist, I've got to break and
bend the rules. Implementation is something an artist works with and fights
against.
My thoughts are that it's a good thing that we have Inform, TADS 2 & 3,
Alan, Hugo, ADRIFT, et al.
--Kevin
David A. Cornelson
news:jEtab.4102$wf3.77...@newssvr13.news.prodigy.com...
>
> An interesting question, requirements vs implementation details, but the
> inner workings of the parser and library would seem to require some level
of
> implementation detail. As soon as we start looking into modeling game
> objects we are dealing with implementation details: certain languages are
> better suited than others; certain datastructures are better suited than
> others.
>
So then the next question is:
Can we develop a set of test cases or assertions that identify what an
acceptable IF Parser and Library must accomodate in order to be considered
in the same breath as TADS 1,2,3, Inform, or Hugo?
This might seem to be a terribly long list of tests, but it's not infinite,
and it would go a long way to building a basis for IF parser and library
design and development. The parsing tests would be less tedious. The library
assertions would be somewhat subjective, but they could be rated from
critical to unimportant; critical being "[take] <object> moves item to
{inventory}" and unimportant might be something too specific, like "[sell]
<object>".
I can setup another Wiki if anyone is interested in following up on this...
Dave
Benjamin Fan
> So, whatever you choose, half the language authors will turn away from
> your library and roll their own *on principle* because your design
> doesn't fit their target audience, or works badly with their language
> syntax.
While I don't want to discourage anyone from implementing such a
class library, I agree that the common library might either be too complex
or too simple (and limiting). For example, darkness-- how do you model it?
I can think of several different ways: locations are either dark or not,
there are different gradiations of darkness, darkness is dependent on time
and day, darkness is a function of some darkness property, darkness is a
function of the absence of some lightness property, darkness is a function
of time of day and day of year and cloudiness and pollution level, darkness
is dependent upon character's ability to see, etc.
I also suspect that a common library might contribute to IF that is
unoriginal in terms of "gameplay" and "feel". Not necessarily a bad thing,
since originality could be expressed within the other aspects of an IF
work, and perhaps the negatives would be offset by the positive of increased
numbers of authors.
Ben
--
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
David Thornley
David A. Cornelson <david dot cornelson at iflibrary dot com> wrote:
>
>So then the next question is:
>
>Can we develop a set of test cases or assertions that identify what an
>acceptable IF Parser and Library must accomodate in order to be considered
>in the same breath as TADS 1,2,3, Inform, or Hugo?
>
here. If we're talking about an actual language design, there's
"Cloak of Darkness" and "Adventure".
Aside from that, look at the "how to play IF" sections in lots of
games out there. You know, the ones that list commands like
"hit troll with axe" and "george, light lantern". Those would at
least be a good place to start.
>This might seem to be a terribly long list of tests, but it's not infinite,
>and it would go a long way to building a basis for IF parser and library
>design and development.
Are you talking about something closer to formal verification tests
or design guidelines? I don't see how to do formal verification in
a useful way, personally, without being language-specific.
If what you're looking for is a formal list of things the language
designer must keep in mind, then it might be useful. On the other
hand, there's not many IF languages being designed.
David A. Cornelson
>
> Are you talking about something closer to formal verification tests
> or design guidelines? I don't see how to do formal verification in
> a useful way, personally, without being language-specific.
>
> If what you're looking for is a formal list of things the language
> designer must keep in mind, then it might be useful. On the other
> hand, there's not many IF languages being designed.
Somewhere between formal verification tests and formal lists of things that
a parser+library (i too believe these are inseperable) need to accomodate.
Eventually, there will be a set of patterns and a set of base specific
things you'd include in a world model (walls, directions, doors, etc).
I think this would be a "nice to have", somewhat like the glossary that
Dennis Jerz started (and I need to get going again) but focused on the
"ability" of an IF system.
Dave
Kevin Forchione
message news:8kCdnZN696h...@speakeasy.net...
> "David Thornley" <thor...@visi.com> wrote in message
> news:3f6b0df5$0$168$a186...@newsreader.visi.com...
> >
> Somewhere between formal verification tests and formal lists of things
that
> a parser+library (i too believe these are inseperable) need to accomodate.
> Eventually, there will be a set of patterns and a set of base specific
> things you'd include in a world model (walls, directions, doors, etc).
Walls, directions, doors, etc are important model world concepts, but the
nexus between the library and parser consists more of questions regarding:
* what constitutes containment in the model world
* how is scope defined, and is it associated with "sense-passing"? (i.e.
light/dark, visibility, reachability, etc)
* does the model world have a notion of "indistinguishable" objects?
* does the model world have a notion of "numbered" objects?
* does the model world have a notion of "aggregated" objects? "proxy"
objects?
* does the model world have a notion of actor knowledge?
Along with these questions, there are concerns with the idea of
preconditions to actions, nested actions, recursive actions, and
verification of the logicalness of actions prior to execution.
No doubt one can write a program in Basic that could exactly mirror the
inputs and outputs of an Inform or TADS game. But the inner workings of the
library and parser, the subtlety of the model world, are things that aren't
going to be addressable through a serious of inputs and outputs.
For instance, I return again to the level of abstraction in the model world.
<<knock on door>> may produce the same result between Infocom's "Sherlock"
and a TADS 3 port, but TADS 3 allows the author to abstract the level of
implementation, so that sound propagation is responsible for the answering
of the door, rather than a simple redirection of messages. If Mrs Hudson is
not able to hear the knocking at the door, for example, she won't answer it.
And this can be abstracted to any door, and any actor. What's more, the
actual sensing of the door itself is not required, only the sensing of the
sound propagation. So if Mrs. Hudson is in the hall and hears a knocking,
but the door is not sensible, she *may* respond to the sound as signifying a
visitor at the door, or may remark on the peculiar rappings in the walls
that seem to haunt this house.
You see what I'm getting at, I hope...
--Kevin
David A. Cornelson
>
> For instance, I return again to the level of abstraction in the model
world.
> <<knock on door>> may produce the same result between Infocom's "Sherlock"
> and a TADS 3 port, but TADS 3 allows the author to abstract the level of
> implementation, so that sound propagation is responsible for the answering
> of the door, rather than a simple redirection of messages. If Mrs Hudson
is
> not able to hear the knocking at the door, for example, she won't answer
it.
> And this can be abstracted to any door, and any actor. What's more, the
> actual sensing of the door itself is not required, only the sensing of the
> sound propagation. So if Mrs. Hudson is in the hall and hears a knocking,
> but the door is not sensible, she *may* respond to the sound as signifying
a
> visitor at the door, or may remark on the peculiar rappings in the walls
> that seem to haunt this house.
>
> You see what I'm getting at, I hope...
>
If I'm reading you right, you're saying that even test cases wouldn't show
the type of "abilities" that IF require since the code has an artistic
nature to it that cannot be easily defined. Or...it's not that a particular
command can succeed or fail, it is the implementation of its success or
failure that make up the ability of an IF language.
Dave
Kevin Forchione
> "Kevin Forchione" <ke...@lysseus.com> wrote in message
> news:gaGab.519$rd4...@newssvr29.news.prodigy.com...
> >
> the type of "abilities" that IF require since the code has an artistic
> nature to it that cannot be easily defined. Or...it's not that a
particular
> command can succeed or fail, it is the implementation of its success or
> failure that make up the ability of an IF language.
More importantly, test cases by themselves won't reveal the complexity or
subtlety of the parser/library. Why? Because any sequence of input/output
can simply be hardcoded to meet a given scenario. Any finite series of test
cases can be programmed for, but we probably shouldn't judge a system
successful by whether it meets those criteria.
--Kevin
David A. Cornelson
>
> More importantly, test cases by themselves won't reveal the complexity or
> subtlety of the parser/library. Why? Because any sequence of input/output
> can simply be hardcoded to meet a given scenario. Any finite series of
test
> cases can be programmed for, but we probably shouldn't judge a system
> successful by whether it meets those criteria.
>
Come on. There _has_ to be a way to judge these things. Is it possible that
a test case is actually a game? Like Adventure or Toyshop?
Dave
Benjamin Fan
> "David Thornley" <thor...@visi.com> wrote in message
> news:3f69f520$0$42047$a186...@newsreader.visi.com...
>
> > So you say. You may be right, but I personally think that the
> > community would do better moving forward in other ways. I suspect
> > that there are a lot of people who agree with me. Convince us.
>
> I'm in agreement with David.
>
> Better yet, people that want to develop a "better mousetrap" should first
> write a replacement library for TADS 2 or Inform. If you can't do that, then
> you're certainly talking through your hat.
"Talking through your hat"? The tone seems disproportionate for
someone who was just suggesting an worthy but idealistic "what-if?"
project and asking for feedback.
Technically, I agree that it would be difficult to have a common
library which can be used with existing system libraries. However, it
may be that if such a common library were to be written, the existing
IF systems and/or their libraries would get re-written to work with the
common library. That is, the common library would be seen as the new
standard and people would jump to change the existing systems in order
for them to work with it. (But, I think that this is unlikely to
happen.)
Kevin Forchione
news:9ea00d5e.03091...@posting.google.com...
> "Kevin Forchione" <ke...@lysseus.com> wrote in message
news:<8wpab.4073$Nl1.69...@newssvr13.news.prodigy.com>...
> > "David Thornley" <thor...@visi.com> wrote in message
> > news:3f69f520$0$42047$a186...@newsreader.visi.com...
> >
> > > So you say. You may be right, but I personally think that the
> > > community would do better moving forward in other ways. I suspect
> > > that there are a lot of people who agree with me. Convince us.
> >
> > I'm in agreement with David.
> >
> > Better yet, people that want to develop a "better mousetrap" should
first
> > write a replacement library for TADS 2 or Inform. If you can't do that,
then
> > you're certainly talking through your hat.
>
> "Talking through your hat"? The tone seems disproportionate for
> someone who was just suggesting an worthy but idealistic "what-if?"
> project and asking for feedback.
You're probably right about the tone. But the suggestion is still a very
good one.
--Kevin
David Thornley
Benjamin Fan <junkaccou...@yahoo.com> wrote:
>"Kevin Forchione" <ke...@lysseus.com> wrote in message news:<8wpab.4073$Nl1.69...@newssvr13.news.prodigy.com>...
>> "David Thornley" <thor...@visi.com> wrote in message
>> news:3f69f520$0$42047$a186...@newsreader.visi.com...
>>
>> > So you say. You may be right, but I personally think that the
>> > community would do better moving forward in other ways. I suspect
>> > that there are a lot of people who agree with me. Convince us.
>>
>> I'm in agreement with David.
>>
>> Better yet, people that want to develop a "better mousetrap" should first
>> write a replacement library for TADS 2 or Inform. If you can't do that, then
>> you're certainly talking through your hat.
>
> "Talking through your hat"? The tone seems disproportionate for
>someone who was just suggesting an worthy but idealistic "what-if?"
>project and asking for feedback.
>
with Grand Projects....</geezer>
There are several problems I have with the original proposal, and I
will admit that some of them may be perception.
First, the tone of the posting suggested to me that the poster was
proposing that other people do a large amount of free work to
implement his idea, without suggesting that the poster would do
some. Therefore, my statement that no such project can work unless
the proponent is willing to put in serious work before getting
anything going.
Second, it sounded like "blue sky", "wouldn't-it-be-neat" talk
from somebody who had no idea how lots of it could be accomplished.
For example, consider the meta-language. The idea seemed to be
that it could be as expressive as TADS or Inform while being very
high-level. Now, something like this would be wonderful, but
I've never seen any such project work. VHL languages either
do very well in some specialized domain, and work badly or not
at all outside it, or they are failures. This suggests to me
that the poster is, indeed, talking through his hat. Therefore,
my suggestion that the poster try designing such a language.
Most likely, this would mean the poster would get discouraged.
It could conceivably result in him making a breakthrough that
would benefit the rest of the world (not just the IF part),
which is what he'd need to do to implement his idea.
Third, it didn't fit the actual needs of the community. Newbies
would be frightened off by having to deal with two languages
right up front.
So, it seemed to me that we were dealing with somebody who knew
neither software development, nor software, nor the needs of IF.
Moreover, it seemed phrased more like "this is what people should
do" than "what do you think of this idea?"
So, I don't see any point in going ahead with this proposal,
and I'm not thrilled with what I read of the original poster.
Now, the poster may decide to show me up by coming up with something
that I claimed impossible. That would be great. If he succeeded,
that would be wonderful. I'd have a good deal of respect for a
genuine try that ended in utter failure.
There are proper ways to post those sorts of ideas.
One is to say "What do you think of this?". It shows a certain
amount of humility, or perhaps some lack of arrogance.
One is to say "This is what I've done so far, and here's what
I think remains to be done. I think it looks promising, and I
could use some help if anybody else does." This shows dedication
and skill. One advantage of this is that it shows that the
project, unless inherently impossible, is likely to be carried
through, and so no volunteer is going to wind up with tens of
hours of work and code and be told, "No, I lost interest in that
project last week."
David Thornley
David A. Cornelson <david dot cornelson at iflibrary dot com> wrote:
>"Kevin Forchione" <ke...@lysseus.com> wrote in message
>news:AVPab.592$lg7...@newssvr29.news.prodigy.com...
>>
>> More importantly, test cases by themselves won't reveal the complexity or
>> subtlety of the parser/library. Why? Because any sequence of input/output
>> can simply be hardcoded to meet a given scenario. Any finite series of
>test
>> cases can be programmed for, but we probably shouldn't judge a system
>> successful by whether it meets those criteria.
>>
assumption that the answers aren't hard-coded, that the code actually
does the right sort of thing to find them. In general, if the
implementor knows what the tests are going to be, the implementor
can cheat. Back when everybody was using a certain function to test
C implementations (Fibonacci numbers? I forget) there were rumors that
some compilers simply checked to see if this was that function and
spat out stored hand-written and extremely optimized machine code.
However, in most cases we can recognize whether a system is a cheat
or not. Unlike, say, C compilers, the source is normally available
(indeed, the library source has to be available in many systems),
and it's easy to see whether the system response is faked.
>
>Come on. There _has_ to be a way to judge these things. Is it possible that
>a test case is actually a game? Like Adventure or Toyshop?
>
Cloak of Darkness is the current standard.
However, I don't see that it's feasible to have automatic checking; it
has to be done by hand. For example, there are a few steps to win
Cloak of Darkness, and one could write a transcript of a winning game
and a losing game. However, to test a system one would like to see
if there is some sort of reasonable response to "eat cloak" and the
like. If this is to be automatically checked, that's a constraint
on the sort of default messages that can be put into a system.