[Glulx] Text compression
Andrew Plotkin
algorithms. Not much, but here's what I've got. The values are compression
ratios; 1.0000 means no compression, 0.0001 means it compressed incredibly
small.
No encoding: 1.0000
Word Huffman: 0.7861
Z-machine (v5) encoding: 0.7335
Character Huffman: 0.5894
The test data was the game text of Gareth Rees's Christminster, which you
can download from ftp.gmd.de. (You'll have to get Inform 5.5 and the
5/whatever libraries, then compile with the Inform -r switch to get the
game text out.)
My test source code is on the web page:
http://www.eblong.com/zarf/glulx/
I haven't tried any other schemes, although I have several suggestions
archived in email. I'll try to get to them.
If you want to run your own experiments, download my test code and write
your own compression and decompression functions. There is documentation
in there on exactly how to do this. I've already written all the support
code -- reading in text, breaking it into words if appropriate, measuring
the compression ratio. All you have to do is compress and decompress. And
beat that 59% mark. :)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Jonadab the Unsightly One
> Character Huffman: 0.5894
> All you have to do is compress and decompress. And
> beat that 59% mark. :)
That's going to be pretty hard to beat. If you were
compressing whole pages of text at one go that would
be one thing, but we're talking about compressing each
string individually, IIUC, so I expect 59% is pretty
close to as good as you're going to do, unless you've
got some kind of special case (say, a set of strings
that by some odd coincidence or special design can
be generated from a fractal seed or somesuch).
I'd be happy to be proved wrong, of course.
-- jonadab
I've given up spamblocking; it wasn't working all that
well anyway; my email address is now correct in the headers.
Hugh Allen
>I've devoted a bit of spare time to testing different text compression
>algorithms.
Amdahl's Law was conceived with parallel processing in mind, but it applies
equally well to compression of multi-part files.
If you have a story file which is (say) 40% code and 60% text and you
manage by heroic effort to compress the text to 30% of its size, the file is
only compressed to (0.4 + 0.6*0.3) = 58%.
zarf, do you have any statistics about what percentage of a typical story is
code? I know it will be more in glulx than in z-code.
If we want to bother with compression we should do it to both text and code,
or we are wasting our effort.
I can imagine that VM intructions are quite compressible, but are their
parameters? Some thoughts:
You could save space by restricting pointers to the minimum
number of bits needed to address the memory used by a particular program
(story). But can you distinguish pointers from other miscellaneous data?
I think BTW that 32-bit integers is overkill for IF (when used as numbers
in a program). 16-bit should suffice.
Routine addresses could be represented by indices like they are in Hugo.
(with a table of routine addresses in the header)
Code (jump) addresses could be signed 16-bit(say) integers. You almost never
want to jump to a different routine. More bits might be needed if code was
compressed and thus not byte-aligned. Better still, you could have a
variable-length code for jump addresses (eg. give the number of bits needed
first, Huffman-coded or just unary. See compression textbooks for other
schemes). Or use a table of jump labels as for routine addresses.
Hugh
Hugh Allen
>That's going to be pretty hard to beat. If you were
>compressing whole pages of text at one go that would
>be one thing, but we're talking about compressing each
>string individually, IIUC, so I expect 59% is pretty
>close to as good as you're going to do, unless you've
>got some kind of special case (say, a set of strings
>that by some odd coincidence or special design can
>be generated from a fractal seed or somesuch).
>
>I'd be happy to be proved wrong, of course.
You are. You don't compress each string completely separately.
They have common substrings and other redundancies. It's not
really that different from compressing their concatenation. You
just have to maintain the ability to extract each string separately.
Hugh
Andrew Plotkin
> Andrew Plotkin <erky...@netcom.com> wrote:
>
>> Character Huffman: 0.5894
>
>> All you have to do is compress and decompress. And
>> beat that 59% mark. :)
>
> compressing whole pages of text at one go that would
> be one thing, but we're talking about compressing each
> string individually, IIUC, so I expect 59% is pretty
> close to as good as you're going to do, unless you've
> got some kind of special case (say, a set of strings
> that by some odd coincidence or special design can
> be generated from a fractal seed or somesuch).
That Huffman algorithm *already* includes gathering data from the entire
text. It's not Huffman-compressing each individual string. They share a
common table.
Andrew Plotkin
> Andrew Plotkin <erky...@netcom.com> wrote:
>>algorithms.
>
> Amdahl's Law was conceived with parallel processing in mind, but it applies
> equally well to compression of multi-part files.
>
> If you have a story file which is (say) 40% code and 60% text and you
> manage by heroic effort to compress the text to 30% of its size, the file is
> only compressed to (0.4 + 0.6*0.3) = 58%.
Yes, yes. This is why I've left it as an afterthought. :)
I'm willing to do at least Huffman encoding; it's easy, it's pretty good,
and it has the side benefit of obscuring cleartext in the game file. Even
if it only saves 15% or 20% total space in the final product, that's worth
the (small) effort.
> zarf, do you have any statistics about what percentage of a typical story is
> code? I know it will be more in glulx than in z-code.
I posted some statistics a few months ago, but I've made a couple of
improvements since then. Hang on...
For Advent (no debugging or strict mode):
+---------------------+ 00003c
| code |
+---------------------+ 0113b3
| strings |
+=====================+ 023000
.... global variables and arrays
+---------------------+ 02444d
.... objects and property tables
+=====================+ 02bddf
.... grammar and dictionary tables
+---------------------+ 02f800
So, almost equal amounts of code and text.
> If we want to bother with compression we should do it to both text and code,
> or we are wasting our effort.
Failing to do a task is never a waste of effort. It may be a waste of time
and space, but not effort. :-)
> I can imagine that VM intructions are quite compressible, but are their
> parameters?
I've already done a fair amount of work in making sure that both the
instructions and parameters are small. You can generally drop leading
zeroes in a two- or four-byte field, for example. (The compiler I've got
doesn't take full advantage of this, but it's not totally lame about it
either.)
Inform is rather heavily built around the idea that There Are Only Values,
and no difference between pointers and integers. I decided early on to
keep this in Glulx Inform. It keeps the library code nearly unchanged, and
in the end, ease of transition (from Z-machine to Glulx) is more important
than compression.
Similarly, I decided that every object reference is an address, because
it's easy and Z-machine Inform *partially* works that way. It means that
routines and strings are referred to by four-byte fields, which -- as you
note -- is nonoptimal, but it makes them easy to work with.
Have you read the spec?
Hugh Allen
just trying to use shorter instructions/operands.
(and to answer zarf's question, no I haven't read much of the glulx standard ;-)
Here's the idea:
Compilers tend to generate quite repetitive code (ask the author of
"disinformation"). You could add a post-processor to the compiler which looks
for common sequences of instructions and turns them into "routines". I use that
word in quotes because it would probably be better to have them access the
stack frame of the calling routine than make them ordinary routines with
arguments and local variables.
You would have to look for common bits of code with no jumps or labels in them
(calls and returns would be OK). Or you could even allow jumps/labels, with some
trickery. Maybe.
Hugh
Jonadab the Unsightly One
> That Huffman algorithm *already* includes gathering data from the entire
> text. It's not Huffman-compressing each individual string. They share a
> common table.
Yes, I figured that. Otherwise you'd have to store a table
for each string, which would be wildly inefficient.
R. Alan Monroe
>However, is there really a point in compressing texts and (non-graphic)
>game files today? (Except as a way to encrypt the text.) Or is it just a
>left-over from the "old days", I sometimes wonder. Even Palm machines have
>megabytes of RAM.
HERESY!!
Smaller is better. Period.
:^)
Have fun
Alan
Aquarius
>However, is there really a point in compressing texts and (non-graphic)
>game files today? (Except as a way to encrypt the text.) Or is it just a
>left-over from the "old days", I sometimes wonder. Even Palm machines have
>megabytes of RAM.
[insert standard bitch about this here]
There are a fair few people still running IF on old machines, as far
as I know. One of the things that I like about it is that it gives me
something to use my clapped out old 286 for -- there are basically no
system requirements for playing IF (or at the least, very minimal
ones). Chopping off the lower, poorer section of the market with the
"You can play this great game as long as you have a good machine"
seems a little unfair, and slightly contrary to the retro nature of IF
in general? Of course, not everyone agrees with me about IF being
retro anyway....
Aquarius
--
http://www.kryogenix.albatross.co.uk/
"Gibberish is unintelligible sounds. Even Aq, on a
bad day, does better than that." -- Zubrette, afe
Jonadab the Unsightly One
> HERESY!!
> Smaller is better. Period.
> :^)
Here's a notion... it doesn't really make any difference to the
glulx spec (well, not as such), and it doesn't reduce RAM
requirements, but it saves secondary storage space. What if the
interpreter could be fed a stardard archive file (say, a ZIP or TGZ
or somesuch -- anything really common will do), automatically find
the glulx file in there (assuming there is exactly one with the same
base filename as the archive), read it, store saved games in the same
archive with the game itself, and so forth? This would be an
optional feature for interpreters, since if yours doesn't support it
the worst case is you have to unzip the thing before you can play it.
It would be advantageous, however, if all major glulx interpreters
supported the same archive format this way so that the if-archive
could store them in that format.
Thoughts?
John W. Kennedy
> I think BTW that 32-bit integers is overkill for IF (when used as numbers
> in a program). 16-bit should suffice.
No. Quite apart from anything else, it puts a severe limitation on
realistic handling of money.
--
-John W. Kennedy
-rri...@ibm.net
Compact is becoming contract
Man only earns and pays. -- Charles Williams
Adam J. Thornton
John W. Kennedy <rri...@ibm.net> wrote:
>Hugh Allen wrote:
>
>> I think BTW that 32-bit integers is overkill for IF (when used as numbers
>> in a program). 16-bit should suffice.
>
>No. Quite apart from anything else, it puts a severe limitation on
>realistic handling of money.
Does it?
When I have $655.35 in my pocket, I honestly probably don't care much about
the pennies.
When I've got $65535 in my bank account, I'll be happy to round to the
nearest $10.
And on the day when I've got $65.5 billion, what's a million here or there?
Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Irene Callaci
<rri...@ibm.net> wrote:
>Hugh Allen wrote:
>
>> I think BTW that 32-bit integers is overkill for IF (when used as numbers
>> in a program). 16-bit should suffice.
>
>No. Quite apart from anything else, it puts a severe limitation on
>realistic handling of money.
You said it. I'm struggling with that now. My one-dollar bills
have a value of 100 (nickels == 5, dimes == 10, quarters == 25),
so a twenty-dollar bill has a value of 2000. A hundred-dollar
bill has a value of 10000. If you want to add up all your money,
it doesn't take long before it overflows.
irene
Kathleen M. Fischer
> You said it. I'm struggling with that now. My one-dollar bills
> have a value of 100 (nickels == 5, dimes == 10, quarters == 25),
> so a twenty-dollar bill has a value of 2000. A hundred-dollar
> bill has a value of 10000. If you want to add up all your money,
> it doesn't take long before it overflows.
Off the topic if 32 vs. 16-bit, but with regards to your game:
If you don't use pennies then couldn't you have nickels be
your base unit? So a nickel=1, dime=2, quarter=5, $1 = 20,
$20 = 400 and $100 = 2000? 32767 nickels = $1638.35. Not a lot
of dough, but it's better than $327.67 :)
Kathleen (math and mornings don't always mix)
--
*******************************************************************
* Kathleen M. Fischer *
* kfis...@greenhouse.nospam.gov (nospam = l l n l) *
** "Don't stop to stomp ants while the elephants are stampeding" **
Iain Merrick
[...]
> When I have $655.35 in my pocket, I honestly probably don't care much about
> the pennies.
>
> When I've got $65535 in my bank account, I'll be happy to round to the
> nearest $10.
>
> And on the day when I've got $65.5 billion, what's a million here or there?
Fair enough.
So when are you releasing floating_point.inf?
Irene Callaci
<kfis...@greenhouse.nospam.gov> wrote:
>Irene Callaci wrote:
>> You said it. I'm struggling with that now. My one-dollar bills
>> have a value of 100 (nickels == 5, dimes == 10, quarters == 25),
>> so a twenty-dollar bill has a value of 2000. A hundred-dollar
>> bill has a value of 10000. If you want to add up all your money,
>> it doesn't take long before it overflows.
>
>Off the topic if 32 vs. 16-bit, but with regards to your game:
>
>If you don't use pennies then couldn't you have nickels be
>your base unit? So a nickel=1, dime=2, quarter=5, $1 = 20,
>$20 = 400 and $100 = 2000? 32767 nickels = $1638.35. Not a lot
>of dough, but it's better than $327.67 :)
I suppose I could, but I wanted a system I could drop into
any game without wondering six months from now what in the
world I had done. I have a COUNT MONEY action which is very
simple (basically, sum/100 and sum%100). If I used a value
of 1 for nickels, 2 for dimes, etc., I'd have a harder time
printing the value of 3 nickels, 2 dimes, 6 quarters, 4
one-dollar bills, a five and a twenty. Hmmm...and what about
making change if nickels == 1, dimes == 2, etc.? I'm sure
it can be done, but I'm afraid my coding skills run more
along the lines of 545/100 = 5.45. :)
irene
Kathleen M. Fischer
> >If you don't use pennies then couldn't you have nickels be
> >your base unit? So a nickel=1, dime=2, quarter=5, $1 = 20,
> >$20 = 400 and $100 = 2000? 32767 nickels = $1638.35. Not a lot
> >of dough, but it's better than $327.67 :)
>
> I suppose I could, but I wanted a system I could drop into
> any game without wondering six months from now what in the
> world I had done. I have a COUNT MONEY action which is very
> simple (basically, sum/100 and sum%100). If I used a value
> of 1 for nickels, 2 for dimes, etc., I'd have a harder time
> printing the value of 3 nickels, 2 dimes, 6 quarters, 4
> one-dollar bills, a five and a twenty. Hmmm...and what about
> making change if nickels == 1, dimes == 2, etc.? I'm sure
> it can be done, but I'm afraid my coding skills run more
> along the lines of 545/100 = 5.45. :)
Hey, no one ever said making money is easy...
Kathleen :)
Eric O'Dell
wrote:
>When I have $655.35 in my pocket, I honestly probably don't care much about
>the pennies.
>
>When I've got $65535 in my bank account, I'll be happy to round to the
>nearest $10.
>
>And on the day when I've got $65.5 billion, what's a million here or there?
That might work. On the other hand, the above method sure puts a
damper on the realistic handling of accountants.
-E.
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
http://members.tripod.com/~abadger
Eric O'Dell
Callaci) wrote:
>I suppose I could, but I wanted a system I could drop into
>any game without wondering six months from now what in the
>world I had done. I have a COUNT MONEY action which is very
>simple (basically, sum/100 and sum%100). If I used a value
>of 1 for nickels, 2 for dimes, etc., I'd have a harder time
>printing the value of 3 nickels, 2 dimes, 6 quarters, 4
>one-dollar bills, a five and a twenty. Hmmm...and what about
>making change if nickels == 1, dimes == 2, etc.? I'm sure
>it can be done, but I'm afraid my coding skills run more
>along the lines of 545/100 = 5.45. :)
You could always create your own 32-bit values by combining a pair of
16-bit values, which was what we had to do in the old days before
native 32-bit processors (and what we have to do now to produce 64-bit
values). It's not terrifically complicated. I'm not sure how it would
work in Inform, but you'd need to create functions to handle your
32-bit values without (directly) using the built-in operators to
manage them.
Jon Zeppieri
memory....
Why should an IF VM use 16 bit words? Presumably, to save memory. I
understand that some people like the idea of playing the newest IF on
the oldest computers, but that hardly seems compelling. And as for
PDAs: in a few years, they won't have many memory restrictions,
either. (Compaq/Digital's Itsy, for example, has 64M.)
-jaz
In article <7nkh8g$8tp$1...@cnn.Princeton.EDU>,
ad...@princeton.edu (Adam J. Thornton) wrote:
> Does it?
>
> When I have $655.35 in my pocket, I honestly probably don't care much
about
> the pennies.
>
> When I've got $65535 in my bank account, I'll be happy to round to the
> nearest $10.
>
> And on the day when I've got $65.5 billion, what's a million here or
there?
>
> Adam
> --
> ad...@princeton.edu
> "My eyes say their prayers to her / Sailors ring her bell / Like a
moth
> mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
>
--
Don't bother replying to the above email address;
I'll never check it. The actual address is my
first name at eease dot com.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
ct
Eric O'Dell <eod...@pobox.com> wrote:
>>And on the day when I've got $65.5 billion, what's a million here or there?
>
>damper on the realistic handling of accountants.
> BRING REVOLUTION
The revolution comes. The accountants are put up against the handily
nearby brick wall.
> SHOOT ACCOUNTANTS
Shot. The politicians are put against said brick wall...
regards, ct
John W. Kennedy
>
> In article <379DC441...@ibm.net>,
> John W. Kennedy <rri...@ibm.net> wrote:
> >Hugh Allen wrote:
> >
> >> I think BTW that 32-bit integers is overkill for IF (when used as numbers
> >> in a program). 16-bit should suffice.
> >
> >No. Quite apart from anything else, it puts a severe limitation on
> >realistic handling of money.
>
>
> When I have $655.35 in my pocket, I honestly probably don't care much about
> the pennies.
...but it breaks mimesis to have to pay one pound for, say, a bagel.
Hugh Allen
>You could always create your own 32-bit values by combining a pair of
>16-bit values, which was what we had to do in the old days before
>native 32-bit processors (and what we have to do now to produce 64-bit
>values). It's not terrifically complicated. I'm not sure how it would
>work in Inform, but you'd need to create functions to handle your
>32-bit values without (directly) using the built-in operators to
>manage them.
Or better still, have them implemented in the compiler, so like in C you would
declare a variable (or property) to be a "long int" instead of an "int" (or
something equivalent but Informese) and then just use the normal arithmetic
operators on it. Of course this would require changing Inform and some people
might not like the "inconvenience" of having to declare the types of
some variables.
*rant on*
BTW I (and most of the CS community) think that "strong typing" is a Good
Thing(tm). If you declare the types of *all* variables (and properties and
function arguments), it
1. Makes your program more understandable and maintainable.
2. Allows the compiler to check for some kinds of programming errors at
compile-time.
3. Allows the compiler to generate more efficient code (in languages, unlike
Inform, which have a decent set of built-in and derived types, not just a
16-bit word which is used for everything)
4. Allows a debugger to print the value of a variable without the user having
to supply its type at debug time (BTW TADS 2.50 achieves this with run-time
typing which is not as good as strong typing but better than no typing).
5. etc...
* rant off *
Hugh
Jonadab the Unsightly One
> > When I have $655.35 in my pocket, I honestly probably don't care much about
> > the pennies.
>
> ...but it breaks mimesis to have to pay one pound for, say, a bagel.
Depends where you buy it.
There are places where you could easily pay twice that.
Jonadab the Unsightly One
> *rant on*
>
> BTW I (and most of the CS community) think that "strong typing" is a Good
> Thing(tm).
Then you'll want to stay far away from Inform, because
pretty much any variable can be any type depending on
what you store in it. The compiler won't bat an eye
at the following (I think; I may have the syntax wrong
for a couple of them, as I'm rusty):
foo = "The quick brown fox jumped over lazy dogs";
foo = 'foo';
foo = #n$x;
foo = ##Take;
foo = 42;
foo = bar->baz;
foo = bar-->baz;
foo = DiningRoomChair;
foo = MetaClass(DiningRoomChair);
foo = #r$TakeSub; ! I'm especially unsure of this syntax.
foo = description;
foo = NPC.description; ! a property that holds a string or routine
foo = NPC.number; ! a property that usually holds a number
foo = NPC.article; ! a property that holds a string
foo = NPC.add_to_scope; ! a property that holds an object
! Note that if add_to_scope holds an array
! of objects and foo is not an array the
! compiler _will_ complain.
foo = NPC;
foo = edible;
! Note that foo = NPC.edible; is not allowed, AFAIK, since
! attributes don't hold a value as such (they just either
! are or aren't -- which technically is a (boolean) value,
! but Inform doesn't treat it as such, really).
I guess Inform is just about as weakly typed as a language
can be. I like it that way, personally.
L. Ross Raszewski
<jon...@bright.net> wrote:
>! Note that foo = NPC.edible; is not allowed, AFAIK, since
>! attributes don't hold a value as such (they just either
>! are or aren't -- which technically is a (boolean) value,
>! but Inform doesn't treat it as such, really).
Well, it's actually because attributes aren't properties, so the property
syntax isn't allowed. (Apples and oranges, you know)
foo = NPC has edible;
Is the syntactically proper way to do that, which inform likes just fine.
>
>I guess Inform is just about as weakly typed as a language
>can be. I like it that way, personally.
>
Here here.
BrenBarn
>
>Depends where you buy it.
>
>There are places where you could easily pay twice that.
picture of terrorist bombers (or whatever happens to be on the front page of
the London Times). A bagel for a pound? In the UK, I'd call that cheap.
From,
Brendan B. B. (Bren...@aol.com)
(Name in header has spam-blocker, use the address above instead.)
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown
David Glasser
> ! Note that foo = NPC.edible; is not allowed, AFAIK, since
> ! attributes don't hold a value as such (they just either
> ! are or aren't -- which technically is a (boolean) value,
> ! but Inform doesn't treat it as such, really).
Unless Inform is a little smarted than I think (quite possible), it'll
figure out what attribute number edible is (N) and return the value of
property N of NPC, which isn't what you want.
My main problem with Inform's types is not that it has no types but that
its arrays are just about impossible to use.
--
David Glasser: gla...@iname.com | raif FAQ: http://come.to/raiffaq/
"It's good to explore the G.U.E. caves / It's good to explore the G.U.E.
caves / You can count all the leaves / You can KILL TROLL WITH SWORD /
You'll get stuck but you won't be bored"-Joe.Mason, rec.arts.int-fiction
Jonadab the Unsightly One
> > ! Note that foo = NPC.edible; is not allowed, AFAIK, since
> > ! attributes don't hold a value as such (they just either
> > ! are or aren't -- which technically is a (boolean) value,
> > ! but Inform doesn't treat it as such, really).
>
> Unless Inform is a little smarted than I think (quite possible), it'll
> figure out what attribute number edible is (N) and return the value of
> property N of NPC, which isn't what you want.
I'm sure that would happen if you did this:
bar = edible;
foo = NPC.bar;
But I'm guessing you might at least get a warning at
compile time if you directly try to do this:
foo = NPC.edible;
I could be wrong, though, because that's something I've
never tried. I realise a lot of people have trouble
keeping attributes and properties straight, but I never
had that problem even as a complete novice. They're
just fundamentally different things. OTOH, I had a
little previous experience in other languages (mainly
BASIC), so I understood the idea of a flag going in.
> My main problem with Inform's types is not that it has no types but that
> its arrays are just about impossible to use.
It's not quite as bad as all that!
"It must be hard to cook if you anthropomorphize your vegitables."
-- Calvin
Phil Goetz
>
>> *rant on*
>>
>> BTW I (and most of the CS community) think that "strong typing" is a Good
>> Thing(tm).
Sometimes it's good. Sometimes it's bad. It's a tradeoff between
having freedom and catching errors more easily. Don't pretend that the CS
community is unified behind strong typing. A lot of people like Perl
better than Python.
Phil
Dan Schmidt
Actually, Python is pretty much just like Inform in the typing respect;
objects have an unchangeable type but variables (names) do not. So
a = "Hi there";
a = 3;
a = door.open_function; b = a("north");
works out fine; the name a is assigned to three different objects
along the way, each of which is of a different class.
Perl in some ways has more restrictions (arrays and hashes have to be
'declared' explicitly with variable prefixes) and in some ways has
fewer (autoconversion between numbers and strings).
--
Dan Schmidt -> df...@thecia.net, df...@alum.mit.edu
Honest Bob & the http://www2.thecia.net/users/dfan/
Factory-to-Dealer Incentives -> http://www2.thecia.net/users/dfan/hbob/
Gamelan Galak Tika -> http://web.mit.edu/galak-tika/www/
BrenBarn
that I find. . . debatable in various programming languages is the idea that
you have to explicitly define variables at all.
For example, in QBasic, you have "strong typing" because you cannot assign
a number to a string variable (or vice versa). But on the other hand, you
never need to "define" a variable before you use it.
In Inform, you can assign almost any value to any variable, but you must
define each variable before you can use it.
Out of curiosity: Is there any language with both provides "weak typing"
and does not require the explicit declaration of variable names?
Gareth Rees
> Out of curiosity: Is there any language with both provides "weak typing"
> and does not require the explicit declaration of variable names?
Common Lisp allows you to assign to a variable that has not been
declared. It supports both untyped and typed variables.
--
Gareth Rees