Inform 7, IF Dialogue, Data Structures, and Syntax
ChicagoDave
to write dialogue. But I want to write dialogue in a way that shows
that the NPC's remember what they've seen and heard or have already
mentioned.
Upon reviewing this subject there doesn't seem to be a fluid way of
implementing dialogue, even in Inform 7.
It seems to be a very complex programming problem without a "natural
language" solution.
If you're dealing with one or two levels of dialogue, I think Eric
Eve's conversation extensions will suffice, but if you have a
intertwined dialogue between several NPC's and the PC, things get very
complicated very fast.
I'm not even sure if there are data structures within Inform that can
properly handle interwoven branches of response dialogue.
I can't determine if "knowledge" should be built into the standard
library and responses created as kinds, or if there is some other
elegant solution, but I do believe that dialogue poses a problem that
the natural language of I7 has not addressed.
I have proven to myself that building a world model is enormously
easier using I7, but now I'm trying to tie loose ends together in my
story with sophisticated dialogue between characters and that
simplicity I saw before has evaporated.
I now stand frozen trying to figure how to do dialogue for NPC's that
have a memory.
I suppose for stories that don't rely too much on dialogue, this is not
as important, but for stories that do and will rely on dialogue, this
is critical.
Do I setup a memory system for NPC's?
Do I build event kinds that can be reviewed before responding?
Is there a way to centralize the processing of responses instead of
writing an Instead clause for each portion of dialogue?
Do I need to use tables?
All of these questions are giving me a headache.
Anyone else run into this issue?
David C.
Neil Cerutti
> So I'm in the lovely phase of developing a couple of games
> where I want to write dialogue. But I want to write dialogue in
> a way that shows that the NPC's remember what they've seen and
> heard or have already mentioned.
>
> Upon reviewing this subject there doesn't seem to be a fluid
> way of implementing dialogue, even in Inform 7.
There isn't one built-in, at any rate. This is a tall order, I
think.
> It seems to be a very complex programming problem without a
> "natural language" solution.
>
> If you're dealing with one or two levels of dialogue, I think
> Eric Eve's conversation extensions will suffice, but if you
> have a intertwined dialogue between several NPC's and the PC,
> things get very complicated very fast.
>
> I'm not even sure if there are data structures within Inform
> that can properly handle interwoven branches of response
> dialogue.
I can be built, of course. Whether or not it can be done with
reasonable effort will fall out through your efforts, I guess.
> I now stand frozen trying to figure how to do dialogue for
> NPC's that have a memory.
>
> I suppose for stories that don't rely too much on dialogue,
> this is not as important, but for stories that do and will rely
> on dialogue, this is critical.
>
> Do I setup a memory system for NPC's?
> Do I build event kinds that can be reviewed before responding?
> Is there a way to centralize the processing of responses instead of
> writing an Instead clause for each portion of dialogue?
> Do I need to use tables?
>
> All of these questions are giving me a headache.
>
> Anyone else run into this issue?
Not yet. Can you go into more detail? What exact knowledge will
each NPC require? Knowledge of topics only, or knowledge of
topics plus objects and rooms?
--
Neil Cerutti
Emily Short
ChicagoDave wrote:
> So I'm in the lovely phase of developing a couple of games where I want
> to write dialogue. But I want to write dialogue in a way that shows
> that the NPC's remember what they've seen and heard or have already
> mentioned.
>
> Upon reviewing this subject there doesn't seem to be a fluid way of
> implementing dialogue, even in Inform 7.
>
> It seems to be a very complex programming problem without a "natural
> language" solution.
This sounds to me more like a design issue than a syntax issue.
Before you decide how to implement, you need to figure out what exactly
you want this system to do: what kinds of information you're keeping
track of, and how *much* information you're tracking at each level.
Once you've figured that out, it will be easier to select appropriate
structures in order to represent these things.
Some questions I would ask:
How many facts do you imagine keeping track of? (Not exact, just a
ballpark estimate. Are we talking about five? fifty? five hundred?)
-- Do you need to model abstract knowledge that the NPCs have (e.g.,
that Joe is skinny), or are you mostly concerned about keeping track of
what game events have occurred? (I would generally say that factual
modeling of the former kind is usually NOT useful unless you are
planning to have some simulation of NPC reasoning or you plan to have
NPCs learn things and communicate new knowledge during the game.)
-- Can the conversation context you're interested be modeled in terms
of plot stages? That is, are you mostly interested in making sure that
certain comments occur only at specific scenes in your game, or is the
flow of cause and effect less discrete than that? This may determine
whether you can keep track of previous events simply with scenes and
the like, or whether you want to write a separate system to track what
has occurred.
How many things-to-say do you have in mind? (By this I have in mind the
actual reply that the NPC gives in response to a question -- I usually
call these quips.)
-- How rigorous do you want to be about preventing people from
repeating themselves? This may determine whether you need to model
responses in a way that allows them to be flagged for use/reuse.
-- If you want to have prerequisite requirements for saying specific
things, are these prerequisites all going to be similar in nature? That
is, does the availability of a given quip generally depend on whether
another quip has been said already? Or are you interested in being able
to test, freely, any aspect of the game state? In the former case, I
might handle dependence as a relation between quips ("X requires Y" so
that X can be said only when Y has been marked as used); in the latter,
I might endow quips with individual rules to determine whether they're
available.
How many separate topics of conversation will there be? (By topic I
mean "JOE" in the sentence "ASK JENNIFER ABOUT JOE".)
-- Do these topics of conversation mostly correspond to objects inside
the game world, or are they mostly abstract, or a mixture of both? This
may determine whether you want to make your ASK verb primarily deal
with objects rather than with textual keywords.
As a general rule of thumb: if you expect to have many of a given kind
of thing in your model and/or you expect to keep track of relatively
little state information about that thing, it may make sense to use
tables: they are compact, memory-wise. If you expect to keep track of
lots of information about a thing, it may make sense to use objects. If
there's a one-to-one correspondence between elements in your model
(e.g., there is only ever one thing to say about a given topic; or, a
given piece of factual information is only represented in one kind of
comment), then it makes sense not to model both elements individually;
represent them once and be done with it.
For what it's worth (and I am not saying you will necessarily find this
helpful, but it's there if you think it might), I recently put up an
article that goes into more depth than my earlier stuff about NPC
conversation modeling -- pretty much exactly this issue, in fact.
(http://emshort.home.mindspring.com/Site/Conversation.html)
ChicagoDave
> (http://emshort.home.mindspring.com/Site/Conversation.html)
Gulp.
Okay, that was probably way more information than I expected, but very
helpful in the sense that the problem is known and has a clear
definition.
We also have some solutions.
I guess I need to clearly define my needs and develop a solution based
on those needs and then see if there's a way to simplify it for future
development.
My idea of a basic reusable conversation system would use ASK/TELL and
allow the author to tag concrete actions as something a player might
know. So not necessarily knowledge of a topic per se, but knowledge of
a thing, the state of a thing, the fact that a things state has
changed, the location of a thing, the proximity of a thing, or the
usage of a thing.
It would also allow the author to define logical trees of abstract
conversation which have nothing to do with game state other than
knowing that the player has already asked a question and is delving
deeper into a particular topic.
I'm not just crying out for someone to write this for me...I'm actively
trying to learn how to build something appropriate for long-term use.
What I would like to see are seminal examples of varying conversation
types that have highly simplified implementations within Inform 7.
David C.
JDC
ChicagoDave wrote:
> I'm not just crying out for someone to write this for me...I'm actively
> trying to learn how to build something appropriate for long-term use.
> What I would like to see are seminal examples of varying conversation
> types that have highly simplified implementations within Inform 7.
I just finished something with a (pretty basic) conversation system
which seemed significantly easier to do in I7 than it would have with
I6 (I just sent this to you, in fact, as entry in the MCDream II
minicomp; hopefully it got to you).
I assigned a table to each NPC, with topic and reply columns. I could
then swap out the tables after universally significant events (namely
scene changes), or change individual reply entries for individual NPCs
in response to local events. I also used relations to keep track of
which topics had been discussed by which characters, and which were
relevant.
Like I said, pretty basic (hardly seminal) but it was very simple to
code in I7 and can give at least a minimal semblence of NPC knowledge.
-JDC
Michael Martin
> My idea of a basic reusable conversation system would use ASK/TELL and
> allow the author to tag concrete actions as something a player might
> know. So not necessarily knowledge of a topic per se, but knowledge of
> a thing, the state of a thing, the fact that a things state has
> changed, the location of a thing, the proximity of a thing, or the
> usage of a thing.
You can actually get a lot of mileage out of the fact that your quips
in I7 can include conditionals and stuff inside the strings. My WIP
has a fair number of quips that look vaguely like "[if the ordeal is
known]'Wow, that's terrible.' 'Yes.'[otherwise](You may know about
that topic, but your character doesn't yet.)" Most commonly, this was
to make sure that actions were only being narrated if the character
acting could be seen.
--Michael
ChicagoDave
>
> This sounds to me more like a design issue than a syntax issue.
>
> How many facts do you imagine keeping track of? (Not exact, just a
> ballpark estimate. Are we talking about five? fifty? five hundred?)
As an author, I don't really know how complex my dialogue will be until
I start writing it. So I guess the solution here would be that I need
to script my dialogue before addressing how it will be implemented in
I7.
> -- Do you need to model abstract knowledge that the NPCs have (e.g.,
> that Joe is skinny), or are you mostly concerned about keeping track of
> what game events have occurred?
I would like both. I want to base some dialogue on physical world
modeling and other dialogue as a way to expand the emotion, background
story, or characterization of the NPC's, their thoughts, and feelings.
I also see abstract dialogue as the best possible way to offer hints
and help. It's my belief that all solutions should have "in game" hints
from the environment or characters. This is done through descriptive
scenery or via, ahem, dialogue.
> -- Can the conversation context you're interested be modeled in terms
> of plot stages?
I don't know. I have successfully avoided the scene capabilities so
far, but that might come in handy yet.
> How many things-to-say do you have in mind? (By this I have in mind the
> actual reply that the NPC gives in response to a question -- I usually
> call these quips.)
Again, as an author, I'd prefer not to need to know this and write as
I'm creating.
> -- How rigorous do you want to be about preventing people from
> repeating themselves? This may determine whether you need to model
> responses in a way that allows them to be flagged for use/reuse.
I want logical conclusions and responses at all times.
> -- If you want to have prerequisite requirements for saying specific
> things, are these prerequisites all going to be similar in nature?
No. The prereq's may be world model or abstract.
> How many separate topics of conversation will there be? (By topic I
> mean "JOE" in the sentence "ASK JENNIFER ABOUT JOE".)
No clue.
Overall I have this sneaking suspicion that dialogue will continue to
be a thorn in my side. But I will have to resolve this issue to the
best of my ability. I can't see how productive an IF author I can be
unless I can continue to attack a story in my head without pause for
_too much_ logical construction.
David C.
Adam Thornton
ChicagoDave <david.c...@gmail.com> wrote:
>I'm not just crying out for someone to write this for me...I'm actively
>trying to learn how to build something appropriate for long-term use.
>What I would like to see are seminal examples of varying conversation
>types that have highly simplified implementations within Inform 7.
I'm using a modified version of example 206, "Farewell."
I toyed briefly with doing this with real objects rather than text
strings but the scoping problems got grotesque. What I have is cheesy
but serviceable. Basically each person has a conversation table and a
default reply (with sane, if boring, defaults for each of these).
Then Stetson (an NPC) has something like:
Table of Stetson's Chatter
topic reply summary turn stamp
"Mylae/ship/ships" "'Yup. I remember it well, buddy. That sure was
something, wasn't it?'" "he remembers Mylae vividly" --
Adam
Emily Short
ChicagoDave wrote:
> > Emily Short wrote:
> >
> > This sounds to me more like a design issue than a syntax issue.
> > Some questions I would ask:
> >
> > How many facts do you imagine keeping track of? (Not exact, just a
> > ballpark estimate. Are we talking about five? fifty? five hundred?)
>
> As an author, I don't really know how complex my dialogue will be until
> I start writing it. So I guess the solution here would be that I need
> to script my dialogue before addressing how it will be implemented in
> I7.
Well, maybe. I'm talking about very ballpark estimates here, not an
exact count.
Still, it probably wouldn't hurt to map out one conversation/piece of
dialogue you envision having in the game, and then see what that
suggests to you about your needs; maybe poke at the existing examples
and extensions and see what you like and don't like about their
implementations; go from there.
steve....@gmail.com
> Upon reviewing this subject there doesn't seem to be a fluid way of
> implementing dialogue, even in Inform 7.
"Even" in I7? You're under the impression that this should be easier in
I7, in principle?
> I do believe that dialogue poses a problem that
> the natural language of I7 has not addressed.
It sounds to me you're considering "the natural language of I7" as a
magic wand, and you're pointing it at things and you're surprised that
it doesn't work. Maybe you should re-think a little.
By the way, TADS 3 has three well-developed conversation interfaces,
and one quite powerful rule-based topic-resolution system, and a couple
well-developed knowledge/memory rubrics -- and it's far easier to
program in.
> I have proven to myself that building a world model is enormously
> easier using I7
Uh, as opposed to what? (N.B.: all standard IF libraries come with
"world model" included.)
> but now I'm trying to tie loose ends together in my
> story with sophisticated dialogue between characters and that
> simplicity I saw before has evaporated.
Oh. Well, will you permit me to use you as an example of a user who is
initially amazed by I7, but then finds things evaporating? You yelled
at me for warning you.
> I now stand frozen trying to figure how to do dialogue for NPC's that
> have a memory.
I think it's the same no matter what major programming project you're
working on. If you wanted to do some really serious
world-modeling/simulation work, you'd have the same freezing problem.
ChicagoDave
> "Even" in I7? You're under the impression that this should be easier in
> I7, in principle?
>
> > I do believe that dialogue poses a problem that
> > the natural language of I7 has not addressed.
>
> It sounds to me you're considering "the natural language of I7" as a
> magic wand, and you're pointing it at things and you're surprised that
> it doesn't work. Maybe you should re-think a little.
Not a magic wand. Dialogue constructs are a layer of
syntax/code/definition that has yet to see an optimal approach. I think
Emily's essay clearly defines the problems. I7 may yet prove capable,
but the implementation isn't there yet.
> By the way, TADS 3 has three well-developed conversation interfaces,
> and one quite powerful rule-based topic-resolution system, and a couple
> well-developed knowledge/memory rubrics -- and it's far easier to
> program in.
I dislike TADS 3 in the same way I dislike doing string-handling in C.
> > I have proven to myself that building a world model is enormously
> > easier using I7
>
> Uh, as opposed to what? (N.B.: all standard IF libraries come with
> "world model" included.)
>
> > but now I'm trying to tie loose ends together in my
> > story with sophisticated dialogue between characters and that
> > simplicity I saw before has evaporated.
>
> Oh. Well, will you permit me to use you as an example of a user who is
> initially amazed by I7, but then finds things evaporating? You yelled
> at me for warning you.
>
> > I now stand frozen trying to figure how to do dialogue for NPC's that
> > have a memory.
>
> I think it's the same no matter what major programming project you're
> working on. If you wanted to do some really serious
> world-modeling/simulation work, you'd have the same freezing problem.
I'm still amazed at Inform 7 and have accomplished more in the last
several months than in the last 8 years. More than I ever would have
been able to get done in TADS (pick a version) or Inform 6. The fact
that this one layer of IF hasn't really been fully investigated in a
beta programming tool doesn't mean anything to me.
One thing that definitely hasn't changed is my opinion of you.
David C.
vaporware
> It sounds to me you're considering "the natural language of I7" as a
> magic wand, and you're pointing it at things and you're surprised that
> it doesn't work. Maybe you should re-think a little.
>
> By the way, TADS 3 has three well-developed conversation interfaces,
> and one quite powerful rule-based topic-resolution system, and a couple
> well-developed knowledge/memory rubrics -- and it's far easier to
> program in.
Also, it counts down the days to the competition deadline. It points
out holes in your plot and grammatical mistakes in your dialogue. It
warns you when puzzles are too easy. It gives you new ideas when you
get stuck. It scours your hard drive for spyware and cleans up your
unused desktop icons. It smells like lavender and pumpkin pie. It puts
the kids to bed and bakes corn muffins while you code.
And when your wife leaves the room... well, let's just say it helps not
to wear a belt when you're programming in TADS 3.
vw
steve....@gmail.com
> Dialogue constructs are a layer of
> syntax/code/definition that has yet to see an optimal approach.
I don't see why you imagine there should/could be an optimal approach.
I believe a rule-oriented framework is the best for dealing with this
realm. That's basically what TADS 3 provides. I guess that I7 will grow
to do/provide something similar.
> I think
> Emily's essay clearly defines the problems. I7 may yet prove capable,
> but the implementation isn't there yet.
Last I heard, all of Emily's problems were adequately answered by TADS
3. Not that I think Emily's problems are the be-all. I7 is entirely
capable, of course.
> > By the way, TADS 3 has three well-developed conversation interfaces,
> > and one quite powerful rule-based topic-resolution system, and a couple
> > well-developed knowledge/memory rubrics -- and it's far easier to
> > program in.
>
> I dislike TADS 3 in the same way I dislike doing string-handling in C.
You dislike TADS 3, and you find it stunningly difficult to program in
I7. I know what you mean, and I sympathise: it's a hard world indeed.
ChicagoDave
> You dislike TADS 3, and you find it stunningly difficult to program in
> I7. I know what you mean, and I sympathise: it's a hard world indeed.
I never said that.
In fact, I said that building a world model has never been easier.
I did say that dialogue is _currently_ problematic and complex, but not
impossible. I'm also working on a solution as are other people. We'll
get a set of core dialogue extensions smoothed out eventually.
All your other comments pointless.
David C.
Adam Thornton
vaporware <jmc...@gmail.com> wrote:
>And when your wife leaves the room... well, let's just say it helps not
>to wear a belt when you're programming in TADS 3.
AUGH.
If *ONLY* there were a *MANUAL* I would have *KNOWN* about this feature
and not wasted all that time working on my I7 WIP!
Adam
Emily Short
ChicagoDave wrote:
> Overall I have this sneaking suspicion that dialogue will continue to
> be a thorn in my side. But I will have to resolve this issue to the
> best of my ability. I can't see how productive an IF author I can be
> unless I can continue to attack a story in my head without pause for
> _too much_ logical construction.
Hm, okay.
I have no idea whether this will turn out to be helpful at all, either
as a solution to your problems or as a learning tool. But what I've
done is write up a basic implementation of the features I understand
you to want (perhaps not congruent with your actual intentions, of
course), and commented it to try to explain *why* I used the structures
I used where I used them. It is here:
http://emshort.home.mindspring.com/ZombieChat.txt
Because it's pretty heavily commented, it may be most readable if
pasted into the I7 application so that the syntax coloring is in force.
On the other hand, of course, it may be that I didn't explain things
well enough, so if you have questions, feel free to ask. (Or to ignore
it, if it is too confusing or off-base from what you wanted.)
ChicagoDave
> Hm, okay.
>
> I have no idea whether this will turn out to be helpful at all, either
> as a solution to your problems or as a learning tool. But what I've
> done is write up a basic implementation of the features I understand
> you to want (perhaps not congruent with your actual intentions, of
> course), and commented it to try to explain *why* I used the structures
> I used where I used them. It is here:
>
> http://emshort.home.mindspring.com/ZombieChat.txt
You are most generous. I did not mean to have you do this and I
appreciate it all the more.
Thank you,
David
Emily Short
ChicagoDave wrote:
> You are most generous. I did not mean to have you do this and I
> appreciate it all the more.
No problem, really -- I am interested in the pedagogical problem of how
to familiarize people with the structures of I7, so this seemed like an
interesting thing to take a stab at.
Kevin Forchione
news:1155685897....@i3g2000cwc.googlegroups.com...
>> steve....@gmail.com wrote:
<snip>
>> By the way, TADS 3 has three well-developed conversation interfaces,
>> and one quite powerful rule-based topic-resolution system, and a couple
>> well-developed knowledge/memory rubrics -- and it's far easier to
>> program in.
>
> I dislike TADS 3 in the same way I dislike doing string-handling in C.
Personally I find both systems have had a synergistic effect on me. Though
most of my projects are in TADS 3 Mr. Nelson's ideas are, as always,
enormously stimulating.
But is it the language syntax, the processing model, or the programming
paradigm that you dislike so much?
--Kevin
Adam Thornton
Kevin Forchione <ke...@lysseus.com> wrote:
>Personally I find both systems have had a synergistic effect on me.
I wish that Eric Eve had advertised his TADS 3 Tour Guide more
vociferously, not to say obnoxiously. I started reading it last night
and it's really quite fascinating. It strikes me that it should give me
enough knowledge to really do a fair comparison of where TADS 3, I6, and
I7 each have their strengths and weaknessess (yes, Kent Tessman cries,
but I never have tried anything of any size in Hugo).
Adam
P.S. I'll vociferously advertise it, in case it's some sort of
stiff-upper-lip British reticence at work:
http://users.ox.ac.uk/~manc0049/TADSGuide/intro.htm
Tor Andersson
> I have no idea whether this will turn out to be helpful at all, either
> as a solution to your problems or as a learning tool. But what I've
> done is write up a basic implementation of the features I understand
> you to want (perhaps not congruent with your actual intentions, of
> course), and commented it to try to explain *why* I used the structures
> I used where I used them. It is here:
>
> http://emshort.home.mindspring.com/ZombieChat.txt
>
> Because it's pretty heavily commented, it may be most readable if
> pasted into the I7 application so that the syntax coloring is in force.
Hang on a minute:
<quote>
A subject is a kind of thing.
A subject can be abstract or concrete.
A subject is usually abstract. A thing is usually concrete.
</quote>
How does that work? Do properties that are
declared for a specific kind apply to all objects, even
those that are not of the kind in question?
ChicagoDave
> Personally I find both systems have had a synergistic effect on me. Though
> most of my projects are in TADS 3 Mr. Nelson's ideas are, as always,
> enormously stimulating.
>
> But is it the language syntax, the processing model, or the programming
> paradigm that you dislike so much?
It's my view of IF as well as what I would call "business-oriented
development" I'm afraid. Although I'm a programmer by trade, I have
nearly always been focused on the solution and nearly never on the
constructs below the "business end of things".
So an example is earlier in my career I was asked to write reports in
VAX-C. To this day I cringe at the amount of effort it took to
construct strings and manage memory. I cringe at the ways in which we
had to speak to a database (Ingress) back then.
Now I've taken a liking to object-oriented development, but again, only
from a solutions perspective. I've decided I don't care about design
patterns as much as I thought I would. I like being involved in the
business object modeling, but anything below that is pretty much a
repetitive glop of soup I really don't want to get mixed up in. Let the
kids do that stuff.
But IF adds another aspect to this whole thing.
I like to write stories. I don't generally share my stories with anyone
because I write for myself and I've never been disciplined in going
over them two or three times (or more) to make them public. I'm also
still learning the rules of writing. I think Adam Cadre's review of
Cattus Atrox describes my talent perfectly. I know how to convery
emotion, but there was something of the eighth-grader in my writing
that I needed to get past. I've been working on that.
My interest in IF is similar to my skills as a professional developer.
I want to solve problems and deliver the solution. I'm not really
interested in any of the code that creates the solution. Once the
solution is created, I'm happy. I need never see the code again.
And by solution, I mean seeing the work functioning, not seeing that a
particular portion of code tests successfully.
So with Inform 7 I see a way of _writing_ and thinking about the
solution, without having to pattern code first. One of the things I've
read about some of the other If authors is that they think about what
sort of "tools" they need to implement the story they want to write. I
have never done this and probably never will. I see the story..the
transcript...and want to _write that_.
So when I look at TADS 3 or even Inform 6 or Hugo, I don't feel my
writing muse. She hides from such constrcuts. But when I open up Inform
7, she's at the forefront of my imagination and my ideas and stories
_flow_ into that syntax. And it's really fascinating to be able to sit
down dead tired and really not believe I'm going to get anything done
and yet I read a bit of source and play a section of the game that's
not complete and an hour later I've written another 2000 words.
This has never happened in any other tool for any other purpose. Well,
maybe Visual Basic for writing Windows programs, but even that had a
lack of grace underneath those pretty windows.
So I don't if this helps but really...I just "connect" with the syntax
in the way I want to write IF stories. Now granted, I7 isn't perfect
and I'm still learning how to accomplish complex logical constructs,
but for some reason I never feel like giving up.
Maybe it's just me. I don't know.
David C.
Emily Short
Tor Andersson wrote:
> Hang on a minute:
>
> <quote>
> A subject is a kind of thing.
> A subject can be abstract or concrete.
> A subject is usually abstract. A thing is usually concrete.
> </quote>
>
> How does that work? Do properties that are
> declared for a specific kind apply to all objects, even
> those that are not of the kind in question?
Its presence is an error due to some inadequately-cleaned-up code
revision, I think, but I agree it is curious that I7 let me get away
with it. Hm.
Kevin Forchione
>> Kevin Forchione wrote:
>> Personally I find both systems have had a synergistic effect on me.
>> Though
>> most of my projects are in TADS 3 Mr. Nelson's ideas are, as always,
>> enormously stimulating.
>>
>> But is it the language syntax, the processing model, or the programming
>> paradigm that you dislike so much?
> So I don't if this helps but really...I just "connect" with the syntax
> in the way I want to write IF stories. Now granted, I7 isn't perfect
> and I'm still learning how to accomplish complex logical constructs,
> but for some reason I never feel like giving up.
>
> Maybe it's just me. I don't know.
I can get to this. The whole promise of declarative programming is that you
work on describing the problem (as a program) and let the built-in
algorithms produce the solutions. One of the things about the imperative
paradigm is that even with a library, such as most languages include, which
serves as a platform for approaching the programming problems declaratively,
once you find the need to extend the functionality you must do so
imperatively. So in a sense, with the imperative paradigm you must always
fall into imperative programming once you start moving beyond the base
implementation.
Granted, I7, like other declarative approaches, isn't "pure", but it's a
matter of emphasis, and from a psychological perspective, emphasis makes all
the difference.
--Kevin
Eric Eve
"Adam Thornton" <ad...@fsf.net> wrote in message
news:ec09tl$22d$1...@fileserver.fsf.net...
I'm enormously grateful for the publicity, and utterly delighted for
you to publicize it all you wish, but I'm a little surprised you
hadn't come across it before, since (a) it's explicitly linked to
from and advertised on the official TADS 3 site (see
http://www.tads.org/t3dl.htm#docs) and (b) it's so often been
mentioned in various RAIF posts that I thought people must be tired
of hearing about it!
But I'm glad you're finding it interesting, and pleased that our
recent exchange at least had the effect of leading you to it!
-- Eric