[Announce] makemaze for Inform
Ricardo Dague
"makemaze.zip" to ftp.gmd.de/incoming/if-archive.
In it is "makemaze.inf", a program which generates random mazes and
outputs (via scripting) Inform source files for them. It's a program that
writes programs! Also included is "mazeclas.h" which defines an example
class MazeClass which the maze rooms are instances of.
A short tutorial is shown when it's run.
Could anyone interested please download and test it? Send bug reports
and/or comments to tri...@hotmail.com.
Thanks,
-- Ricardo
Todd Baumann-Fern
Ricardo Dague wrote:
> I know how all of you LOOOOVE mazes in adventure games, so I've uploaded
> "makemaze.zip" to ftp.gmd.de/incoming/if-archive.
Great! I'll can go and buy seed for my corn-maze now. :-} Hehe.
--
--Bud tf...@midstate.tds.net
David "Inky" Scott
> In it is "makemaze.inf", a program which generates random mazes and
> outputs (via scripting) Inform source files for them. It's a program
> that writes programs! Also included is "mazeclas.h" which defines an
I believe (trying to remember my days as a CS major) that Knuth once
said that the two tests of a "valid" programming language were:
1) Can the language be used to write its own compiler?
2) Can the output of programs be used as valid input to the compiler (in
other words, can you write programs that write programs)?
Well, we have #2 now, anybody care to write an Inform compiler in
Inform? :-)
--
David "Inky" Scott Member of the Bermuda Triangle
da...@interoz.com Expedition Force: 1997-1951
InterCity Oz Web Architect Yes, my actions represent the typical
http://chimera.acs.ttu.edu/~z5d31 student at Texas Tech University.
Member of Legion West Roleplaying and 10,000 Animeniacs Anime Club
Last Games Played: Babylon 5 Wars, Mythos, Kings & Things
Gunther Schmidl
>David "Inky" Scott Member of the Bermuda Triangle
^^^^
Watch out! An impostor! Dan! Dan!!!
--
+------------------------+----------------------------------------------+
+ Gunther Schmidl + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 + except temptation" -- Oscar Wilde +
+ A-4040 LINZ +----------------------------------------------+
+ Tel: 0732 25 28 57 + http://gschmidl.home.ml.org - new & improved +
+------------------------+---+------------------------------------------+
+ sothoth (at) usa (dot) net + please remove the "xxx." before replying +
+----------------------------+------------------------------------------+
Andrew Plotkin
> I believe (trying to remember my days as a CS major) that Knuth once
> said that the two tests of a "valid" programming language were:
> 1) Can the language be used to write its own compiler?
> 2) Can the output of programs be used as valid input to the compiler (in
> other words, can you write programs that write programs)?
> Well, we have #2 now, anybody care to write an Inform compiler in
> Inform? :-)
It's been brought up before. The Z-machine doesn't have enough RAM to
run a port of Graham's Inform compiler. Any Inform compiler at all is
going to have to store lots of tables in memory, and the final game file
as well. So the final game size is going to be limited to under 64K, even
with the most clever memory hacks. That's barely enough for a one-object
game with the standard library.
The file opcodes aren't quite strong enough to run a virtual-memory
system, either.
So it's no go.
PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Dan Shiovitz
>PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
The Frobozz Magic Inky Corporation was having a package deal, I
expect. Maybe we can work out some sort of time-share on the name.
(or "You be inky *west* of the Mississippi...")
>--Z
(inky @ ifMUD)
--
Dan Shiovitz || d...@cs.wisc.edu || http://www.cs.wisc.edu/~dbs
"...Incensed by some crack he had made about modern enlightened
thought, modern enlightened thought being practically a personal buddy
of hers, Florence gave him the swift heave-ho and--much against my
will, but she seemed to wish it--became betrothed to me." - PGW, J.a.t.F.S.
Darin Johnson
> > Well, we have #2 now, anybody care to write an Inform compiler in
> > Inform? :-)
>
> It's been brought up before. The Z-machine doesn't have enough RAM to
> run a port of Graham's Inform compiler.
That's a "machine" limitation, not a language one. If the language
clearly limited you to 64K as part of the language/semantics, then
that would be different
--
Darin Johnson
da...@usa.net.delete_me
David Glasser
> David \"Inky\" Scott (da...@interoz.com) wrote:
> > I believe (trying to remember my days as a CS major) that Knuth once
> > said that the two tests of a "valid" programming language were:
>
> > 1) Can the language be used to write its own compiler?
>
> > 2) Can the output of programs be used as valid input to the compiler (in
> > other words, can you write programs that write programs)?
>
> > Well, we have #2 now, anybody care to write an Inform compiler in
> > Inform? :-)
>
> It's been brought up before. The Z-machine doesn't have enough RAM to
> run a port of Graham's Inform compiler. Any Inform compiler at all is
> going to have to store lots of tables in memory, and the final game file
> as well. So the final game size is going to be limited to under 64K, even
> with the most clever memory hacks. That's barely enough for a one-object
> game with the standard library.
>
> The file opcodes aren't quite strong enough to run a virtual-memory
> system, either.
>
> So it's no go.
The answer, it seems, is that *Inform* can write a compiler for itself,
but that it is impossible to run on the ZMachine. (In other words, a
"simple" retargeting of the *language* Inform to the Z-SquaredMachine
would allow an Inform compiler in Inform.)
--David Glasser
gla...@NOSPAMuscom.com | http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Sadie Hawkins, official band of David Glasser: http://sadie.retina.net
"We take our icons very seriously in this class."
Doeadeer3
In article <tvyogry...@cn1.connectnet.com>, Darin Johnson
<da...@usa.net.removethis> writes:
>> It's been brought up before. The Z-machine doesn't have enough RAM to
>> run a port of Graham's Inform compiler.
>
>That's a "machine" limitation, not a language one. If the language
>clearly limited you to 64K as part of the language/semantics, then
>that would be different
Just out of extreme curiosity and because I like learning new things, why
should the z-machine be limited to 64K? I mean I know why historically. Of
course I am not positive I know what the z-machine IS (someone told me an
imaginary *universal* machine that ZIL was designed for). But if we are talking
about Inform emulating the z-machine, then why the limit? Couldn't that be
changed within Inform, itself? If it was would that necessarily affect the .z
files produced by Inform? Isn't the memory allocation for Inform .z files
higher than that already? If not, would that limit what machines .z files could
be played on? Don't interpreters already exceed 64K? Why do we have to maintain
an old standard? Does changing it mean interpreters couldn't play old Infocom
games? Why the 64K limit, even now?
I could keep on asking questions, but I realize I don't know what I am talking
about. Please enlighten me.
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
Andrew Plotkin
> In article <tvyogry...@cn1.connectnet.com>, Darin Johnson
> <da...@usa.net.removethis> writes:
> >> It's been brought up before. The Z-machine doesn't have enough RAM to
> >> run a port of Graham's Inform compiler.
> >
> >That's a "machine" limitation, not a language one. If the language
> >clearly limited you to 64K as part of the language/semantics, then
> >that would be different
BTW, I agree this this. One could argue that some details of Inform 6 (the
language) are tied to the current Z-machine model, but they're details. An
Inform compiler for a new, 32-bit VM would have different details, but
you could sensibly call it the same language.)
> Just out of extreme curiosity and because I like learning new things, why
> should the z-machine be limited to 64K?
It shouldn't!
Oh, you weren't speaking in the ethical declension? :)
> I mean I know why historically. Of
> course I am not positive I know what the z-machine IS (someone told me an
> imaginary *universal* machine that ZIL was designed for).
That's a good description. Except I don't know why the word "universal" is
in there. It's a general-purpose computing machine, in the same sense that
any home computer is.
> But if we are talking
> about Inform emulating the z-machine, then why the limit? Couldn't that be
> changed within Inform, itself? If it was would that necessarily affect the .z
> files produced by Inform? Isn't the memory allocation for Inform .z files
> higher than that already? If not, would that limit what machines .z files could
> be played on? Don't interpreters already exceed 64K? Why do we have to maintain
> an old standard? Does changing it mean interpreters couldn't play old Infocom
> games? Why the 64K limit, even now?
Ok.
First, there are two separate limits.
64K of RAM (writable memory, including all dict words, objects, variables,
arrays, properties -- anything that can be changed during play.)
All memory outside of RAM is ROM (non-writable memory -- can *only*
contain strings and functions.) There's a limit on this, too, which is
different in different Z-machine versions. In V8, it's 512K.
The 64K limit on RAM is very hard to change, because the Z-machine
architecture uses 16-bit values everywhere. Every storage location
(including variables, properties entries, and storage positions on the
stack) is a 16-bit value. All the opcodes that look up and store data take
16-bit values. A 16-bit value can only refer to 65536 separate locations
-- that's (ahem) the long and short of it.
Strings and routines get around this by sneakily using a *non-contiguous*
set of 65536 locations. In V8, strings/routines can be stored at locations
0, 8, 16, 24, 32, 40... 524272, 524280. There are 65536 locations in that
list, so they can all be represented by a 16-bit value.
But this is only practical because very few opcodes *use* strings and
routines. Logically, only @print_string and @call_routine ever use such
values -- and they *only* use such values. (There are really a few
variations of @print and @call, but that's a detail.) It would be terribly
complicated to switch *all* data over to such a system.
Now, any expansion of the memory-space (be it terribly complicated or
simple) means that interpreters have to be changed. We saw that with V8.
That was a very very simple change, both in the Inform compiler and the
interpreters.
Unfortunately, a RAM expansion cannot be that simple. The easiest approach
is to redesign the machine to use 32-bit values everywhere, instead of
16-bit. That's still quite a bit of work.
Furthermore: There are lots of other annoying limitations in the
Z-machine. Number of attributes. Number of global variables. Number of
global properties. The I/O system. More subtle matters, like the way you
have to determine the type of a value. (Does this 16-bit value refer to a
dict word, an object, a string, or a routine? You'll recall the long
thread a couple months ago on this subject. The current methods are...
suboptimal.)
I feel (and I think there's a lot of agreement) that it would very bad to
start fixing these limitations one at a time. We'd wind up with dozens
(really, dozens) of Z-machine versions, in various stages of changedness.
It would be impossible to support either the interpreters or the compiler,
much less games.
So the ideal is to invent an entirely new interpreter, with as few hard
limitations as possible. At least, we can eliminate all the ones we've
found out in the past fifteen years of IF development!
This is, unfortunately, a lot of work. Various people are working on parts
of it. This is explicitly why I started working on Glk, which is a
solution to the "limited I/O system" problem.
Until all the parts are in place, game authors are sort of stuck.
Does that start to answer all of your questions? It all sums to "There's
lots to work on, and it would be a very great waste of time and effort to
fix things one at a time."
(The fact that the problem is structured this way is *itself* one of the
problems. This *also* is one of my goals, of which Glk is an examplar:
changing the view of the IF interpreter from a single unitary piece, which
is entirely changed if any part is changed, to a set of modules working
together.)
Doeadeer3
In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
Plotkin) writes:
>Does that start to answer all of your questions? It all sums to "There's
>lots to work on, and it would be a very great waste of time and effort to
>fix things one at a time."
Yes, thank you very much. Not sure I get it all, but I get the jist.
I stuck the *universal* in the description myself, it was not in the answer
that someone gave me, by inserting it I meant universal in the sense of not
tied to any particular real machine (IBM, Mac, etc.).
Only one question remains unanswered for me then, (btw, I now understand Glk
much better), would a new standard (32-bit, I presume) in the z-machine and the
resultant compilers and interpreters still allow interpreters to play the old
Infocom games? I mean I don't really know what data is stored in those files,
are opcodes stored? If so, is there anyway to adapt them so they would work on
32 bit?
Or would we also have to keep the old interpreters around?
Doe :-) TIA (Den said that was Thanks In Advance, but I don't know if he was
fooling.)
Simon 'tufty' Stapleton
> Only one question remains unanswered for me then, (btw, I now understand Glk
> much better), would a new standard (32-bit, I presume) in the z-machine and the
> resultant compilers and interpreters still allow interpreters to play the old
> Infocom games? I mean I don't really know what data is stored in those files,
> are opcodes stored? If so, is there anyway to adapt them so they would work on
> 32 bit?
I personally would hope that any new 32bit z-machine interpreters would
also handle the old style games, in much the same way that the current
generation handle the various z-machine standards (z3-8). As a guess,
though, this would be a considerable amount of work, as it would
probably mean having two interpreters in one, as I understand it
(particularly as, as andrew says, a new 32bit z-machine should fix
more than just the memory space issues). If the memory space issue
was all that were at stake, it *shouldn't* be *too* hard to map the
16-bit memory space into the larger 32 bit memory space, although I
personally wouldn't want to do it.
> Or would we also have to keep the old interpreters around?
The old terps would still be useful, at leaast for those machines that
can't handle the larger memory space required by 32 bit (Palm Pilot
etc spring to mind, as do the interpreters for the older machines like
the C64, Apple II and the like.)
I may, of course, be way off the mark, in which case feel free to
flame me.
Simon (ifMUD's 'tufty')
--
_______
| ----- | Biased output from the demented brain of
||MacOS|| Simon Stapleton.
|| NOW ||
| ----- | sstaple AT liffe DoT com
| -+-.| (if you can't figure it out...)
|洵洵洵洱
-------
Den of Iniquity
>TIA (Den said that was Thanks In Advance, but I don't know if he was
>fooling.)
*Sob* I'll never be trusted again.
Listen. If what I say is utterly, _utterly_ absurd, such that you _know_
it's not true, such as molecules being painted blue and angels
manufacturing protophyta out of strawberry jelly, then I'm lying
inventively. If what I say is just utterly absurd, like television
reception tax and gasoline selling at $5 per gallon all over the UK, and
you find it hard to believe, then it's a curious piece of trivia and
certainly true (or I believe it to be, anyway). I don't set out to mislead
anyone deliberately.
Unfortunately, as you can imagine, it doesn't always work. My girlfriend
still hasn't quite forgiven me for that time I told her about Giant
Sparrows, with wingspan as large as an eagle's. Honestly.
--
Den
ne...@norwich.edu
erky...@netcom.com (Andrew Plotkin) wrote:
> It's been brought up before. The Z-machine doesn't have enough RAM to
> run a port of Graham's Inform compiler. Any Inform compiler at all is
> going to have to store lots of tables in memory, and the final game file
> as well. So the final game size is going to be limited to under 64K, even
> with the most clever memory hacks. That's barely enough for a one-object
> game with the standard library.
>
> The file opcodes aren't quite strong enough to run a virtual-memory
> system, either.
>
> So it's no go.
>
> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
I toyed with identifying myself as N. Donald Cerutti, but decided it
sounded like a politicians name. Plus, being named Neil seems to have
a long a glorious tradition here. I remember when I first read this group
thinking that everybody was named Graham or Neil on rec.arts.int-ficion.
--
Neil Cerutti
ne...@norwich.edu
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Andrew Plotkin
> doea...@aol.com (Doeadeer3) writes:
> > Only one question remains unanswered for me then, (btw, I now understand Glk
> > much better), would a new standard (32-bit, I presume) in the z-machine and the
> > resultant compilers and interpreters still allow interpreters to play the old
> > Infocom games? I mean I don't really know what data is stored in those files,
> > are opcodes stored? If so, is there anyway to adapt them so they would work on
> > 32 bit?
> I personally would hope that any new 32bit z-machine interpreters would
> also handle the old style games, in much the same way that the current
> generation handle the various z-machine standards (z3-8). As a guess,
> though, this would be a considerable amount of work, as it would
> probably mean having two interpreters in one, as I understand it
> (particularly as, as andrew says, a new 32bit z-machine should fix
> more than just the memory space issues). If the memory space issue
> was all that were at stake, it *shouldn't* be *too* hard to map the
> 16-bit memory space into the larger 32 bit memory space, although I
> personally wouldn't want to do it.
I think the whole thing would be too messy to deal with. I'd much rather
declare (conceptually) that it's an entirely new machine, *not* a new
version of the Z-machine, and it has entirely new interpreters.
That's just labelling, but I think it's also important not to feel stuck
to any part of Z-machine design. I can think of very fundamental changes
that might be worth doing. Stack format, opcode encoding, real dynamic
memory -- etc. Removing the I/O system is quite a change too.
Of course someone could *make* an interpreter that handles both the
Z-machine and whatever new machine this is. Just as someone could make an
interpreter that handles both Z-code and TADS. But I think it's a big, big
mistake to make it a *design goal* of a new VM to make this *easier*.
> > Or would we also have to keep the old interpreters around?
That's what I'd expect.
Magnus Olsson
Doeadeer3 <doea...@aol.com> wrote:
>Just out of extreme curiosity and because I like learning new things, why
>course I am not positive I know what the z-machine IS (someone told me an
>about Inform emulating the z-machine, then why the limit? Couldn't that be
>changed within Inform, itself?
No, Inform doesn't emulate the z-machine: Frotz and JZip and the other
interpreters emulate the z-machine. Inform is
a) a language for writing IF.
b) a compiler for turning that language into code for the z-machine.
Now, Inform a) (the language) doesn't have to be affected by the 64 K
limit (but I think it is in assuming that all addresses fit in a 16-bit
word).
Inform b) most definitely is affected: it has to produce code that the
z-machine can run.
You could write an Inform compiler that didn't produce z-machine code,
but instead code for, forexample, a Pentium processor, and in that
case you could have Inform programs that didn't have to care about
the 64K limit (you might have to increase the language's word length
to 32 bits, though).
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Magnus Olsson
>language) are tied to the current Z-machine model, but they're details. An
>Inform compiler for a new, 32-bit VM would have different details, but
>you could sensibly call it the same language.)
I think there's one very important aspect of the language that's tied
to the current Z-machine model: the assumption that all values fit in
a 16-bit word. If we extended the Z-machine to use, say, 128 K of RAM,
then we would either have to increase the word length, which would
break at least some existing code, or we'd have to add new types
(like pointer vs. short in C), which would break even more existing
code, or we'd have to use packed addresses for RAM as well as for
ROM (which is being done today). But in the last case, RAM wouldn't
be byte addressable anymore, which I suppose would break a lot of
existing code as well.
Andrew Plotkin
> In article <erkyrathF...@netcom.com>,
> Andrew Plotkin <erky...@netcom.com> wrote:
> >language) are tied to the current Z-machine model, but they're details. An
> >Inform compiler for a new, 32-bit VM would have different details, but
> >you could sensibly call it the same language.)
> I think there's one very important aspect of the language that's tied
> to the current Z-machine model: the assumption that all values fit in
> a 16-bit word. If we extended the Z-machine to use, say, 128 K of RAM,
> then we would either have to increase the word length, which would
> break at least some existing code, or we'd have to add new types
> (like pointer vs. short in C), which would break even more existing
> code, or we'd have to use packed addresses for RAM as well as for
> ROM (which is being done today). But in the last case, RAM wouldn't
> be byte addressable anymore, which I suppose would break a lot of
> existing code as well.
I was thinking of the first option -- and yes, it would break existing
source code. I was thinking of it as more or less a detail change in the
Inform language, though. Just a terminology difference.
(It wouldn't affect most game code; an author usually accesses words
through the --> operator, which would still work and transparently fetch
32-bit words instead of 16-bit words.
(The *library* would require lots of changes, but they'd all be
superficial changes of "2" constants to "4". And the same would apply to
any game code that cares -- generally stuff which checks the size of a
property array.
(In fact, the sensible maneuver would be to have a compiler-defined
constant WORDSIZE which was either 2 or 4, depending on the VM target.
Then both libraries and game source could be written to be platform
independent. As I said, I was thinking of this as a fairly minor change to
the language.)
("Minor" because there are much thornier VM changes I want to make too.
:-)
--Z (whew, a four-paragraph parenthetical comment.)
Doeadeer3
In article <Pine.SGI.3.95L.98093...@ebor.york.ac.uk>, Den of
Iniquity <dms...@york.ac.uk> writes:
>>TIA (Den said that was Thanks In Advance, but I don't know if he was
>>fooling.)
>
>*Sob* I'll never be trusted again.
Hehehe.
[snip]
>Unfortunately, as you can imagine, it doesn't always work. My girlfriend
>still hasn't quite forgiven me for that time I told her about Giant
>Sparrows, with wingspan as large as an eagle's. Honestly.
Rolf.
Well, I admit I was deliberately teasing you about TIA.
(Now, *sniff*, you'll never trust me again either, you'll always wonder if I am
teasing or tongue in cheek. *Sniff*. Hmmmmm, come to think of it you might be
wise not to... ;-) )
Doe
L. Ross Raszewski
m...@bartlet.df.lth.se (Magnus Olsson) wrote:
> Inform b) most definitely is affected: it has to produce code that the
> z-machine can run.
>
> You could write an Inform compiler that didn't produce z-machine code,
> but instead code for, forexample, a Pentium processor, and in that
> case you could have Inform programs that didn't have to care about
> the 64K limit (you might have to increase the language's word length
> to 32 bits, though).
>
Of coursem, you also have the problem of arrays,m which in inform can be
addressed either with the byte operator -> or the word operator -->.
print_to_string (output stream 3) places the string length in the first
_word_ of the array, and the characters start in the third _byte_. If we
made words 32-bit, we'd either need to double the size of a byte (which would
cost us so much space that we might as well still be using 16 bits) or make
any code which uses print_to_string (or istring.h) break. Now, you can say
"Well, that's a small sacrifice, and we can just make all the old code
non-portable", but it becomes a BIG issue if someone starts out writing a v5
game, then halfway through decideds it won't fit, and has to use v32 instead.
Again, you could say "well, evryone should use the 32-bit VM even for short
games", but ISTR people here still really liked portablility. I somehow
doubt that a new 32 bit VM will be as widely ported as the Z-machine(look how
long it's taken to get hugo ported to _anything_)
ObGLK -- Does GLK support at least the same color options as the Z machine?
ISTR Zarf dosen't believe we programmers have any right to mess around with
color. I happen to believe that we do. I'm hard pressed to believe that glk
solves the problem of the Z machine's alleged "limited I/O" if it doesn't
allow things that Z does....
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Doeadeer3
In article <19980930125843...@ngol04.aol.com>, doea...@aol.com
(Doeadeer3) writes:
>>>TIA (Den said that was Thanks In Advance, but I don't know if he was
>>>fooling.)
>>
>>*Sob* I'll never be trusted again.
>
>Well, I admit I was deliberately teasing you about TIA.
>
>(Now, *sniff*, you'll never trust me again either,
Okay, to be perfectly honest (sigh, that is soooo incredibly boring), I tend to
use joking to illustrate a truth, so if I hadn't had the tiniest suspicion you
might have been fooling, I wouldn't have teased. So if you didn't often tell
tall tales, I wouldn't have had suspicions and if I didn't often joke to make a
point, I wouldn't have teased.
Donut break time, I am getting confused.
Doe :-)
Doeadeer3
>That's just labelling, but I think it's also important not to feel stuck
>to any part of Z-machine design. I can think of very fundamental changes
>that might be worth doing. Stack format, opcode encoding, real dynamic
>memory -- etc. Removing the I/O system is quite a change too.
>
>Of course someone could *make* an interpreter that handles both the
>Z-machine and whatever new machine this is. Just as someone could make an
>interpreter that handles both Z-code and TADS. But I think it's a big, big
>mistake to make it a *design goal* of a new VM to make this *easier*.
Okay, answer another *dumb* q, if you would, please.
I was under the impression that the opcodes and memory management for a 16-bit
machine are fairly compatible across platforms, i.e., it is not a tremendous
task to port the z-machine to IBM and Mac and Amiga, etc. (if that is the way
one would say it.)
Does the same hold true for 32-bit? Or do opcodes and/or memory management
start differing a lot, thus making it a MUCH harder task?
Doe :-) Just curious.
Doeadeer3
>But if we are talking
>>about Inform emulating the z-machine, then why the limit? Couldn't that be
>>changed within Inform, itself?
>
>No, Inform doesn't emulate the z-machine: Frotz and JZip and the other
>interpreters emulate the z-machine. Inform is
>
>a) a language for writing IF.
>b) a compiler for turning that language into code for the z-machine.
I meant b when I said that, I just didn't say it correctly.
>Now, Inform a) (the language) doesn't have to be affected by the 64 K
>limit (but I think it is in assuming that all addresses fit in a 16-bit
>word).
>
>Inform b) most definitely is affected: it has to produce code that the
>z-machine can run.
Thanks, that's very clear.
Since the Inform compiler is written in C and C is not limited to 16-bits I can
see how Inform could be easily changed for a "new standard".
Doe :-)
Allen Garvin
I think the whole thing would be too messy to deal with. I'd much
rather declare (conceptually) that it's an entirely new machine, *not*
a new version of the Z-machine, and it has entirely new interpreters.
But someone working alone, in secret, could probably modify Inform and one
of the interpreters in a pretty short time to handle 32 bits. It'd be
a bother, but could be done. To specify and develop and entire new machine
however, would probably involve months of vigorous, vociferous arguing on
rec.arts.int-fiction, spawning dozens of off-topic discussions and lots of
posts of misinformation and some hurt feelings. Hm, wait, that's what
r.a.if is normally like... Anyway, the first would probably be done pretty
quickly, but the second might take years before coming to fruition.
--
Allen Garvin I think I'll
--------------------------------------------- Let the mystery be
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil Iris Dement
Ricardo Dague
> Of coursem, you also have the problem of arrays,m which in inform can be
> addressed either with the byte operator -> or the word operator -->.
> print_to_string (output stream 3) places the string length in the first
> _word_ of the array, and the characters start in the third _byte_. If we
> made words 32-bit, we'd either need to double the size of a byte (which would
> cost us so much space that we might as well still be using 16 bits) or make
> any code which uses print_to_string (or istring.h) break.
You could define a constant like SIZEOF_INT, which would be 2 for 16-bit
machines and 4 for 32-bit.
-- Ricardo
John Francis
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>
>You could write an Inform compiler that didn't produce z-machine code,
>but instead code for, forexample, a Pentium processor, and in that
>case you could have Inform programs that didn't have to care about
>the 64K limit (you might have to increase the language's word length
>to 32 bits, though).
You don't have to increase the WORD length - just the size of an address.
Mind you, it would probably be a good idea, at that point, to also
introduce a new 32-bit arithmetic data type (a LONG, presumably).
I suppose we'd also need a new dereferencing operator ( ---> ? )
I don't think we need to let strings get beyond 64K, though, so
the 16-bit length count is probably sufficient.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
Andrew Plotkin
> In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
> Plotkin) writes:
> >That's just labelling, but I think it's also important not to feel stuck
> >to any part of Z-machine design. I can think of very fundamental changes
> >that might be worth doing. Stack format, opcode encoding, real dynamic
> >memory -- etc. Removing the I/O system is quite a change too.
> >
> >Of course someone could *make* an interpreter that handles both the
> >Z-machine and whatever new machine this is. Just as someone could make an
> >interpreter that handles both Z-code and TADS. But I think it's a big, big
> >mistake to make it a *design goal* of a new VM to make this *easier*.
> I was under the impression that the opcodes and memory management for a 16-bit
> machine are fairly compatible across platforms, i.e., it is not a tremendous
> task to port the z-machine to IBM and Mac and Amiga, etc. (if that is the way
> one would say it.)
That's correct. The CPU part is very clean and well-defined, and it
doesn't have to interface with messy OS code, which is what makes the I/O
hard to port.
> Does the same hold true for 32-bit? Or do opcodes and/or memory management
> start differing a lot, thus making it a MUCH harder task?
No, it's exactly the same. Just different constants.
When I say it's a lot of work to convert a 16-bit VM to 32-bit, I mean (1)
all old game files will break, (2) quite a bit of source code will break,
including both library and (some) game source; (3) changing an interpreter
involves going in and looking at all the interpreter code, which is pretty
much the same amount of work as writing as new interpreter from scratch.
--Z
Andrew Plotkin
> "Well, that's a small sacrifice, and we can just make all the old code
> non-portable", but it becomes a BIG issue if someone starts out writing a v5
> game, then halfway through decideds it won't fit, and has to use v32 instead.
I've posted some comments about how to extend the Inform language and
compiler so that the same source can be compiled for either target. I
don't think it's a difficult problem.
> Again, you could say "well, evryone should use the 32-bit VM even for short
> games", but ISTR people here still really liked portablility. I somehow
> doubt that a new 32 bit VM will be as widely ported as the Z-machine(look how
> long it's taken to get hugo ported to _anything_)
I bet you're wrong. I've posted about that too, in the past.
> ObGLK -- Does GLK support at least the same color options as the Z machine?
> ISTR Zarf dosen't believe we programmers have any right to mess around with
> color.
You recall incorrectly.
> I happen to believe that we do. I'm hard pressed to believe that glk
> solves the problem of the Z machine's alleged "limited I/O" if it doesn't
> allow things that Z does....
See spec section 5.5.
Doeadeer3
Thanks, I now understand a lot more than I did before.
(But I would still rate that level of understanding on a scale of 1-10 about
somewhere in the 3-5 range, even that may be too high.)
Fred M. Sloniker
Francis) wrote:
>I don't think we need to let strings get beyond 64K, though
And two digits is fine for the year, right? (:3
(Just pointing out that, when you're trying to correct for obsolete
assumptions about how big is 'big enough', it's not a good idea to
introduce new assumptions. Of course, I rather suspect even the most
pessemistic Y2K fix assumes a four-digit year... wonder how much
effort it would be to code a program that could handle *any* year,
even years orders of magnitude farther in the future than any
hypothetical 'Big Crunch'? (:3)
Magnus Olsson
John Francis <jfra...@dungeon.engr.sgi.com> wrote:
>In article <6uth40$1h9$1...@bartlet.df.lth.se>,
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>>
>>You could write an Inform compiler that didn't produce z-machine code,
>>but instead code for, forexample, a Pentium processor, and in that
>>case you could have Inform programs that didn't have to care about
>>the 64K limit (you might have to increase the language's word length
>>to 32 bits, though).
>
>You don't have to increase the WORD length - just the size of an address.
I didn't mean the size of the machine word, but the size of the Inform
language's variables. You can think of the hgh-level language's
execution model as still another VM on top of the Z-machine, and
*that* high-level VM has a word size equal to the length of an address
- this is necessary since Inform is a typeless language where pointers
have to fit in a basic integer variable.
>Mind you, it would probably be a good idea, at that point, to also
>introduce a new 32-bit arithmetic data type (a LONG, presumably).
Introducing types to a typeless language is no small undertaking.
Simon 'tufty' Stapleton
> I didn't mean the size of the machine word, but the size of the Inform
> language's variables. You can think of the hgh-level language's
> execution model as still another VM on top of the Z-machine, and
> *that* high-level VM has a word size equal to the length of an address
> - this is necessary since Inform is a typeless language where pointers
> have to fit in a basic integer variable.
Surely this is the answer to the 'multiple interpreters' issue as well.
3 steps.
1 - Invent new and fixed 32bit Virtual machine. This might or might
not be based on the existing z-machine.
2 - Write an interpreter for this VM.
3 - Write an z-machine interpreter native to the new VM. this
wouldn't have to be as big as (say) frotz - as it would merely
handle the mapping from the z-machine to the new VM -
particularly easy if the new VM is based on z-machine. You would
also only need to write one of these as the front end would
be handled by the interpreter written in stage 2.
Bingo! Backwards compatibility.
Simon
I assume this has already been thought of. But it suddenly struck
me as a piece of inspiration, and given how boring my days are
normally, I thought I'd share it with you. Apologies if this has
been tedious.
Andrew Plotkin
> > I didn't mean the size of the machine word, but the size of the Inform
> > language's variables. You can think of the hgh-level language's
> > execution model as still another VM on top of the Z-machine, and
> > *that* high-level VM has a word size equal to the length of an address
> > - this is necessary since Inform is a typeless language where pointers
> > have to fit in a basic integer variable.
> Surely this is the answer to the 'multiple interpreters' issue as well.
> 3 steps.
>
> 1 - Invent new and fixed 32bit Virtual machine. This might or might
> not be based on the existing z-machine.
>
> 2 - Write an interpreter for this VM.
>
> 3 - Write an z-machine interpreter native to the new VM. this
> wouldn't have to be as big as (say) frotz - as it would merely
> handle the mapping from the z-machine to the new VM -
> particularly easy if the new VM is based on z-machine. You would
> also only need to write one of these as the front end would
> be handled by the interpreter written in stage 2.
>
> Bingo! Backwards compatibility.
Yeah, but you've introduced another layer of emulation. That slows the
game down another order of magnitude. This seems a little extravagant when
the alternative is simply having two (equally fast) interpreter programs
lying around.
(This shouldn't lead to an infinite regression of interpreters, because a
well-designed 32-bit VM should last us another 15 years without *any*
further changes. That's why I'm so keen to make sure we don't get stuck
with a badly-designed one. :-)
Magnus's point is not really what you said; he was saying that the Inform
*language* is implemented in terms of the Z-machine. It's sort of
like another VM, but the analogy isn't exact.
I actually don't quite agree with him. If I were changing Inform to target
a 32-bit VM, I'd have the machine word and the Inform language storage
elements both be 32 bits. Throw out the 16-bit word at both levels. I
think that'd cause the minimum disruption to Inform *source* (both
libraries and game source.)
Actually, for completeness, a 32-bit VM should have 16-bit opcodes (in
addition to byte and 4-byte opcodes). But the Inform compiler would
probably never use them.
(That may have been a bit confusing. The Z-machine has @storew, @loadw,
@storeb, and @loadb instructions -- store and load words, store and load
bytes. A word is 2 bytes. All Inform storage elements are words, and the
--> operator also manipulates words, but you can still manipulate bytes
with the -> operator. So the compiler uses all four of those opcodes.
(An Inform compiler targetted to a 32-bit VM, I think, should use 4-byte
storage elements, and the --> operator should manipulate 4-byte fields as
well. -> should still do bytes. So the compiler would only need to use
opcodes to store and load 1-byte and 4-byte fields.)
Branko Collin
<rras...@hotmail.com> wrote:
> Again, you could say "well, evryone should use the 32-bit VM even for short
>games", but ISTR people here still really liked portablility.
^^^^
I Suspect There R?
--
branko collin, bco...@xs4all.nl
<<<I'm a moron 'n' this is my wife>>> zappa
Branko Collin
wrote:
I'm sorry, but you're much to narrow minded. Who says a year has to
has digits. What if we decide next year is called Branko, and the year
after BrankoBranko, and the year after Branko, and then just when the
united programmers of the world have decided to just count 1, 2, 3, we
change the system.
(So let date point to something dynamic, then it's up to the memory
you've got.)
Doeadeer3
>(That may have been a bit confusing. The Z-machine has @storew, @loadw,
>@storeb, and @loadb instructions -- store and load words, store and load
>bytes. A word is 2 bytes. All Inform storage elements are words, and the
>--> operator also manipulates words, but you can still manipulate bytes
>with the -> operator. So the compiler uses all four of those opcodes.
>
>(An Inform compiler targetted to a 32-bit VM, I think, should use 4-byte
>storage elements, and the --> operator should manipulate 4-byte fields as
>well. -> should still do bytes. So the compiler would only need to use
>opcodes to store and load 1-byte and 4-byte fields.)
Another dumb q, couldn't the complier have an input parameter (when run) that
could switch between the two?
Byte Word
Inform 1 test.inf Inform 2 test.inf
Then the expansion to word addressing and additional opcodes (or features)
could be ignored unless 2 was entered. Nyah, probably wouldn't work (I do
realize I don't know what I am talking about.)
Doe :-) Just wondering
Doeadeer3
In article <19981001133146...@ngol01.aol.com>, doea...@aol.com
(Doeadeer3) writes:
>Byte Word
>Inform 1 test.inf Inform 2 test.inf
PS.
Make that
Word Double Word
Inform 1 test.inf Inform 2 test.inf
Those are the kinds of things that tend to confuse me, but in principle I know
the idea.
Sowwy, for the incorrectness.
Magnus Olsson
>> m...@bartlet.df.lth.se (Magnus Olsson) writes:
>> > I didn't mean the size of the machine word, but the size of the Inform
>> > language's variables. You can think of the hgh-level language's
>> > execution model as still another VM on top of the Z-machine, and
>> > *that* high-level VM has a word size equal to the length of an address
>> > - this is necessary since Inform is a typeless language where pointers
>> > have to fit in a basic integer variable.
(...)
>Magnus's point is not really what you said; he was saying that the Inform
>*language* is implemented in terms of the Z-machine. It's sort of
>like another VM, but the analogy isn't exact.
It's also an analogy that can be rather confusing, I suppose, so let's
put it another way:
The Inform language doesn't have types in the way C does: it does have
different types of data, but there's only one kind of variable, which
I called "word" without thinking. It's a key feature of the language
that if I write
[ foo bar;
bar = ...;
];
then bar is a local variable that can hold an integer, or an address in
RAM, or the address of a string, or the address of a routine, or the
number of a property, or... (completing the list is left as an exercise
to the reader).
The language specification also says that an integer is a 16-bit signed
quantity.
These two things together mean that a variable must be 16 bits long. The
value 16 comes, of course, from the Z-machine's word length, but it is
in principle independent of it.
If you extend the Z-machine to 32 bits (or replace it with some other
architecture with > 16 bits word length), then you'll have to change
the Inform language so that a variable is > 16 bits long, unless
you want to do funny things with addresses that breaks a lot of
existing code. In that case, you'll also have to change the definition
of an integer as a 16-bit signed value. It won't do to restrict
integers to 16 bits, since there's no way for, say, the comparison
operators to know whether they're operating on integers or addresses.
>I actually don't quite agree with him.
Well, I think we actually do agree; it's mostly a matter of how pedantic
we are. :-)
>If I were changing Inform to target
>a 32-bit VM, I'd have the machine word and the Inform language storage
>elements both be 32 bits. Throw out the 16-bit word at both levels. I
>think that'd cause the minimum disruption to Inform *source* (both
>libraries and game source.)
I think this is the best way, yes, but I think there will still be
*some* disruption to game source.
Let me hasten to add that the disruption will be smaller than that
caused by the upgrade from Inform 5 to Inform 6, and I think it will
be worth it.
Andrew Plotkin
> In article <erkyrathF...@netcom.com>, erky...@netcom.com (Andrew
> Plotkin) writes:
> >(That may have been a bit confusing. The Z-machine has @storew, @loadw,
> >@storeb, and @loadb instructions -- store and load words, store and load
> >bytes. A word is 2 bytes. All Inform storage elements are words, and the
> >--> operator also manipulates words, but you can still manipulate bytes
> >with the -> operator. So the compiler uses all four of those opcodes.
> >
> >(An Inform compiler targetted to a 32-bit VM, I think, should use 4-byte
> >storage elements, and the --> operator should manipulate 4-byte fields as
> >well. -> should still do bytes. So the compiler would only need to use
> >opcodes to store and load 1-byte and 4-byte fields.)
> Another dumb q, couldn't the complier have an input parameter (when run) that
> could switch between the two?
> Byte Word
> Inform 1 test.inf Inform 2 test.inf
> Then the expansion to word addressing and additional opcodes (or features)
> could be ignored unless 2 was entered.
I assume you're talking about compiling to the same VM, but using 4-byte
or 2-byte words. (Not 1 or 2, but 2 and 4.)
Sure, that's possible. My Macintosh C compiler has a switch like this; you
can control whether "int" variables are 2-byte or 4-byte. Either way, the
output is a Macintosh executable. (Although C also has "short int" and
"long int" types that give you a little more choice -- but that's not
really relevant, never mind.)
The advantage would be more efficient use of space, for any game whch uses
less than 64K of memory. On the other hand, I don't know that the gains
would be that great. Current games are pushing 64K, and even if all of
that is storage words which double in size, that's still only another 64K,
and what's 64K these days?
Problem: A 32-bit VM probably *wouldn't* support the Z-machine-style hack
of "packing" string and routine addresses. After all, the only point of
that hack is to be able to store references to >64K memory in a 16-bit
field! So compiling a 16-bit model game file for a 32-bit VM would be
*really* limited; not just 64K of RAM, but 64K memory *total*, ROM *and*
RAM.
Yes, you could make a 32-bit VM which included the Z-machine-style hack
for strings and routines. This is almost certainly not worth it. The
gains, as I said, are not all that large; and I *hate* putting in cruddly
hacks when it's not absolutely necessary.
I think it's actually better to support both the Z-machine as it is, and a
clean new 4-byte VM, rather than making a complicated new VM which handles
both 4-byte and 2-byte game models. It's not the best position from a
standing start, but we've *got* the Z-machine support already.
TenthStone
minds on Thu, 01 Oct 1998 04:46:35 GMT:
>On 1 Oct 1998 01:12:30 GMT, jfra...@dungeon.engr.sgi.com (John
>Francis) wrote:
>
>>I don't think we need to let strings get beyond 64K, though
>
>And two digits is fine for the year, right? (:3
>
>(Just pointing out that, when you're trying to correct for obsolete
>assumptions about how big is 'big enough', it's not a good idea to
>introduce new assumptions. Of course, I rather suspect even the most
>pessemistic Y2K fix assumes a four-digit year... wonder how much
>effort it would be to code a program that could handle *any* year,
>even years orders of magnitude farther in the future than any
>hypothetical 'Big Crunch'? (:3)
It would take a bit of effort, but using the same space that even broken
BIOSes use for year storage, we could increase the maximum number of
different year-identifiers avaible by exactly 65,436% if we just abandoned
ASCII date storage. With four digits we could store year values in excess
of 4 billion.
But that's not going to happen. So as for infinite storage space, you
could create ten-byte memory clusters and allocate them to various uses;
eight bytes of storage and the ninth and tenth a word pointing to the next
cluster. That is,
0000: "12345678"[0001]
0001: "90. "[0000]
would return 1234567890.
-----------
The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
Allen Garvin
I don't think we need to let strings get beyond 64K, though, so the
16-bit length count is probably sufficient.
It might become helpful for reading and manipulating files to allow for
greater lengths.
Andrew Plotkin
> Andrew Plotkin <erky...@netcom.com> wrote:
> I think the whole thing would be too messy to deal with. I'd much
> rather declare (conceptually) that it's an entirely new machine, *not*
> a new version of the Z-machine, and it has entirely new interpreters.
> But someone working alone, in secret, could probably modify Inform and one
> of the interpreters in a pretty short time to handle 32 bits. It'd be
> a bother, but could be done. To specify and develop and entire new machine
> however, would probably involve months of vigorous, vociferous arguing on
> rec.arts.int-fiction, spawning dozens of off-topic discussions and lots of
> posts of misinformation and some hurt feelings. Hm, wait, that's what
> r.a.if is normally like... Anyway, the first would probably be done pretty
> quickly, but the second might take years before coming to fruition.
I bet you're wrong.
I also bet that someone working alone *in public* would do a hell of a lot
better than someone working alone in secret. Glk has benefitted from
public comment, and I haven't let anyone else slow me down. (My own
laziness is not "anyone else". :-)
People yell and scream and flame me sometimes, but that doesn't affect the
work. I'm in charge. I'm getting it done.
Darin Johnson
> I don't think we need to let strings get beyond 64K, though, so the
> 16-bit length count is probably sufficient.
>
> It might become helpful for reading and manipulating files to allow for
> greater lengths.
The workaround to this is easy though. Why does something that huge
have to be a single string anyway? You could easily write a data
structure to get around the problem. The problem really only exists
in the VM's anyway.
--
Darin Johnson
da...@usa.net.delete_me
Bryan Scattergood
> I somehow doubt that a new 32 bit VM will be as widely ported as the
> Z-machine(look how long it's taken to get hugo ported to _anything_)
Of course a 32bit VM won't be ported as widely as the Z-machine. If people are
serious about lifting these restrictions then it *can't* be. The 64K RAM limit
is what makes it possible to support the Z-machine on low-end machines like the
Pilot, Psion3 and 128K Spectrum.
I'm *not* saying that going 32bit is necessarily a bad thing. I just want to be
sure that sacrificing the low end machines is going to gain us something in
return. Inform running on top of a hypothetical Z32 may be a neat hack, but it
isn't a killer app.
Bryan
[With a nasty suspicion we'll get a 32bit VM sorted out just as IA64 takes over
the desktop. Yeah, I know, IF can't possibly need more than 4G ...]
Den of Iniquity
>> but ISTR people here still really liked portablility.
> ^^^^
>I Suspect There R?
I seem to remember (or recall, if you prefer).
--
Den
David Given
>>You could write an Inform compiler that didn't produce z-machine code,
>>but instead code for, forexample, a Pentium processor, and in that
>>case you could have Inform programs that didn't have to care about
>>the 64K limit (you might have to increase the language's word length
>>to 32 bits, though).
>
>You don't have to increase the WORD length - just the size of an address.
>
>introduce a new 32-bit arithmetic data type (a LONG, presumably).
One way of increasing the amount of available memory while leaving the
Z-machine as unchanged as possible would be to take a leaf out of EMS'
book --- use memory windows.
Divide the 64kB RAM space up into eight 8kB windows. Each window can have
a block of memory mapped in. Create some new opcodes --- @malloc, @free,
@map. The program can use @malloc to allocate up to 8kB of memory, and is
given a handle. It can then use this handle to map the memory into one of
the windows, where it can access it. Both handles and addresses would be
16-bits.
So, you could do something like (excuse my syntax):
array = @malloc(4*2);
@map(array, 7);
window7 --> 0 = 0;
window7 --> 1 = 42;
window7 --> 2 = 1234;
window7 --> 3 = -1;
A simple back-end change to the Inform compiler would change object
addresses into block handles, so allowing objects to be stored in memory
blocks; and on startup each window would contain a different 8kB block, so
normal Z-machine programs wouldn't be affected. @map is a fast operation
so there wouldn't be much performance hit.
You could even have a set of special handles for accessing memory-mapped
devices.
Constant SysInfoHandle = -1;
@map(SysInfoHandle, 7);
memfree = window7 --> 0;
The only problems I can see is that you now no longer have any bounds on
how much memory a program will use, so you don't have the
if-it-runs-at-all-it-will-run-to-completion property of present Z-machine
programs, and allocating windows could be a little trickier than it might
first appear.
--
+- David Given ----------------+
| Work: d...@tao.co.uk | All generalizations are incorrect,
| Play: dgi...@iname.com | including this one.
+- http://wiredsoc.ml.org/~dg -+
Jonadab the Unsightly One
Den of Iniquity <dms...@york.ac.uk> wrote in article
> Listen. If what I say is utterly, _utterly_ absurd, such that you
_know_
> it's not true, such as molecules being painted blue and angels
> manufacturing protophyta out of strawberry jelly, then I'm lying
> inventively. If what I say is just utterly absurd, like television
> reception tax and gasoline selling at $5 per gallon all over the
UK, and
> you find it hard to believe, then it's a curious piece of trivia
and
> certainly true (or I believe it to be, anyway). I don't set out to
mislead
> anyone deliberately.
Ah. So if I ever ask you WTUUAOMUA (Was That Utterly Utterly Absurd
Or Merely Utterly Absurd) you'll know what I want to know ;-)
> Unfortunately, as you can imagine, it doesn't always work. My
girlfriend
> still hasn't quite forgiven me for that time I told her about
Giant
> Sparrows, with wingspan as large as an eagle's. Honestly.
Now see, I might have thought that utterly absurd myself. If you
wanted
it to be utterly, utterly absurd you should have explained that you
had a saddle for one in your basement but hadn't used it in
several years now, since moving from Peru, the birds' favourite
nesting ground. Then you could have gone on to describe in
detail the feeder you had used to keep for them, in which you would
put coconuts, which they eat as seeds...
-- jonadab
(email the above name at bright.net)
Jonadab the Unsightly One
Doeadeer3 <doea...@aol.com> wrote in article
> Doe :-) TIA (Den said that was Thanks In Advance, but I don't
know if he was
> fooling.)
Most likely not, because I often see "TIA in advance".
Erik Max Francis
It stands for either "I seem to remember/recall" or "it stands to
reason."
Which is why I don't use such abbreviations; many people flat out don't
know what they mean, and even when they do, they're often ambiguous.
--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon (efnet) / finger m...@sade.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
\
/ Covenants without the sword are but words.
/ Camden
Jonadab the Unsightly One
Ricardo Dague <tri...@hotmail.com> wrote in article
> You could define a constant like SIZEOF_INT, which would be 2 for
16-bit
> machines and 4 for 32-bit.
If we implement a 256-bit VM now, we'll be ahead of the
rest of the world for a change!
In all seriousness, though, I think it would be very, very good
if the new version of Inform could compile from the same
source code to both z8 and whatever the new thing is
with minimal modifications. Sure, you're going to have
to alter the Switches directive, and any code that does *certain*
things won't be compatible. In the libraries any code that
does those certain things can be rigged with conditional
compilation. Yeah, a few things will get broken, but if
there's a nice, accurate, complete list of them with nice
descriptions in English of how to make the changes it
would facilitate greatly the change for authors.
Say, couldn't even Inform stuff like the --> operator
and certain keywords work differently in the two
versions? To break less code? Just a thought.
I expect zasm code would get broken, though,
but most games use very little of it directly, and
as I said the libraries can have conditional
compilation.
Jonadab the Unsightly One
Magnus Olsson <m...@bartlet.df.lth.se> wrote in article
<6uvum8$rbh$1...@bartlet.df.lth.se>...
> >You don't have to increase the WORD length - just the size of an
address.
>
> I didn't mean the size of the machine word, but the size of the
Inform
> language's variables. You can think of the hgh-level language's
> execution model as still another VM on top of the Z-machine, and
> *that* high-level VM has a word size equal to the length of an
address
> - this is necessary since Inform is a typeless language where
pointers
> have to fit in a basic integer variable.
Right. In Inform, any address has to fit in an integer. Period.
Did I mention that typelessness is one of my favourite features
of Inform? I really like it. It would be nice to be able to
determine (for certain) the type of a given variable at run time,
but I wouldn't want to be "boxed in" to a strongly typed language.
Sometimes I really *want* to store one type in a variable one
moment and another type another moment, for example. With
decent commenting this isn't a problem, honest.
> >Mind you, it would probably be a good idea, at that point, to
also
> >introduce a new 32-bit arithmetic data type (a LONG, presumably).
>
> Introducing types to a typeless language is no small undertaking.
And unnecessary. I have a hard time thinking that increasing the
standard integer to 32 bits would break any existing code.
OTOH, if we did that would all our z-code grow by leaps and bounds
and allow only the same amount of game in a larger file, or would
we see a real increase in usable space? Maybe we should get into
bit twiddling...
Jonadab the Unsightly One
Simon 'tufty' Stapleton <nob...@no.bloody.where> wrote in article
> Surely this is the answer to the 'multiple interpreters' issue as
well.
>
> 3 steps.
>
> 1 - Invent new and fixed 32bit Virtual machine. This might or
might
> not be based on the existing z-machine.
It would certainly be built with knowledge of the existing
z-machine and its advantages and disadvantages, at least.
> 2 - Write an interpreter for this VM.
>
> 3 - Write an z-machine interpreter native to the new VM. this
> wouldn't have to be as big as (say) frotz - as it would merely
> handle the mapping from the z-machine to the new VM -
> particularly easy if the new VM is based on z-machine. You
would
> also only need to write one of these as the front end would
> be handled by the interpreter written in stage 2.
>
> Bingo! Backwards compatibility.
The new VM would need the real, actual file support I've
been saying it needs anyhow.
> I assume this has already been thought of. But it suddenly struck
> me as a piece of inspiration, and given how boring my days are
> normally, I thought I'd share it with you. Apologies if this has
> been tedious.
Not at all. Whether it's been thought of before or not, it's a good
idea, IMO. What would also be very nice would be to write a
decent TADS interpreter for the new VM, but that could come later.
Jonadab the Unsightly One
David Given <dg@> wrote in article <907328614.5946.0.nnrp-
> A simple back-end change to the Inform compiler would change
object
> addresses into block handles, so allowing objects to be stored in
memory
> blocks; and on startup each window would contain a different 8kB
block, so
> normal Z-machine programs wouldn't be affected. @map is a fast
operation
> so there wouldn't be much performance hit.
> The only problems I can see is that you now no longer have any
bounds on
> how much memory a program will use, so you don't have the
> if-it-runs-at-all-it-will-run-to-completion property of present
Z-machine
> programs, and allocating windows could be a little trickier than
it might
> first appear.
Assuming you only use the memory pages to swap different
portions of real memory into addressable space that's not
a problem. You just require the interpreter to load the whole
game into real memory from the start even though it won't
need to address it all at once. (One way to force this would
be to read a value from each page as part of the startup
procedure.)
If you use it to allocate memory dynamically at run time
then yes, all bets would be off.
Jonadab the Unsightly One
Andrew Plotkin <erky...@netcom.com> wrote in article
> Yes, you could make a 32-bit VM which included the Z-machine-style
hack
> for strings and routines. This is almost certainly not worth it.
The
> gains, as I said, are not all that large; and I *hate* putting in
cruddly
> hacks when it's not absolutely necessary.
>
> I think it's actually better to support both the Z-machine as it
is, and a
> clean new 4-byte VM, rather than making a complicated new VM which
handles
> both 4-byte and 2-byte game models. It's not the best position
from a
> standing start, but we've *got* the Z-machine support already.
As long as the same *compiler* supports both, it can support them
by compiling to different VMs and that's alright with me,
particularly
since we need the old VM for old, already-compiled games, anyway.
Really, I would want most existing z8 source code to compile
to the new VM with just a changed Switches directive to
v9 or somesuch instead of v8. There would be minor breakages
elsewhere, but, as I said, if the library supported both via
IFDEF and the differences were clearly and exhaustively
documented, I think porting wouldn't be too great a nightmare.
Dark fiber
<1O431...@compuserve.com> wrote:
>Of course a 32bit VM won't be ported as widely as the Z-machine. If people are
>serious about lifting these restrictions then it *can't* be. The 64K RAM limit
>is what makes it possible to support the Z-machine on low-end machines like the
>Pilot, Psion3 and 128K Spectrum.
>
>I'm *not* saying that going 32bit is necessarily a bad thing. I just want to be
>sure that sacrificing the low end machines is going to gain us something in
>return. Inform running on top of a hypothetical Z32 may be a neat hack, but it
>isn't a killer app.
hmm the pilot runs on a 32bit cpu and afaik so does the psion (i not
sure tho.... :) as for maintaining low end machines, personally i dont
see the point. how many people actually copy across games to apple2's,
c64's and spectrums? maybe a handfull at the most? i played, well
attempted to play a few IF games on my pilot.. its not something i'll
ever bother with in the future.
ja ne
-df
Dark Fiber <ent...@tig.com.au>
http://homepages.tig.com.au/~entropy
Head honch of the Ed Wood school of FanFic
Sazan Aisu Fanfiction homeroom
http://www.geocities.com/Tokyo/Ginza/7478
Neil K.
> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
Sir, when you are tired of Neils you are tired of life.
- Neil K.
(an observation; not a threat)
--
t e l a computer consulting + design * Vancouver, BC, Canada
web: http://www.tela.bc.ca/tela/ * email: tela @ tela.bc.ca
Joe Mason
> erky...@netcom.com (Andrew Plotkin) heretically declaimed:
>
>> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
>
> Sir, when you are tired of Neils you are tired of life.
>
> - Neil K.
>
> (an observation; not a threat)
It was this observation, I believe, which led to the tragic suicide rate among
the early formulaters of quantum physics. Strange but true.
Joe
--
I think OO is great... It's no coincidence that "woohoo" contains "oo" twice.
-- GLYPH
David Glasser
> On Fri, 02 Oct 1998 07:03:05 +0100, Bryan Scattergood
> <1O431...@compuserve.com> wrote:
>
> >Of course a 32bit VM won't be ported as widely as the Z-machine. If
> >people are serious about lifting these restrictions then it *can't* be.
> >The 64K RAM limit is what makes it possible to support the Z-machine on
> >low-end machines like the Pilot, Psion3 and 128K Spectrum.
> >
> >I'm *not* saying that going 32bit is necessarily a bad thing. I just want
> >to be sure that sacrificing the low end machines is going to gain us
> >something in return. Inform running on top of a hypothetical Z32 may be a
> >neat hack, but it isn't a killer app.
>
> hmm the pilot runs on a 32bit cpu and afaik so does the psion (i not
> sure tho.... :) as for maintaining low end machines, personally i dont
> see the point. how many people actually copy across games to apple2's,
> c64's and spectrums? maybe a handfull at the most? i played, well
> attempted to play a few IF games on my pilot.. its not something i'll
> ever bother with in the future.
Yes, the Pilot is 32bit. But in general, it doesn't have enough RAM to
play anything huge.
--David Glasser
gla...@NOSPAMuscom.com | http://onramp.uscom.com/~glasser
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Sadie Hawkins, official band of David Glasser: http://sadie.retina.net
"We take our icons very seriously in this class."
Joyce Haslam
> Listen. If what I say is utterly, _utterly_ absurd, such that you _know_
> it's not true, such as molecules being painted blue and angels
> manufacturing protophyta out of strawberry jelly, then I'm lying
> inventively. [...]
Have you tried the one about worn-out electrons? That what the power
station does is re-invigorate them and send them out again? If you
can get a physicist or engineer to swallow that one, you're _flying_.
Joyce.
--
Joyce Haslam
http://argonet.co.uk/users/dljhaslam/ for Gateway to Karos [INFORM]
Powerbase is for RiscOs only
c o m u s @ a r g o n e t . c o . u k
Magnus Olsson
Joe Mason <jcm...@uwaterloo.ca> wrote:
>Neil K. <fake...@anti-spam.address> insribed:
>> erky...@netcom.com (Andrew Plotkin) heretically declaimed:
>>
>>> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
>>
>> Sir, when you are tired of Neils you are tired of life.
>>
>> - Neil K.
>>
>> (an observation; not a threat)
>
>It was this observation, I believe, which led to the tragic suicide rate among
>the early formulaters of quantum physics. Strange but true.
Sorry, Joe, I can't think of an Neils among the foundsers of QM. There's
Niels Bohr, of course, but his spelling kind of ruins the joke.
Drone
Olsson) wrote:
> In article <npvR1.63060$hx3.7...@HME2.newscontent-01.sprint.ca>,
> Joe Mason <jcm...@uwaterloo.ca> wrote:
> >Neil K. <fake...@anti-spam.address> insribed:
> >> erky...@netcom.com (Andrew Plotkin) heretically declaimed:
> >>
> >>> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
> >>
> >> Sir, when you are tired of Neils you are tired of life.
> >>
> >> - Neil K.
> >>
> >> (an observation; not a threat)
> >
> >It was this observation, I believe, which led to the tragic suicide
rate among
> >the early formulaters of quantum physics. Strange but true.
>
> Sorry, Joe, I can't think of an Neils among the foundsers of QM. There's
> Niels Bohr, of course, but his spelling kind of ruins the joke.
I thought it enhanced the joke.
Drone.
Bryan Scattergood
> In article <6uuktu$14...@fido.engr.sgi.com>,
> John Francis <jfra...@dungeon.engr.sgi.com> wrote:
> >
> >introduce a new 32-bit arithmetic data type (a LONG, presumably).
>
> Z-machine as unchanged as possible would be to take a leaf out of EMS'
> book --- use memory windows.
>
> Divide the 64kB RAM space up into eight 8kB windows.
AARGH!! No, no, no ... <whimper>.
I've programmed systems like that. Given a choice between bank-switching (as
on the late Z80 boxes), Intel segment-register hell and something like the
flat 68k memory-model, I'll take the latter. Please.
Backward compatibility with existing Z-code just isn't that important.
> A simple back-end change to the Inform compiler would change object
> addresses into block handles
I'm now confused. I don't think you *need* @map. You just want a way of
packing 32bit addresses into 16bit words. The extra level of indirection you
get from a handle should be enough for that. The VM has a 256K table
somewhere and the conversion is just a lookup.
If the only thing you do with a handle 'a' is index off it using 'a-->i',
and '-->' is used *only* with handles on the left, then you can hide that
detail inside the VM by tweaking the index-and-load opcodes? You lose the
ability to do pointer arithmetic using separately created handles, but even
C doesn't guarantee that ability.
If that isn't true, you could add a new symbol for indexing where the
guarantees do hold, but that could be ugly.
> @map is a fast operation so there wouldn't be much performance hit.
IIRC, on hand-coded Z80 emulators the performance hit for bank-switching is
between 5 and 10%.
Bryan
Paul F. Snively
jcm...@uwaterloo.ca (Joe Mason) wrote:
>Neil K. <fake...@anti-spam.address> insribed:
>> erky...@netcom.com (Andrew Plotkin) heretically declaimed:
>>
>>> PS: Drowning in Inkys, I see. Well, we were getting tired of Neils.
>>
>> Sir, when you are tired of Neils you are tired of life.
>>
>> - Neil K.
>>
>> (an observation; not a threat)
>
>It was this observation, I believe, which led to the tragic suicide rate among
>the early formulaters of quantum physics. Strange but true.
Actually, the early formulaters of quantum physics are neither alive nor
dead until an observer opens the caskets.
>Joe
>--
>I think OO is great... It's no coincidence that "woohoo" contains "oo" twice.
>-- GLYPH
(Apologies to those unfamiliar with the Quantum Mechanics and particularly
Schrödinger's Cat.)
--
----------------------------------------------------------------------------
Paul Snively
<mailto:ch...@mcione.com>
"I had the sense, too, of the illicit side of the casbah, of a kind of
trade in human (or, in this case, executive) flesh." -- Michael Wolff,
"Burn Rate"
Paul F. Snively
<co...@argonet.co.uk> wrote:
>Den of Iniquity <dms...@york.ac.uk> hallucinated:
>
>> Listen. If what I say is utterly, _utterly_ absurd, such that you _know_
>> it's not true, such as molecules being painted blue and angels
>> manufacturing protophyta out of strawberry jelly, then I'm lying
>> inventively. [...]
>
>Have you tried the one about worn-out electrons? That what the power
>station does is re-invigorate them and send them out again? If you
>can get a physicist or engineer to swallow that one, you're _flying_.
Actually--and this isn't a joke--there's a school of thought at the farther
reaches of Quantum Mechanics that suggests that, for all intents and
purposes, there's only _one_ electron in the universe.
Admittedly, it's a very _busy_ electron.
Of course, given the Quantum Mechanics, it's important to remember that
there isn't actually any such particle as an electron at all. In fact,
there aren't particles at all. Nor are there waves. There are just times
when subatomic events look like waves, and times when they look like
particles. As Richard Feynman pointed out, "this doesn't mean that these
subatomic objects are sometimes particles and sometimes waves; it means
that our concepts of 'particle' and 'wave' are weak."
>Joyce.
>
>--
>Joyce Haslam
>http://argonet.co.uk/users/dljhaslam/ for Gateway to Karos [INFORM]
>Powerbase is for RiscOs only
>c o m u s @ a r g o n e t . c o . u k
Paul
Magnus Olsson
Paul F. Snively <ch...@mcione.com> wrote:
>Actually--and this isn't a joke--there's a school of thought at the farther
>reaches of Quantum Mechanics that suggests that, for all intents and
>purposes, there's only _one_ electron in the universe.
>
>Admittedly, it's a very _busy_ electron.
Well, that theory was never intended to be taken very seriously; it is
based on the fact that the equations for a positron (an anti-electron)
are identical to those of an electron going backwards in time. So if
an electron starts out going forward in time, and then "turns about",
emitting a photon in the process, and starts going backwards in time
(though on a different trajectory), it will be the same as if you had
an electron and a positron, both going forwards in time, annihilating
each other to form a photon.
>Of course, given the Quantum Mechanics, it's important to remember that
>there isn't actually any such particle as an electron at all. In fact,
>there aren't particles at all. Nor are there waves. There are just times
>when subatomic events look like waves, and times when they look like
>particles. As Richard Feynman pointed out, "this doesn't mean that these
>subatomic objects are sometimes particles and sometimes waves; it means
>that our concepts of 'particle' and 'wave' are weak."
This is more of a semantic question than a physical one: Feynman's
remark refers to the fact that the concepts of particles and waves in
classical physics do not correspond exactly to those of quantum
mechanics.
So if by "particles" you mean something like classical particles:
little billiard-ball-like things bouncing about, spinning around their
own axes and so on, then it's correct to say that "there are no
particles". However, this most definitely doesn't mean that there is
no such entity as an electron; just that you can't interpret the
excitations of quantum fields (or the vibrational modes of
superstrings, if you believe in those theories) as classical particles
and waves.
Now wasn't that enlightening?
Erik Max Francis
> Well, that theory was never intended to be taken very seriously; it is
> based on the fact that the equations for a positron (an anti-electron)
> are identical to those of an electron going backwards in time. So if
> an electron starts out going forward in time, and then "turns about",
> emitting a photon in the process, and starts going backwards in time
> (though on a different trajectory), it will be the same as if you had
> an electron and a positron, both going forwards in time, annihilating
> each other to form a photon.
In practical terms, what it means is that given a reaction equation, you
can move one term over to the other side of the equation, change it to
its antiparticle, and the equation is still valid (though naturally the
reaction rate may not be the same). So normal beta decay turns a
neutron into a proton, an electron, and an (electron) antineutrino:
n -> p + e- + ~nu.
The above concept means that you can have positron- or neutrino- (but
not antineutrino-) induced beta decay:
n + nu -> p + e-
n + e+ -> p + ~nu.
--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon (efnet) / finger m...@sade.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
\
/ Measure a thousand times and cut once.
/ (a Turkish proverb)
Doeadeer3
In article <6v8j4c$7gb$1...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
Olsson) writes:
>Now wasn't that enlightening?
Always makes me think that Flip Wilson, as Geraldine (comic, playing a woman)
was right.
"What you see, is you what you get."
Doe :-)
Doe doea...@aol.com (formerly known as FemaleDeer)
****************************************************************************
"In all matters of opinion, our adversaries are insane." Mark Twain
LucFrench
I know it's awfully unclean to impliment in C (which badly needs general
purpose bit field type), but what if we were to use a 20 byte VM instead of 16
or 32 bits?
<For those of you using TIN, this was in responce to an extended arguement
about extending the Z-Machine to 32 bits.>
Thanks
Luc "Idiot" French
Andrew Plotkin
> I know it's awfully unclean to impliment in C (which badly needs general
> purpose bit field type), but what if we were to use a 20 byte VM instead of 16
> or 32 bits?
Twenty *bytes*? You're trying to store a complete simulation of the Earth
with an Inform object for each molecule? :)
Yes, see the very large VM thread from a couple of months ago. We went
through all the combinations of 32-bit, 20-bit or 24-bit or 28-bit, and
16-bit. The sole advantage of anything in between 16 and 32 is that you
can fit type info inside the reference.
As I said, I think it's a lousy idea. More details in Dejanews.
Emacs used 8/24. Emacs ran into space problems. I *really* don't want
weird icky VM hacks; we *don't need to squeeze space*. It's not 1973 and
we already know the game files are in the megabyte range. We've already
got solutions for the games that are physically capable of running on an
Apple 2.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
John Francis
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>In article <chewy-ya02408000...@news.mci2000.com>,
>Paul F. Snively <ch...@mcione.com> wrote:
>>Actually--and this isn't a joke--there's a school of thought at the farther
>>reaches of Quantum Mechanics that suggests that, for all intents and
>>purposes, there's only _one_ electron in the universe.
>>
>>Admittedly, it's a very _busy_ electron.
>
>based on the fact that the equations for a positron (an anti-electron)
>are identical to those of an electron going backwards in time.
So, given that fact that the equations are identical, just how would you
propose to demonstrate the falsehood of this interpretation? Just why
would you suggest it is not meant to be taken seriously?
(although, admittedly, I'm not quite sure what it means to say that it
is, in some way, the 'same' electron).
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
Magnus Olsson
Erik Max Francis <m...@alcyone.com> wrote:
>Magnus Olsson wrote:
>
>> Well, that theory was never intended to be taken very seriously; it is
>> based on the fact that the equations for a positron (an anti-electron)
>> an electron starts out going forward in time, and then "turns about",
>> emitting a photon in the process, and starts going backwards in time
>> (though on a different trajectory), it will be the same as if you had
>> an electron and a positron, both going forwards in time, annihilating
>> each other to form a photon.
>
>In practical terms, what it means is that given a reaction equation, you
>can move one term over to the other side of the equation, change it to
>its antiparticle, and the equation is still valid (though naturally the
>reaction rate may not be the same).
Actually, it says more than that: the matrix elements (QM jargon for
thewhat is basically the probability to go from one state to another)
are the same, and any difference in reaction rate depends entirely on
kinematics.
Magnus Olsson
John Francis <jfra...@dungeon.engr.sgi.com> wrote:
>In article <6v8j4c$7gb$1...@bartlet.df.lth.se>,
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>>In article <chewy-ya02408000...@news.mci2000.com>,
>>Paul F. Snively <ch...@mcione.com> wrote:
>>>Actually--and this isn't a joke--there's a school of thought at the farther
>>>reaches of Quantum Mechanics that suggests that, for all intents and
>>>purposes, there's only _one_ electron in the universe.
>>>
>>>Admittedly, it's a very _busy_ electron.
>>
>>based on the fact that the equations for a positron (an anti-electron)
>>are identical to those of an electron going backwards in time.
>
>propose to demonstrate the falsehood of this interpretation?
Count all the electrons and positrons in the universe. If all of them
"really" are only one electron going back and forth in time
(masquerading as a positron when going backwards in time), then it
follows that there is at most one positron more or less than there are
electrons. So if you find, say, 10 electrons more than positrons, then
the hypothesis is wrong.
Of course, this thought experiment may be a bit hard to carry out, but
there does seem to be an excess of matter over antimatter in the
universe, and some theories even predict such an excess.
>Just why
>would you suggest it is not meant to be taken seriously?
I didn't mean that it's wrong (although it probably is), I meant that
it wasn't suggested as a serious physical theory. Besides, I've read
that the person who proposed the idea (I've forgotten who it was) made
the suggestion half in jest. [Pedant mode on] Of course, that leaves
the question open how the person who wrote what I read knew this, but
please note that I didn't say that I *knew* it wasn't meant to be
taken seriously, only that I thought so [Pedant mode off].
A counterchallenge: if you think it was supposed to be taken
seriously, please find a reference or citation where the idea is
proposed as a serious physical theory, and I'll stand corrected.
>(although, admittedly, I'm not quite sure what it means to say that it
>is, in some way, the 'same' electron).
In QM, such questions not only can't be answered, they are
meaningless, since elementary particles aren't individuals and don't
have any identity (any more than one radio wave can be said to be the
same as another one with identical values of all properties). Strange
as it may sound, this is actually an experimental fact; photons follow
Bose-Einstein statistics where there is only one permutation of N
identical particles (as opposed to the common-sense value of N!).
Joe McMahon
Jonadab the Unsightly One <jon...@zerospam.com> wrote:
>
>Did I mention that typelessness is one of my favourite features
>of Inform? I really like it. It would be nice to be able to
>determine (for certain) the type of a given variable at run time,
>but I wouldn't want to be "boxed in" to a strongly typed language.
>
>Sometimes I really *want* to store one type in a variable one
>moment and another type another moment, for example. With
>decent commenting this isn't a problem, honest.
>
feel like it might be possible to port the Inform language to a slightly
different paradigm? Say, as a set of classes for Perl?
(digs in, waiting for the incoming)
--- Joe M.
--
Which is worse, a huge hall full of ATMOSPHERE
or a MAZE full of faux EMT plate?
John Francis
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>In article <6vb5kq$a3...@fido.engr.sgi.com>,
>John Francis <jfra...@dungeon.engr.sgi.com> wrote:
>>In article <6v8j4c$7gb$1...@bartlet.df.lth.se>,
>>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>>>In article <chewy-ya02408000...@news.mci2000.com>,
>>>Paul F. Snively <ch...@mcione.com> wrote:
>>>>Actually--and this isn't a joke--there's a school of thought at the farther
>>>>reaches of Quantum Mechanics that suggests that, for all intents and
>>>>purposes, there's only _one_ electron in the universe.
>>>>
>>>>Admittedly, it's a very _busy_ electron.
>>>
>>>Well, that theory was never intended to be taken very seriously; it is
>>>based on the fact that the equations for a positron (an anti-electron)
>>>are identical to those of an electron going backwards in time.
>>
>>So, given that fact that the equations are identical, just how would you
>>propose to demonstrate the falsehood of this interpretation?
>
>Count all the electrons and positrons in the universe. If all of them
>"really" are only one electron going back and forth in time
>(masquerading as a positron when going backwards in time), then it
>follows that there is at most one positron more or less than there are
>electrons. So if you find, say, 10 electrons more than positrons, then
>the hypothesis is wrong.
Yes - I though of that. But it only takes a small variation of the
theory to substitute a different constant. Maybe there are only
10 electrons (or 100, or ...)
>>(although, admittedly, I'm not quite sure what it means to say that it
>>is, in some way, the 'same' electron).
>
>In QM, such questions not only can't be answered, they are
>meaningless, since elementary particles aren't individuals and don't
>have any identity (any more than one radio wave can be said to be the
>same as another one with identical values of all properties). Strange
>as it may sound, this is actually an experimental fact; photons follow
>Bose-Einstein statistics where there is only one permutation of N
>identical particles (as opposed to the common-sense value of N!).
Common sense and quantum mechanics don't mix. Heck, common sense and
special relativity don't mix, and that's a lot more mainstream.
I'm a mathematician, not a physicist. If the underlying equations
are the same, I tend to think of it as the same theory. It's only the
physicists (or "bloody engineers", as we like to call them :-) who try
to relate the nice abstract theories to the real world. Good luck!
Mark J Musante
> I'm a mathematician, not a physicist. If the underlying equations
> are the same, I tend to think of it as the same theory. It's only the
> physicists (or "bloody engineers", as we like to call them :-) who try
> to relate the nice abstract theories to the real world. Good luck!
I was going to respond with a quote from Richard Feynman, but all the
quote links seem to be broken.
Something to do with the second law of thermodynamics, I suspect.
-=- Mark -=-
Erik Max Francis
> Count all the electrons and positrons in the universe. If all of them
> "really" are only one electron going back and forth in time
> (masquerading as a positron when going backwards in time), then it
> follows that there is at most one positron more or less than there are
> electrons. So if you find, say, 10 electrons more than positrons, then
> the hypothesis is wrong.
I don't see the conclusion, unless you're presuming that the total
charge of these particles is zero, for which there is no a priori
reason.
--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon (efnet) / finger m...@sade.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
\
/ Bachelors have consciences, married men have wives.
/ H.L. Mencken
Magnus Olsson
>
>> Count all the electrons and positrons in the universe. If all of them
>> "really" are only one electron going back and forth in time
>> (masquerading as a positron when going backwards in time), then it
>> follows that there is at most one positron more or less than there are
>> electrons. So if you find, say, 10 electrons more than positrons, then
>> the hypothesis is wrong.
>
>I don't see the conclusion, unless you're presuming that the total
>charge of these particles is zero, for which there is no a priori
>reason.
Simple topology: if at a given time there are, say, 100 electrons in
the universe (without loss of generality, we can assume a small value
of "universe") that are all really the One True Electron going
forwards in time along different spatial trajectories, and at the same
time 110 positrons which are all really the One True Electron going
backwards in time, then the OTE's space-time trajectory has to cross
the same time slice 100 times in the forward direction and 110 times
in the backwards direction, which isn't possible (assuming, of course,
that the time dimension of the universe is open and doesn't "loop
around", which would lead to a whole bunch of very strange effects).
Of course, you could probably think out some strange theory in which
there is only one Electron and where everything else is just as it
should be. I'll want to apply Occam's razor with considerable
force if you do, though.
Drone
Olsson) wrote:
> Of course, you could probably think out some strange theory in which
> there is only one Electron and where everything else is just as it
> should be. I'll want to apply Occam's razor with considerable
> force if you do, though.
>
Occam's razor favours simpler explanations, not 'normal' or 'non-strange'
ones. You could take the perspective that there being only one electron in
the universe is, assuming all else is equal and all phenomena are
accounted for, the simplest possible explanation.
My knowledge of physics extends only to popular representations, though,
so I wouldn't be able to debate fine points with you.
Drone.
Erik Max Francis
> BTW, is there also some formula that predicts how likely and how soon
> a raif
> thread will go off-topic?
Yes: immediately.
Darin Johnson
> >Sure, just give me a little time, please.
>
> Unfortunately, you can't have any time; you must count every single one
> in one instant. Sorry.
But if there's really only just one electron, that means it's been all
over the darn place. But an electron can be described as just a
probability field, the electron itself not really existing at any
particular place. This means that an extremely critical part of the
physical and chemical basis of the universe is relying upon a single
probability field. But if we observe that electron, the probability
field will collapse because Heisenberg Uncertainty Principle! This
means that the whole thing could just end at any moment!!! And it
will end at the moment that Schroedinger's Cat realizes if it's dead
or alive!
Someone's gotta do something about that cat before it's too late!
AAAAAHHHHHHHH!!!
(Sorry, late at night, I'm getting groggy. Maybe I made a mistake in
my math.)
--
Darin Johnson
da...@usa.net.delete_me
Jon Petersen
>
> John Francis (jfra...@dungeon.engr.sgi.com) wrote:
> > In article <19981006205607...@ngol05.aol.com>,
> > Doeadeer3 <doea...@aol.com> wrote:
> > >
> > >BTW, is there also some formula that predicts how likely and how soon a raif
> > >thread will go off-topic?
>
>
> The aged gouda at the Pennsylvania Macaroni Company is the best damn
> cheese I've ever tasted.
>
> --Z
>
Is _Speaker for the Dead_ any good? Also, I bought this book, _Shadow
Claw_, by Gene Wolfe, for $2 at a student store sale, and was wondering
if it was worth reading.
Jon
Doeadeer3
In article <6vd66u$fh7$1...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
Olsson) writes:
>Count all the electrons and positrons in the universe.
Sure, just give me a little time, please.
I probably have been hanging around raif too long, the OT in this thread seems
almost like a logicial progression (Z-Machine to Quantum Physics).
BTW, is there also some formula that predicts how likely and how soon a raif
thread will go off-topic? I am really beginning to suspect there is one (but it
probably changes when you look at it).
TenthStone
minds on 07 Oct 1998 00:56:07 GMT:
>In article <6vd66u$fh7$1...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
>Olsson) writes:
>>Count all the electrons and positrons in the universe.
>
>Sure, just give me a little time, please.
Unfortunately, you can't have any time; you must count every single one
in one instant. Sorry.
>BTW, is there also some formula that predicts how likely and how soon a raif
>thread will go off-topic? I am really beginning to suspect there is one (but it
>probably changes when you look at it).
Iniquitous's Theorem: r(p^2)n-hat = c
where r is the rate of interest in the thread, p is the number of people
reading the thread, n-hat is the estimated number of posts before the
thread goes off-topic, and c is a constant depending on the subject of the
thread. Units:
r in posts per person squared
p in people
n-hat in posts
Lower values of c just mean that the thread is more likely to go
off-topic. Threads about interesting ideas for new works, e.g., have
c-values of significantly less than .001.
In short, the more interested people are in a thread and the more people
are paying attention to it, the more likely it is to go off-topic the
sooner. i.e. people naturally tend to change the subject.
-----------
The imperturbable TenthStone
tenth...@hotmail.com mcc...@erols.com mcc...@gsgis.k12.va.us
Joe Mason
>
>BTW, is there also some formula that predicts how likely and how soon a raif
>thread will go off-topic? I am really beginning to suspect there is one (but it
>probably changes when you look at it).
There's really only one thread in r.a.i-f. It just crosses the newsgroup
many times.
John Francis
>thread will go off-topic?
Do you know of any other online dictionaries besides m-w and the OED?
Andrew Plotkin
> In article <19981006205607...@ngol05.aol.com>,
> Doeadeer3 <doea...@aol.com> wrote:
> >
> >BTW, is there also some formula that predicts how likely and how soon a raif
> >thread will go off-topic?
> Do you know of any other online dictionaries besides m-w and the OED?
The aged gouda at the Pennsylvania Macaroni Company is the best damn
cheese I've ever tasted.
--Z
--
Jonadab the Unsightly One
Neil K. <fake...@anti-spam.address> wrote in article
<fake-mail-0310981129240001@rich-
> Den of Iniquity <dms...@york.ac.uk> hallucinated:
> > Sparrows, with wingspan as large as an eagle's. Honestly.
>
> Whoah, man. Like, what are you on?
Sleep Deprivation, most likely ;-)
-- jonadab
(email the above name at bright.net)
Jonadab the Unsightly One
Joyce Haslam <co...@argonet.co.uk> wrote in article
<488f780...@argonet.co.uk>...
> Have you tried the one about worn-out electrons? That what the
power
> station does is re-invigorate them and send them out again? If you
> can get a physicist or engineer to swallow that one, you're
_flying_.
Rather like asking your doctor about HCE?
Personally, I like the "darksucker" theory.
Jonadab the Unsightly One
> Of course, given the Quantum Mechanics, it's important to remember
that
> there isn't actually any such particle as an electron at all. In
fact,
> there aren't particles at all. Nor are there waves. There are just
times
> when subatomic events look like waves, and times when they look
like
> particles. As Richard Feynman pointed out, "this doesn't mean that
these
> subatomic objects are sometimes particles and sometimes waves; it
means
> that our concepts of 'particle' and 'wave' are weak."
I think particles and waves are two different *models* for
explaining subatomic stuff (note use of technical jargon
"stuff"), similarly to how covalent and ionic bonding are
two different models for explaining chemical stuff. Neither
is accurate, but both explain some behaviors, and both
help us to understand a little better what's going on --
as long as we keep in mind that they are, in fact, just
models.
Of course, it's all pretty moot once you're aware of
the Spam Can Totality.
Jonadab the Unsightly One
<361acab...@news.erols.com>...
> >>Count all the electrons and positrons in the universe.
> >
> >Sure, just give me a little time, please.
>
> Unfortunately, you can't have any time; you must count every
single one
> in one instant. Sorry.
General Kxtg, prepare your troops for war. We have a task to
perform, and we haven't been given enough time to complete it.
Your mission is to conquer the Milky Way galaxy, which we
will then feed into our Space-->Time converters. Good luck.
> Iniquitous's Theorem: r(p^2)n-hat = c
> where r is the rate of interest in the thread, p is the number of
people
> reading the thread, n-hat is the estimated number of posts before
the
> thread goes off-topic, and c is a constant depending on the
subject of the
> thread. Units:
> r in posts per person squared
> p in people
> n-hat in posts
> Lower values of c just mean that the thread is more likely to go
> off-topic. Threads about interesting ideas for new works, e.g.,
have
> c-values of significantly less than .001.
>
> In short, the more interested people are in a thread and the more
people
> are paying attention to it, the more likely it is to go off-topic
the
> sooner. i.e. people naturally tend to change the subject.
What we need, then, is a table of approximate c-values for
various topics.
Magnus Olsson
Darin Johnson <da...@usa.net.removethis> wrote:
>mcc...@erols.com (TenthStone) writes:
>
>> >Sure, just give me a little time, please.
>>
>> Unfortunately, you can't have any time; you must count every single one
>> in one instant. Sorry.
>
>over the darn place. But an electron can be described as just a
>probability field, the electron itself not really existing at any
>particular place. This means that an extremely critical part of the
>physical and chemical basis of the universe is relying upon a single
>probability field. But if we observe that electron, the probability
>field will collapse because Heisenberg Uncertainty Principle! This
>means that the whole thing could just end at any moment!!! And it
>will end at the moment that Schroedinger's Cat realizes if it's dead
>or alive!
I hesitate to tell you this, but it won't help if you assume that
the One Electron hypothethis is false. You'll simply replace a one-
particle state with a many-particle state, which will collapse the
moment the Cat
[ universe not responding - still trying ]
Jonadab the Unsightly One
Jon Petersen <en...@ucla.edu> wrote in article
<361B0C...@ucla.edu>...
> Is _Speaker for the Dead_ any good?
IMO yes. But reading Ender's War first is a good idea.
> Also, I bought this book, _Shadow
> Claw_, by Gene Wolfe, for $2 at a student store sale, and was
wondering
> if it was worth reading.
Can't say about that one.
Jonadab the Unsightly One
John Francis <jfra...@dungeon.engr.sgi.com> wrote in article
>
> Do you know of any other online dictionaries besides m-w and the
OED?
Yes.
http://www.fwi.uva.nl/~mes/jargon/
Magnus Olsson
John Francis <jfra...@dungeon.engr.sgi.com> wrote:
>In article <6vd66u$fh7$1...@bartlet.df.lth.se>,
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>>"really" are only one electron going back and forth in time
>>(masquerading as a positron when going backwards in time), then it
>>follows that there is at most one positron more or less than there are
>>electrons. So if you find, say, 10 electrons more than positrons, then
>>the hypothesis is wrong.
>
>theory to substitute a different constant. Maybe there are only
>10 electrons (or 100, or ...)
Well, in that case the hypothesis loses its alluring simplicity,
doesn't it?
Magnus Olsson
Drone <foxg...@globalserve.net> wrote:
>In article <6vdv0m$alk$1...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
>Olsson) wrote:
>
>> Of course, you could probably think out some strange theory in which
>> there is only one Electron and where everything else is just as it
>> should be. I'll want to apply Occam's razor with considerable
>> force if you do, though.
>>
>
>Occam's razor favours simpler explanations, not 'normal' or 'non-strange'
>ones.
Did I ever claim the opposite?
I posted a rather too short and snotty response earlier, which I've
now cancelled. Here's a more comprehensive reply:
My PhD is in theoretical particle physics, so I'm rather used to
theories that are decidedly "strange" in the sense of "not
normal". I'm also used to the tradition of regarding simple theories
as beuatiful.
So what's wrong with the One Electron hypothesis? It's very simple,
and quite elegant, I'm not arguing with that, and I'm not tying to apply
Occam's razor here either.
But Drone is quoting me out of context. The text that he snipped was about
a way of falsifying the hypothesis under certain assumptions. What I
wrote was essentially that the One Electron hypothesis in its simplest
form doesn't seem to agree with other theories, or (which is of course
the crucial test) with the world we actually observe.
I then made the point that you can of course always patch up the
hypothesis by adding things ad-hoc to make it work. For example, you
can get around my argument about the number of electrons vs. the
number of positrons by adding assumptions that the time dimension
"wraps around".
My point is that once you start making that kind of ad-hoc
assumptions, the hypothesis isn't so simple anymore.
And *then* it's time for Occam and his razor.
To summarize my thoughts about the One Electron hypothesis: sure, it's
simple and beautiful. I just don't think it holds water in its
simplest form (there are other, deeper, difficulties with it in
addition to the number of particles - what about "loop diagrams", for
example, and what happens when you add bosons to your theories, not to
speak of supersymmetry and strings?). If you start adding assumptions
and constraints to make it work, then it's no longer so simple and
beautiful. And even without these considerations, you'll still have to
define what you mean by movement backwards in time, and you'll have to
invent some mechanism that connects all the world-lines at the
beginning and end of time. And how does it work if time isn't finite?
Enter Occam.
Besides, the hypothesis really is unnecessary: the two things that it
explains, viz. that all electrons are indistinguishable, and the
symmetry between particles and antiparticles, both follow directly
from the postulates of relativistic quantum field theory (the latter
in the form of what is called CPT invariance). You don't have to
invoke any ideas about there being only one Electron to "explain"
these things.
Finally, a connection back to our earlier, theological, discussions:
When I first heard of the One Electron idea, when I was doing freshman
physics, I thought it was just as neat as you think it is. So I
mentioned it to a classmate, one of the most cynical people I've ever
known. His sarcastic comment was: "So there's only One Electron? I
guess it's supposed to be God."
Joyce Haslam
> > Have you tried the one about worn-out electrons?
> Rather like asking your doctor about HCE?
TLAs again? What, pray tell, is HCE?
> Personally, I like the "darksucker" theory.
Me too.
Joyce.
--
Joyce Haslam
http://argonet.co.uk/users/dljhaslam/ for Gateway to Karos [INFORM]
Powerbase is for RiscOs only
c o m u s @ a r g o n e t . c o . u k
Stephen Granade
> There's really only one thread in r.a.i-f. It just crosses the newsgroup
> many times.
In that case, I'm waiting to see a couple of anti-threads. Hopefully
they'll annihilate the threads I'm not as interested in.
Stephen
--
Stephen Granade | Interested in adventure games?
sgra...@phy.duke.edu | Visit Mining Co.'s IF Page
Duke University, Physics Dept | http://interactfiction.miningco.com
Martin Dransfield
> Also, I bought this book, _Shadow Claw_, by Gene Wolfe, for $2 at a
> student store sale, and was wondering if it was worth reading.
Oh God yes. Look it up at amazon.com and read the reviews. Far more
eloquent than I could manage.
--
Martin
Jurgen Lerch)
David Given <dg@> wrote:
> One way of increasing the amount of available memory while leaving the
> Z-machine as unchanged as possible would be to take a leaf out of EMS'
> book --- use memory windows.
> Divide the 64kB RAM space up into eight 8kB windows. Each window can have
> a block of memory mapped in. Create some new opcodes --- @malloc, @free,
> @map. The program can use @malloc to allocate up to 8kB of memory, and is
> given a handle. It can then use this handle to map the memory into one of
> the windows, where it can access it. Both handles and addresses would be
> 16-bits.
ARG! NO!
Apart from smelling badly of Intel I always thought that one of
the main reasons for using Inform/TADS/Alan/whatever instead of C
or Modula was that we don't need to care for those things. And one
of these no-programming-experience-beginners would be *scared* -
and should be, too!
Ad Astra!
JuL
--
ler...@uni-duesseldorf.de Realit"at ist eine Kr"ucke f"ur
J"urgen ,,JuL'' Lerch diejenigen, die mit der Fantasie nicht
http://sunserver1.rz.uni-duesseldorf.de/~lerchj/ zurechtkommen
Joe Mason
>
>IMO yes. But reading Ender's War first is a good idea.
Game! Game! It's _Ender's Game_!
Ender