Organising and folding code. Database paradigm. Kind of I7 biased.
d...@pobox.com
got me thinking.
Wouldn't it be cool if I could view (and edit) together in one place
all the rules that were in a particular rulebook regardless of where
they were originally defined in the source? Or all the declarations
that applied to a particular kind, or a particular object.
How about viewing all the rules that could possibly apply to a
particular object (or kind)?
The kind of thing I am imagining is where there is no canonical linear
representation of the source but instead a database of assertions and
declarations. This arises from the practice that some author's have of
arranging notes on 3x5 index cards. A card might have the details of a
location on it, or an object, or a character. Extending this to IF,
cards would also have details of verbs, actions, and rules. I might
choose to gather all my "location" cards together so that I can check
that the locations all consistently refer to each other; that a
particular effect that I want to convey in a region is convingly
portrayed; that a feature described from several locations is described
consistently and appropriately. Later on I might want to reorganise my
cards and look at all the things that apply to a given scene: the
poisioned apple card; the poisoning action card; the orchard.
A source code editor would then support a number of "views" or
"queries" which would pull out a number of cards from the database and
present them to you for browsing and editing (yes, probably as a linear
text, but possibly not). Quite possibly one of the "views" would show
all cards in some arbitrary order (and hence me most like the
traditional view of a single file of code).
In a way the index panel of Inform 7 does some of this. The World tab
organises the room and object cards together. The Kinds tab organises
cards taxonomically. But you can't see the code, nor can you edit it.
drj
Emily Short
d...@pobox.com wrote:
> A source code editor would then support a number of "views" or
> "queries" which would pull out a number of cards from the database and
> present them to you for browsing and editing (yes, probably as a linear
> text, but possibly not). Quite possibly one of the "views" would show
> all cards in some arbitrary order (and hence me most like the
> traditional view of a single file of code).
>
> In a way the index panel of Inform 7 does some of this. The World tab
> organises the room and object cards together. The Kinds tab organises
> cards taxonomically. But you can't see the code, nor can you edit it.
I can see the appeal of this, but my suspicion is that for I7 it would
be quite hard -- in order to figure out what belongs where, you
effectively need to run most of a compile process (maybe skipping the
I6 compilation, but doing all the I7 parsing), and if you had to
reassess this after every edit it would presumably be prohibitively
sluggish. (After all, the Index doesn't rebuild unless you recompile.)
It's a neat thought, though.
ChicagoDave
> I can see the appeal of this, but my suspicion is that for I7 it would
> be quite hard -- in order to figure out what belongs where, you
> effectively need to run most of a compile process (maybe skipping the
> I6 compilation, but doing all the I7 parsing), and if you had to
> reassess this after every edit it would presumably be prohibitively
> sluggish. (After all, the Index doesn't rebuild unless you recompile.)
Most IDE's actually do an incremental compile everytime the source text
changes. I suspect there's some underlying algorithm that determines
how broad of a recompile is required. I have no idea how you would do
incremental compiles though.
If this were somehow implemented in the NI and I6 compilers, the
sluggishness would be circumvented and you'd have the ability to enable
real-time development environment features such as code folding, code
indexing, and so on.
David C.
d...@pobox.com
Emily Short wrote:
> d...@pobox.com wrote:
> > A source code editor would then support a number of "views" or
> > "queries" which would pull out a number of cards from the database and
> > present them to you for browsing and editing (yes, probably as a linear
> > text, but possibly not). Quite possibly one of the "views" would show
> > all cards in some arbitrary order (and hence me most like the
> > traditional view of a single file of code).
> >
> > In a way the index panel of Inform 7 does some of this. The World tab
> > organises the room and object cards together. The Kinds tab organises
> > cards taxonomically. But you can't see the code, nor can you edit it.
>
> I can see the appeal of this, but my suspicion is that for I7 it would
> be quite hard -- in order to figure out what belongs where, you
> effectively need to run most of a compile process (maybe skipping the
> I6 compilation, but doing all the I7 parsing)
Oh yes. Very much so.
I expect though that if a development system was based around this idea
then most of the time an author would be editing cards and the unit of
recompilation would naturally be the card. In order to support
efficient incremental collection of single cards the compiler would
have to maintain a database that contained the "compiled form" of each
card. In a very self-referential manner the compiled form would be
whatever data and summaries the compiler needed in order to support
efficient incremental collection. Practically this means that the
compiler's internal "model" for a card would need to be persistently
stored. Since a card is not an entire program this "model" is
necessarily incomplete. For example we might have a card that says "X
has Y called Z". In the absence of any other declarations the
compiler's model has to cope with the fact that X might be a kind or an
instance and that Y might be a value or a kind. Z is pretty much a
name. The Inform 7 compiler is almost certainly doing analysis of this
sort, but almost certainly not in a way that is amenable to this
partial extraction treatment.
These ideas are not particularly new; as I understand it they're
standard fare in the compiler construction world.
> , and if you had to
> reassess this after every edit it would presumably be prohibitively
> sluggish. (After all, the Index doesn't rebuild unless you recompile.)
Yeah, and that annoys me too.
>
> It's a neat thought, though.
Oh, it was definiely in the "neat thought" rather than "practical idea"
category.
drj