C++ text based game
Jamezz
beginners project, nothing too advanced. I'm open to new ideas etc. I've
already started working on a simple parser, and am looking for some help,
and some fresh ideas on how to program things. Anyone interested please
email me.
James
Robotboy8
>already started working on a simple parser, and am looking for some help,
Simple as in, CYOA? If it's more complex, I'd love to see the source and maybe
help with some puzzles. Maybe. I'm feeling noncommital tonight.
--
If I say so then it is so, if it is so it's probably because I said so.
mathew
> Anyone here interested in helping me make a text based game in C++.
Given that C++ is about the second-worst language to do string
manipulation in, you might want to explain *why* you're starting this
project...
mathew
--
<URL:http://www.pobox.com/~meta/>
jjkc
-JP
Adam J. Thornton
INTERCAL is certainly worse.
So is Brainf*ck.
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
Nikita
bottle:
> In article <3B297D2E...@warwick.net>, jjkc <jj...@warwick.net>
> wrote:
>>What's the worst? C?
>
> INTERCAL is certainly worse.
>
> So is Brainf*ck.
Not mentioning Malbolge (Programming from Hell(tm))
--
P.S. please if you get a chanse put some flowrs
on Algernons grave in the bak yard.
Stuart Allen
> Jamezz <jlloy...@home.com> wrote:
> > Anyone here interested in helping me make a text based game in C++.
>
> Given that C++ is about the second-worst language to do string
> manipulation in, you might want to explain *why* you're starting this
> project...
You don't have to look very far to find a good string handling class
for C++. But even without one, I think it is a very interesting
learning excercise to write your own parser. Obviously if your goal is
to write a piece of IF that will appeal to the r.a.i-f community, then
this isn't the way to go. But then again, that isn't everybody's
goal...
Magnus Olsson
Stuart Allen <stu...@jacl.animats.net> wrote:
>me...@pobox.com (mathew) wrote in message
>news:<1ev09j4.z9wju61gjpoewN%me...@pobox.com>...
>> Jamezz <jlloy...@home.com> wrote:
>> > Anyone here interested in helping me make a text based game in C++.
>>
>> Given that C++ is about the second-worst language to do string
>> manipulation in, you might want to explain *why* you're starting this
>> project...
>
>You don't have to look very far to find a good string handling class
>for C++.
You don't have to look beyond the language standard itself: the class
string is a part of the C++ standard since at least a year. And, yes,
it's a "real" string class with variable length, concatenation,
substring extraction, deletion, copy-on-write etc.
It would be nice if people would stop judging C++ by what the language
was like several years ago.
--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------
Jason Etheridge
> What's the worst? C?
What would be the best? I kind of like Icon.
Perl is catching my interest, too.
Richard Bos
> In article <3B297D2E...@warwick.net>, jjkc <jj...@warwick.net> wrote:
> >What's the worst? C?
>
> INTERCAL is certainly worse.
>
> So is Brainf*ck.
Ever tried string handling in (standard!) Pascal? C isn't too hot with
strings, but it can bind Pascal to the bedposts with them.
Richard
Neil Cerutti
Every tried string manipulation in Inform? Yech! Much worse than
in C.
--
Neil Cerutti <cer...@together.net>
*** You won the colony swamp eel eating contest and collected $300
(Yuck). ***
Kathleen M. Fischer
I'll second that.
Is it still around?
Kathleen
-- Masquerade (Comp2000, nominated for Best Story (XYZZY's))
-- ftp://ftp.gmd.de/if-archive/games/zcode/Mask.z5
-- The Cove - Best of Landscape, Interactive Fiction Art Show 2000
-- ftp://ftp.gmd.de/if-archive/games/zcode/Cove.z5
-- Excuse me while I dance a little jig of despair
Andrew Merenbach
pha...@yahoo.com wrote on 6/15/01 1:36 AM:
> On Thu, 14 Jun 2001 23:12:49 -0400, jjkc <jj...@warwick.net> wrote:
>> What's the worst? C?
>
> What would be the best? I kind of like Icon.
> Perl is catching my interest, too.
My all-time fave is Basic.
--
Andrew M.
Andrew Merenbach
greenG...@MailAndNews.com wrote on 6/15/01 9:32 AM:
What platforms used Icon?
--
Andrew Merenbach
Kathleen M. Fischer
>===== Original Message From Andrew Merenbach <amere...@mac.com> =====
>in article 3B35...@MailAndNews.com, Kathleen M. Fischer at
>greenG...@MailAndNews.com wrote on 6/15/01 9:32 AM:
>
>>> ===== Original Message From pha...@yahoo.com =====
>>> On Thu, 14 Jun 2001 23:12:49 -0400, jjkc <jj...@warwick.net> wrote:
>>> What's the worst? C?
>>>
>>> What would be the best? I kind of like Icon.
>>
>> I'll second that.
>>
>> Is it still around?
>
>What platforms used Icon?
For me, it would probably have been VMS, but it's been quite a while ago
(1985?). I suppose it could have been Unix.
Kathleen (suddenly feeling rather old)
Muffy
>
> (Mail&News reported send error. Trying again. Apologies if a repeat)
>
> >===== Original Message From Andrew Merenbach <amere...@mac.com> =====
> >in article 3B35...@MailAndNews.com, Kathleen M. Fischer at
> >greenG...@MailAndNews.com wrote on 6/15/01 9:32 AM:
> >
> >>> ===== Original Message From pha...@yahoo.com =====
> >>> On Thu, 14 Jun 2001 23:12:49 -0400, jjkc <jj...@warwick.net> wrote:
> >>> What's the worst? C?
> >>>
> >>> What would be the best? I kind of like Icon.
> >>
> >> I'll second that.
> >>
> >> Is it still around?
> >
> >What platforms used Icon?
>
> For me, it would probably have been VMS, but it's been quite a while ago
> (1985?). I suppose it could have been Unix.
>
> Kathleen (suddenly feeling rather old)
In 1989 or so, my highschool had an Icon lab...they ran on Unix, had
trackballs, and were provided at a discount to Canadian Schools
(apparently there was some deal with the government: if computer labs
bought Icons, they got a partial rebate).
Maybe I'm confused, though...maybe there was a language called Icon as
well. On the Icons we always ended up programming in Watcom BASIC,
never an actual "Icon" BASIC.
Wow, I really didn't like those computers...
Muffy.
Kathleen M. Fischer
>"Kathleen M. Fischer" wrote:
>> (Mail&News reported send error. Trying again. Apologies if a repeat)
>> >===== Original Message From Andrew Merenbach <amere...@mac.com> =====
>> >in article 3B35...@MailAndNews.com, Kathleen M. Fischer at
>> >greenG...@MailAndNews.com wrote on 6/15/01 9:32 AM:
>> >>> ===== Original Message From pha...@yahoo.com =====
>> >>> On Thu, 14 Jun 2001 23:12:49 -0400, jjkc <jj...@warwick.net> wrote:
>> >>> What's the worst? C?
>> >>>
>> >>> What would be the best? I kind of like Icon.
>> >>
>> >> I'll second that.
>> >>
>> >> Is it still around?
>> >
>> >What platforms used Icon?
>>
>> For me, it would probably have been VMS, but it's been quite a while ago
>> (1985?). I suppose it could have been Unix.
>
>well.
Yes, there was. :) A nifty little one that provided just about any string
manipulation a person could ask for.
I have no idea if it was ever "used" by industry, nor if it is still is use
today.
Kathleen
James Taylor
<URL:mailto:greenG...@MailAndNews.com> wrote:
>
> Muffy wrote:
> > ...maybe there was a language called Icon as well.
>
> Yes, there was. :) A nifty little one that provided just
> about any string manipulation a person could ask for.
>
> I have no idea if it was ever "used" by industry, nor if it
> is still is use today.
Can you give examples of the kind of string operations Icon
will do and how you invoke them please.
I am a Perl man myself, and I find it hard to imagine any language
that has string handling as more of a core strength than Perl does.
I would therefore be very interested in some Icon examples.
Thanks.
--
James Taylor <james (at) oakseed demon co uk>
Based in Hammersmith, London, UK.
PGP key available ID: 3FBE1BF9
Fingerprint: F19D803624ED6FE8 370045159F66FD02
Dan Schmidt
| >===== Original Message From pha...@yahoo.com =====
| >On Thu, 14 Jun 2001 23:12:49 -0400, jjkc <jj...@warwick.net> wrote:
| >> What's the worst? C?
| >
| >What would be the best? I kind of like Icon.
|
| I'll second that.
|
| Is it still around?
Sure: http://www.cs.arizona.edu/icon/
I like it a lot too, though I haven't used it for anything more than toys.
Kathleen M. Fischer
=====
>Can you give examples of the kind of string operations Icon
>will do and how you invoke them please.
=8-O
Ummm... probably not. It's been way too many years ago, and I've learned way
to many languages in the interim. :(
>I am a Perl man myself, and I find it hard to imagine any language
>that has string handling as more of a core strength than Perl does.
>I would therefore be very interested in some Icon examples.
One of these days I'm going to look into Perl. No time, no time.
I seem to recall (noting 15 years have passed, and I only worked with it in
a
college class) that was a procedural language that had an extremely powerful
but cryptic syntax, which let you do *ANYTHING* to a string that a person
could possibly imagine in a compressed amount of code. Of course, 15 years
ago, the reigning languages were probably FORTRAN, C, and Pascal, and what
could be imagined might well have been far less than what can be imagined
now.
:)
jjkc
(essentially "Visual Pascal"). C is much, much worse.
-Jim
Alan Trewartha
<URL:mailto:greenG...@MailAndNews.com> wrote:
> One of these days I'm going to look into Perl. No time, no time.
No! Go for it! First thing I did when I installed MacOS X. It's the dog's!
Loads of stuff on the web to help you whichever way you prefer to learn
(unless it's with a "meat" person standing over you saying "do this" of
course).
Mind you I do find string manipulation/parsing disproportionately useful at
work.
On a slightly different topic, now that MacOS X (via learning perl) has
dangled me deep into other hardcore geek languages (php, python) I feel more
at home in Inform than ever before, which is ironic considering how little
string manipulation there is in Inform. Of course, it's not too difficult to
see why Inform should be so similar in syntax and approach to these other
languages (historically speaking).
A
mathew
> You don't have to look beyond the language standard itself: the class
> string is a part of the C++ standard since at least a year. And, yes,
> it's a "real" string class with variable length, concatenation,
> substring extraction, deletion, copy-on-write etc.
In other words, it gives C++ the kind of string-handling enjoyed by
BASIC. Which isn't exactly something to crow about.
Heavy Cat Multimedia Ltd.
Assembler, or Visual Basic.
--
"All programs have at least one bug."
"All programs can be reduced by one instruction."
"Therefore, all programs can be reduced to one instruction..
..that doesn't work."
Scott
Heavy Cat Multimedia Ltd.
http://www.heavycat.com/
http://www.ladystar.net/
Heavy Cat Multimedia Ltd.
>On Thu, 14 Jun 2001 23:12:49 -0400, jjkc <jj...@warwick.net> wrote:
>> What's the worst? C?
>
>What would be the best? I kind of like Icon.
>Perl is catching my interest, too.
Perl. No doubt. Undisputed champion of string processing.
--
Would the last real software engineer to leave the
corporate IT job market please power down the
server?
Joe Mason
Muffy <muffysb...@hotmail.com> wrote:
> In 1989 or so, my highschool had an Icon lab...they ran on Unix, had
>trackballs, and were provided at a discount to Canadian Schools
>(apparently there was some deal with the government: if computer labs
>bought Icons, they got a partial rebate).
Unisys Icons, yes. I had them in public school. We all hated them at the time - thought they were dumb. In hindsight,
that's not true at all, they just weren't "cool" because they were fully endorsed by (ick) teachers. To this day I prefer
the trackball to the mouse.
They had some good educational games, too. Some really dumb educational games, but also a few good ones. I liked the one
where you're a ship captain on an exploratory voyage - reminds me a lot of Pirates! but less violent. Also A Week in the
Life, of course (CYOA IF on the theme of teen problems).
On the other hand, the word processor was really annoying. So was the program launcher menu.
Got my first exposure to Unix on the Icons, in grade 7 or 8 when one of the teachers showed me how to get out of the GUI
menu and gave me an account for a project. Also my first experience in cross-platform coding: I worked on an IF game in
Prolog on my PC at home and the computers at school. (Except I was using Turbo Pascal, which was DOS-only, I believe.
Maybe my memory is wonky. Maybe there was - yeah, that's it. There was a DOS emulator, or a dual-boot of some sort.)
Joe
Magnus Olsson
No, but I was merely disputing the claim that C++ was the second-worst
language for string processing, not by any means saying that it was
the best.
Andrew Merenbach
wrote on 6/16/01 6:11 AM:
Hey, I liked Basic! It wasn't THAT bad, really!
You could search for occurrences of characters in strings, convert strings
to numbers, convert numbers to strings, and do all sorts of nifty things.
But that's just my opinion. :-)
--
Andrew Merenbach
Tom Waddington
>> I am a Perl man myself, and I find it hard to imagine any language
>> that has string handling as more of a core strength than Perl does.
>> I would therefore be very interested in some Icon examples.
> One of these days I'm going to look into Perl. No time, no time.
No better time than now; a mailing list for beginners was recently
announced on http://www.perl.com
Funnily enough, one of Icon's string manipulation features was being
considered for Perl 6. I can't remember which one, or what became of
the proposal, but it's interesting to see that the current king of
string manipulation still has something to learn from the older
languages.
Of course, Perl has many other advantages above string handling. You
can write pretty much anything with it, it will talk to anything you
can't write in it and it's syntax is incredibly flexible. Or as the
eminent Mr Plotkin once put it: "Perl is a complete slut of a
language."
Be seeing you,
--
Tom Waddington
Tom Waddington
>> What's the worst? C?
> Assembler, or Visual Basic.
I'm no fan of VB, quite the contrary in fact, but I have to say that
it's string handling isn't too bad these days. Reference vbscript.dll
and you even have a fairly complete regular expression engine
available. Admittedly, the implementation is a bit, um, cretinous, but
at least it's there.
Heavy Cat Multimedia Ltd.
Perhaps its improved somewhat. As I remember it (VB5 and before) there were
numerous occasions for four and five-level nested if blocks with nested
instr() and mid() statements that became utterly non-understandable after
about an hour of not working on them. Nice to hear VB has regexps now.
Fortunately, we discovered Perl... :)
--
"I'm sorry Captain, but I have an emergency call on
line five from a Mr. Ham."
"Alright, give me Ham on five, hold the Mayo."
Andrew Plotkin
> Every tried string manipulation in Inform?
No. And bystanders may wish to draw some conclusions from the fact
that this doesn't bother me. :)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Jason Etheridge
> Can you give examples of the kind of string operations Icon
> will do and how you invoke them please.
I'm not sure if Icon does regexps and interpolation. I'll try
to find out. But in the meantime...
One difference is in how you refer to positions within a string:
"Hello"
-5 -4 -3 -2 -1 0
H e l l o
1 2 3 4 5 6
The numbers correspond to the gaps between the characters, and not
the characters themselves.
If Line contains "Hello", then Line[2:4] would refer to "el"
Another form would be Line[2+:3], which would get 3 characters
starting from 2, or "ell"
Any letters in single quotes are part of a character set, which is
an actual datatype in Icon.
You could do something like: delimeter := '.,/';
The functions that use csets include any() and many()
which look for csets in a given string. match() and
find() will look for substrings in strings.
any(cset, string) looks to see if the first character in string is
one of those in cset. It returns the position after the matched
character, or otherwise it fails.
many(cset, string) is similar. If at least one character matches,
it returns the position between the last character that matches and
the first that doesn't. Otherwise it fails.
match("abc", "123abc") would fail.
match("abc", "abc123") would return 4.
find("abc", "123abc") would return 4
There is an important distinction between returned values and failed
functions. Icon has something called generators. A function or
expression can return multiple value, and there are easy ways to work
with these.
every write ( find("xy", "xyzzy xyzzy xyzzy") );
Will output the numbers 1, 7, and 13.
You also have implicit scanning (Perl does similar things with $_,
I think):
"xyzzy xyzzy xyzzy" ? ( every write ( find("xy") ) );
does the same thing as the previous example.
The whole generator idea is nice.
1 to 5 is a generator expression that produces five results.
Your basic for loop:
every n := 1 to 5 do sum := sum + n;
You could also do:
every sum +:= 1 to 5;
The do is optional. Every just goes through every value the
first expression provides.
When defining a function, instead of _return_ing a value,
you can _suspend_, returing one of many possible values
(setting up a generator) or you can _fail_.
Perl can return things in a list context, but Icon returns
multiple values in sequence, one at a time. I'm not sure
which is more useful. Icon also has a list datatype, which
you can use a stack, array, etc.
Oh, I remember now. There's a library that provides
regular expressions.
Magnus Olsson
Andrew Plotkin <erky...@eblong.com> wrote:
>Neil Cerutti <cer...@together.net> wrote:
>
>> Every tried string manipulation in Inform?
>
>No. And bystanders may wish to draw some conclusions from the fact
>that this doesn't bother me. :)
In fact, you don't need very much string manipulation in a typical
IF game. String *handling*, yes, but the string manipulation is
usually quite simple, like adding a plural ending.
Even a parser doesn't need to do much string manipulation, beyond
breaking up a command line into tokens and then looking up these
tokens in the vocabulary table (and, strictly speaking, that's the job
of the lexical analyzer, not the parser). Consider the fact that
C is generally considered a good language for writing compilers.
Magnus Olsson
>don't know about Standard Pascal, but I've done an awful lot in Delphi
>(essentially "Visual Pascal"). C is much, much worse.
>
I assume Delphi's string handling is descended from that of Turbo Pascal,
which is quite decent and much better than standard Pascal.
Standard Pascal's string supprt sucks rotten eggs. You can't get much
worse and still be a high-level language (the only worse example
I can think of is FORTRAN 66). C shines in comparison.
Russ Bryan
> No, but I was merely disputing the claim that C++ was the second-worst
> language for string processing, not by any means saying that it was
> the best.
I didn't catch which language received the honor of worst language for
string processing, but if C++ is second then COBOL has to be first.
At least in C++ you can build your own robust string-processing classes.
There is absolutely no resource in COBOL whatsoever which can make string
processing anything but painful.
Andrew Merenbach
a@b.c wrote on 6/16/01 4:21 PM:
A previous post mentioned Assembly as the worst. Wouldn't it be, since it's
pretty much the most basic language there is, on top of which most others
are written?
--
Andrew Merenbach
Kevin Forchione
news:Xns90C2C60D73AFDne...@24.128.8.70...
I certainly wouldn't use COBOL for creating IF, but Object COBOL has made
some strides toward the "class" mechanism. Having worked with COBOL for more
than 12 years I've found it completely capable of handling the applications
it was designed for. And Kasten's Guerrilla COBOL
(http://home.swbell.net/mck9/cobol/cobol.html) provides a teaser with the
following:
"Do you suffer from C-envy? Would you like to try some of the tricks that
are so common in C and other languages? You can. With a reasonably modern
dialect of COBOL, and a little ingenuity, you can do almost anything that a
C programmer can do:
Dynamic Memory Allocation
Pointer Variables
Global Variables
Environmental Variables
Data Structures
Text Parsing Techniques
Finite State Machines"
Not so bizarre, given that more than 80% of the world's code is expressed in
COBOL.
--Kevin
Louis Rose
> >it's string handling isn't too bad these days. Reference vbscript.dll
> >and you even have a fairly complete regular expression engine
> >available. Admittedly, the implementation is a bit, um, cretinous, but
> >at least it's there.
>
> Perhaps its improved somewhat. As I remember it (VB5 and before) there
were
> numerous occasions for four and five-level nested if blocks with nested
> instr() and mid() statements that became utterly non-understandable after
> about an hour of not working on them. Nice to hear VB has regexps now.
> Fortunately, we discovered Perl... :)
Sorry guys, but VB can do anything that Windows can. And anything that Perl
can. And anything that almost anything can. How? Using API calls.
Admittedly, the implimentation side of this is hell but it works. The exe
and required dlls will be huge compared to the likes of Perl, but it can be
done.
If anybody does want any help with string manipulation or most things in VB,
email me.
Louis Rose
louis...@virgin.net
Heavy Cat Multimedia Ltd.
>> >I'm no fan of VB, quite the contrary in fact, but I have to say that
>> >it's string handling isn't too bad these days. Reference vbscript.dll
>> >and you even have a fairly complete regular expression engine
>> >available. Admittedly, the implementation is a bit, um, cretinous, but
>> >at least it's there.
>>
>> Perhaps its improved somewhat. As I remember it (VB5 and before) there
>were
>> numerous occasions for four and five-level nested if blocks with nested
>> instr() and mid() statements that became utterly non-understandable after
>> about an hour of not working on them. Nice to hear VB has regexps now.
>
>> Fortunately, we discovered Perl... :)
>
>Sorry guys, but VB can do anything that Windows can. And anything that Perl
>can.
*cough* *cough* excuse me?
Perl can run on IRIX. Can VB? Perl can run interactively. Perl can do
regexps.
>And anything that almost anything can. How? Using API calls.
I'm not aware of any Windows API calls that emulate Perl.
>
>Admittedly, the implimentation side of this is hell but it works. The exe
>and required dlls will be huge compared to the likes of Perl, but it can be
>done.
But what's the point when I can write a 10-line Perl script (in 1K)
and run that on Windows too? Believe me, I'm a fan of VB as much as the
next Windows programmer. We even wrote one of our commercial
shareware programs in VB. But Perl it isn't, API calls or not. Perl is the
right language for a lot of things that VB isn't, and vice versa.
Andrew Merenbach
Multimedia Ltd. at in...@NOSPAM.heavycat.com wrote on 6/16/01 9:34 PM:
And VB doesn't work on Macs, whereas Perl does.
--
Andrew Merenbach
David Glasser
> >And anything that almost anything can. How? Using API calls.
>
> I'm not aware of any Windows API calls that emulate Perl.
I think there's a Perl DLL or something of that sort.
--
David Glasser
ne...@davidglasser.net http://www.davidglasser.net/
R. Alan Monroe
>Not so bizarre, given that more than 80% of the world's code is expressed in
>COBOL.
Source? Just idly curious. That number feels high to me.
Have fun
Alan
Kevin Forchione
news:tiqhol9...@corp.supernews.com...
A bit imprecise, perhaps. This quote is from the San Francisco Daily
Chronicle, dated March 14, 2001, in an article called "Demand for COBOL
Skills Bouncing Back":
"'Most of the world's business data, approximately 75 to 85 percent, is
written in COBOL,' adds Bill Payson, president and CEO of Senior Techs, an
Internet based job bank for experienced IT professionals in Campbell. 'That
translates to some hundreds of billions of lines of code.'"
And also:
"'If all the COBOL programs stopped working the U.S. economy would
collapse,' says Paul Halpern, director of traditional development solutions
at Merant, a Web-enabling training company in Mountain View. ''Nine out of
10 of the top Internet brokers use COBOL with CICS (Customer Information
Control Systems). Chances are that when you use an ATM card you are starting
a COBOL/CICS process. An IBM report published last year indicates 30 billion
COBOL/CICS transactions are executed worldwide each day, more than the total
number of Web pages hit each day.'"
Interesting numbers, but there are other sources as well that support these
figures.
--Kevin
Magnus Olsson
Louis Rose <louis...@virgin.net> wrote:
>> >I'm no fan of VB, quite the contrary in fact, but I have to say that
>> >it's string handling isn't too bad these days. Reference vbscript.dll
>> >and you even have a fairly complete regular expression engine
>> >available. Admittedly, the implementation is a bit, um, cretinous, but
>> >at least it's there.
>>
>> Perhaps its improved somewhat. As I remember it (VB5 and before) there
>were
>> numerous occasions for four and five-level nested if blocks with nested
>> instr() and mid() statements that became utterly non-understandable after
>> about an hour of not working on them. Nice to hear VB has regexps now.
>
>> Fortunately, we discovered Perl... :)
>
>Sorry guys, but VB can do anything that Windows can. And anything that Perl
>can. And anything that almost anything can. How? Using API calls.
There are Windows API calls that do regexps?
(BTW, you can of course do regexps in any language that support
charater operations - it's just a matter of how much work it is
and how much code you have to write).
Richard Bos
> Richard Bos wrote:
>
> > Ever tried string handling in (standard!) Pascal? C isn't too hot with
> > strings, but it can bind Pascal to the bedposts with them.
>
> don't know about Standard Pascal, but I've done an awful lot in Delphi
> (essentially "Visual Pascal"). C is much, much worse.
Myeah, but that's not a fair comparison. That's like saying that
Pascal's string handling is worse than (C + any number of libraries you
like to add)'s. Or that ISO Basic's string handling is worse than
(Random Modern Proprietary Basic)'s. That's a bit of a foregone
conclusion.
Richard
Mark Musante - Sun Microsystems
> Neil Cerutti <cer...@together.net> wrote:
> >
> > Every tried string manipulation in Inform?
>
> No. And bystanders may wish to draw some conclusions from the fact
> that this doesn't bother me. :)
Surely there was SOME string manipulation in Lists and Lists.
-markm
Dan Schmidt
| On 15 Jun 2001 08:36:36 GMT, Jason Etheridge <pha...@yahoo.com> wrote:
| >On Thu, 14 Jun 2001 23:12:49 -0400, jjkc <jj...@warwick.net> wrote:
| >> What's the worst? C?
| >
| >What would be the best? I kind of like Icon.
| >Perl is catching my interest, too.
|
| Perl. No doubt. Undisputed champion of string processing.
Perl is not so great when you want to look at a string character by
character, consuming as you go. You have to substr all over the
place, or split it into an array but then you lose the ability to
look at it as a string. I do agree that in general it is very good.
Matthew Russotto
Kevin Forchione <Ke...@lysseus.com> wrote:
>
>COBOL.
That is only because COBOL is so verbose that what takes one line in C
takes 15 in COBOL.
--MTR, who once re-wrote a COBOL program which did all sorts of bit
manuipulation into C. Code was far shorter, result was two orders
of magnitude faster -- many hours into few minutes.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Andrew Plotkin
Not really, that I can remember.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Votes count. Count votes.
Richard Bos
> I am a Perl man myself, and I find it hard to imagine any language
> that has string handling as more of a core strength than Perl does.
Reputedly, Snobol made something of a speciality of string handling, and
could do just about anything. Never used it myself, though, so take this
with a grain of salt.
Richard
David Thornley
Louis Rose <louis...@virgin.net> wrote:
>can. And anything that almost anything can. How? Using API calls.
>
vacuous statement.
>Admittedly, the implimentation side of this is hell but it works.
This is a meaningful statement.
The question in most cases is not whether any given language can
support any given task, but whether it is more fun to do so or to
share a cubicle with 469 healthy chipmunks. If it's hell to
implement, it's probably also hell to debug and maintain and
enhance, so I'd recommend using a language that's at worst heck.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
David Thornley
ability to apply a recursive descent parser in one line. In anything
not closely associated with string handling, I'd much rather use
FORTRAN 66 on punch cards.
Damien Neil
Dan Schmidt <df...@harmonixmusic.com> wrote:
>Perl is not so great when you want to look at a string character by
>character, consuming as you go. You have to substr all over the
>place, or split it into an array but then you lose the ability to
>look at it as a string. I do agree that in general it is very good.
while ($s =~ /(.)/gc) {
# Do something with next character, stored in $1.
}
Slightly less efficient than substr()s, but significantly more
efficient once you use multiple regexs to match sequences longer
than a single character.
- Damien
Sean T Barrett
>Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
>>Reputedly, Snobol made something of a speciality of string handling, and
>>could do just about anything. Never used it myself, though, so take this
>>with a grain of salt.
>>
>I used it. The string handling was potentially amazing. It had the
>ability to apply a recursive descent parser in one line. In anything
>not closely associated with string handling, I'd much rather use
>FORTRAN 66 on punch cards.
Now we've gone full circle. Well, full circle back to where we were
a little bit back in the thread; from the Icon FAQ:
Icon is the latest in a series of high-level programming languages
designed to facilitate programming tasks involving strings and
structures. The original language, SNOBOL, was developed at Bell
Telephone Laboratories in the early 1960s. SNOBOL evolved into
SNOBOL4, which is still in use. [...] Although it has similar
objectives and many similar capabilities, Icon bears little
superficial resemblance to SNOBOL4.
However, this whole subject came up because mathew suggested that
C++, being lousy at strings, was a lousy choice for programming an
adventure.
This isn't the issue at all (as we've already noted that Inform is
not exactly world-class in this department either). Obviously there
are issues about creating your own parser and world model, but in
terms of *language choice* for doing adventure programming, the
important factor is that traditional languages are designed around
manipulation of quantities of entities that are all "the same".
Even in a heavily inherited, very-heterogenous language like
Smalltalk, you're still dealing with tens of GUI elements or
hundreds of simulation elements that all play by the same basic
rules. They may have parameterized exceptions--a la attributes
in Inform--but they have nothing resembling the "every object
behaves entirely differently" that most IF has.
Moreover, the vast majority of quality IF uses the same language
to code the library as to code the game, so the language needs
to be powerful enough to handle the needs of many "regular" objects
in sophisticated ways (for the library) and of some significant
number of "exceptional" objects (for the game). There are, as far
as I know, no traditional languages that make this possible;
certainly C++ does not deliver on this front. Simply defining
an initialized unique object is clumsier than one would like.
SeanB
Greg Ewing
>
> Maybe I'm confused, though...maybe there was a language called Icon as
> well.
Yes, there is a programming language called Icon.
It's descended from SNOBOL (created by the same
person). SNOBOL was a very funky language designed
specially for doing pattern matching and other stuff
on strings. Icon takes many of the ideas about
pattern matching from SNOBOL, applies them to
other things besides strings, and generally manages
to be even funkier.
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
Greg Ewing
>
> The whole generator idea is nice.
>
> 1 to 5 is a generator expression that produces five results.
The really amazing thing about this is the way that
generators are built into the very fabric of the language.
Even something as innocuous-looking as
x + 3
can be a generator expression if x itself is a generator
expression, e.g.
(1 to 5) + 3
produces the sequence of values 4, 5, 6, 7, 8. Everything
wants to backtrack and find different ways of evaluating
the expression.
The upshot of this for IF is that Icon would be a great
language for writing an IF parser. If you write a recursive
descent parser in Icon, it automatically tries to find
*every* possible way of parsing the input, which is
very handy when trying to understand ambiguous things
like natural language!
Greg Ewing
>
> An IBM report published last year indicates 30 billion
> COBOL/CICS transactions are executed worldwide each day
The number of transactions doesn't necessarily have anything
to do with the amount of code. 29,999,999,999 of them might
be using the same 10-line Cobol program.
(The one that displays "This machine is temporarily
out of service" perhaps. :-)
Kevin Forchione
news:3B2E9EC5...@my.signature...
> Kevin Forchione wrote:
> >
> > An IBM report published last year indicates 30 billion
> > COBOL/CICS transactions are executed worldwide each day
>
> The number of transactions doesn't necessarily have anything
> to do with the amount of code. 29,999,999,999 of them might
> be using the same 10-line Cobol program.
>
> (The one that displays "This machine is temporarily
> out of service" perhaps. :-)
Quite right. Just another interesting statistic for the layman.
--Kevin
David Glasser
> Perl is not so great when you want to look at a string character by
> character, consuming as you go. You have to substr all over the
> place, or split it into an array but then you lose the ability to
> look at it as a string. I do agree that in general it is very good.
A string manipulation feature I'd really like that Perl lacks is the
ability to 'tag' substrings of a string. For example, I'd like to be
able to say that certain parts of a string should be 'bold', but without
embedding more characters into the string (and thus messing up length
operations, wrapping, etc). Do any languages really support this?
Richard Bos
> A string manipulation feature I'd really like that Perl lacks is the
> ability to 'tag' substrings of a string. For example, I'd like to be
> able to say that certain parts of a string should be 'bold', but without
> embedding more characters into the string (and thus messing up length
> operations, wrapping, etc). Do any languages really support this?
I doubt it, because I don't think it can be done. You see, such tags are
information, and that information needs to be stored somewhere. Store it
in the string, and you mess up its length; store it somewhere else, and
you need to manipulate more than just the string, and normal string
handling functions stop working.
curses (not the game, the terminal package) handles this by using an
extended character for coloured text that takes more room than just the
normal one. This has the disadvantage that you can't handle such curses
strings using non-curses functions. It solves this problem by allowing
you to print ordinary strings in colour, but only in the current colour,
and then allowing you to change the current colour; unfortunately, this
cannot be done inside a string (since, once again, that would take more
information than is available in a standard string).
Richard
Sean T Barrett
>ne...@davidglasser.net (David Glasser) wrote:
>> For example, I'd like to be
>> able to say that certain parts of a string should be 'bold', but without
>> embedding more characters into the string (and thus messing up length
>> operations, wrapping, etc). Do any languages really support this?
>
>I doubt it, because I don't think it can be done. You see, such tags are
>information, and that information needs to be stored somewhere. Store it
>in the string, and you mess up its length
I'm not offhand familiar with any languages that allow it, but there
is no reason it can't be done. It can be done since the language
(or library) defines how the length of a string is computed; I can
store a string with 80 bits per character if I want, and compute the
length as appropriate. (C and C++ weak-typing seem to prejudice
people to thinking of memory layouts, instead of abstract data
types.)
Typesetting languages (e.g. PostScript and TeX) are biased, like
Inform, towards outputting, and, I believe, tend to think of bold
and etc. as qualities of the output--of rendered glyphs, not of
text strings. (This is definitely the case with PS; TeX I'm not
that familiar with.)
It's possible that if you create a rich edit control in Win32,
the control might have a character-access mechanism that you
could use to get this effect, but I doubt it would be anything
other than clumsy.
SeanB
Dan Schmidt
| A string manipulation feature I'd really like that Perl lacks is the
| ability to 'tag' substrings of a string. For example, I'd like to be
| able to say that certain parts of a string should be 'bold', but without
| embedding more characters into the string (and thus messing up length
| operations, wrapping, etc). Do any languages really support this?
Emacs Lisp does.
Poptasticboy UK
>From: Greg Ewing s...@my.signature
>Date: 19/06/01 00:40 GMT Daylight Time
>Message-id: <3B2E9182...@my.signature>
>
>Jason Etheridge wrote:
>>
>> The whole generator idea is nice.
>>
>> 1 to 5 is a generator expression that produces five results.
>
>The really amazing thing about this is the way that
>generators are built into the very fabric of the language.
>Even something as innocuous-looking as
>
> x + 3
>
>can be a generator expression if x itself is a generator
>expression, e.g.
>
> (1 to 5) + 3
>
>produces the sequence of values 4, 5, 6, 7, 8. Everything
>wants to backtrack and find different ways of evaluating
>the expression.
>
>The upshot of this for IF is that Icon would be a great
>language for writing an IF parser. If you write a recursive
>descent parser in Icon, it automatically tries to find
>*every* possible way of parsing the input, which is
>very handy when trying to understand ambiguous things
>like natural language!
While I have limited experience, Prolog seems very good for natural language.
Any thoughts on how useful Prolog would be for writing IF?
Louis Rose
"Magnus Olsson" <m...@df.lth.se> wrote in message
news:9gkh7p$bu$1...@news.lth.se...
Yeah this is the only problem, the sheer amount of code in VB to program so
realtively simple things in other languages, but it can still be done!!!
Richard Bos
> While I have limited experience, Prolog seems very good for natural language.
> Any thoughts on how useful Prolog would be for writing IF?
I tried it. My procedural habits probably didn't help, but I didn't
consider it very much easier than in another language. My impression was
that if you could somehow write the engine code in a procedural
language, and the game code in Prolog, that would improve matters
greatly, but one would still need to be more proficient in Prolog than I
am likely ever to be to make it a success.
Richard
Richard Bos
> Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
> >I doubt it, because I don't think it can be done. You see, such tags are
> >information, and that information needs to be stored somewhere. Store it
> >in the string, and you mess up its length
>
> I'm not offhand familiar with any languages that allow it, but there
> is no reason it can't be done. It can be done since the language
> (or library) defines how the length of a string is computed; I can
> store a string with 80 bits per character if I want, and compute the
> length as appropriate.
You could, in principle (and curses does exactly that), but your
language (or library) will then be much less efficient in printing these
strings than if you use the hardware character. For most languages,
"string" == "collection of hardware characters".
> (C and C++ weak-typing seem to prejudice
> people to thinking of memory layouts, instead of abstract data
> types.)
Hm, no, efficiency concerns, and legibility by other languages, do. If
you write a "normal" string to a text file, every other language should
be able to read it. If you write an enhanced string, most other
languages will be confused by it.
Richard
Sean T Barrett
>buz...@world.std.com (Sean T Barrett) wrote:
>> Richard Bos <in...@hoekstra-uitgeverij.nl> wrote:
>> >I doubt it, because I don't think it can be done.
>For most languages, "string" == "collection of hardware characters".
Followed by a 0. Or with a prefix length that's a byte.
Or with a prefix length that's 32-bits. Or the string is
unicode of any of various flavors.
Almost no hardware implements strings. Assuming "character" = "byte"
is an assumption, not a truth.
Finally, the original poster asked for, essentially, a language
where "string" != "collection of hardware characters". So that
comment amounts to question begging.
>> (C and C++ weak-typing seem to prejudice
>> people to thinking of memory layouts, instead of abstract data
>> types.)
>
>Hm, no, efficiency concerns, and legibility by other languages, do. If
>you write a "normal" string to a text file, every other language should
>be able to read it. If you write an enhanced string, most other
>languages will be confused by it.
You are posting to a newsgroup where people regularly use languages
that compress their string storage on disk, that do not allow file
interchange between applications at all, and which are grossly
inefficient because they are interpreted. The vast majority of
non-mainstream languages are also interpreted. Efficiency is just
not a concern when the language is interpreted but the string
primitives are themselves coded in a compiled language.
The language C's string implementation is insanely inefficient
(let's use an O(n) computation to find out the length of a string!),
but people still use it. Also, formatting strings in memory in
different ways doesn't affect file interchange if those strings
get flattened to remove formatting when saved to plain text
files. So that's irrelevant anyway.
So you're wrong: it can be done, and indeed it apparently
has been done (ELISP), where "it" is what the original poster
asked for: a language that makes it easy to do such things.
I can live with people making goofy pedantic points about my posts,
but this goes beyond pedantry.
SeanB
John Colagioia
> In article <3B297D2E...@warwick.net>, jjkc <jj...@warwick.net> wrote:
> >What's the worst? C?
> INTERCAL is certainly worse.
This is true, although "classical" INTERCAL doesn't have strings at all, so
that's kind of cheating...
> So is Brainf*ck.
Actually, BrainF*** is pretty easy, once you get the hang of it. Granted,
there's a steep learning curve, and you don't have any primitives, but the
whole of dataspace is pretty much a string...
John Colagioia
[...]
> A previous post mentioned Assembly as the worst. Wouldn't it be, since it's
> pretty much the most basic language there is, on top of which most others
> are written?
Not a chance, actually. Assembly on some machines makes it pretty easy. For
example, on the Intel chip, you actually have instructions to scan for a
character, copy blocks of characters from place to place, and so on. If you add
BIOS functionality, you even get string printing for "free."
Motorola is a little bit harder at some points, but still not bad.
Little building blocks does not mean "hard." Tedious, maybe. However, if the
high-level language you use only has string operations "concatenate string to
itself," "truncate to three characters," and "reverse string," then you're going
to have a horrible time getting anything useful accomplished...and THAT is hard.
John Colagioia
> Muffy wrote:
> > Maybe I'm confused, though...maybe there was a language called Icon as
> > well.
> Yes, there is a programming language called Icon.
> It's descended from SNOBOL (created by the same
> person). SNOBOL was a very funky language designed
> specially for doing pattern matching and other stuff
> on strings. Icon takes many of the ideas about
> pattern matching from SNOBOL, applies them to
> other things besides strings, and generally manages
> to be even funkier.
And there's SPITBOL (which, as a sidenote, is what the original INTERCAL
compiler was written in), which is also a SNOBOL descendant, with even more
"funk" to it.
John Colagioia
[...]
> Can you give examples of the kind of string operations Icon
> will do and how you invoke them please.
> I am a Perl man myself, and I find it hard to imagine any language
> that has string handling as more of a core strength than Perl does.
> I would therefore be very interested in some Icon examples.
Ah, the joys of keeping a foot in academia...From "The ICON Programming
Language," by Ralph and Madge Griswold, page 173:
while exp ?:= {
2(="(", tab(bal(')')), pos(-1))
}
where "exp" is a string containing an arithmetic expression, if it
starts with an open-parenthesis, it removes the opening and closing
parentheses. The bal() function is the one doing the work, looking for
the locations of "balance characters." It finds the location pairs of
all potential matches of the second and third parameters (unlisted
above, which default to parentheses) before the occurrance of the first
parameter. The pos() function makes sure that bal() was successful.
Converting arithmetic expressions to "prefix" (operator first, followed
by operands--like LISP), meanwhile, is done like:
procedure lassoc (exp, op)
local j
return exp ? {
every j := bal(op)
form (tab(\j), move(1), tab(0))
}
end
Nope. Even after reading the description, I can't figure out what the
heck they're talking about.
Hm. I guess I'll have to read the book. ICON looks like fun...
[...]
John Colagioia
[...]
> You could, in principle (and curses does exactly that), but your
> language (or library) will then be much less efficient in printing these
> strings than if you use the hardware character. For most languages,
> "string" == "collection of hardware characters".
Actually, just to be annoyingly pedantic for a moment, "for most language
implementations, a string is a collection of hardware characters." Aside from
C, there are very few languages that tell you about the internals of a string,
and with good reason--it doesn't make any difference to the programmer.
> > (C and C++ weak-typing seem to prejudice
> > people to thinking of memory layouts, instead of abstract data
> > types.)
> Hm, no, efficiency concerns, and legibility by other languages, do. If
> you write a "normal" string to a text file, every other language should
> be able to read it. If you write an enhanced string, most other
> languages will be confused by it.
Efficiency is a nonissue, because--despite what most compiler writers will have
you believe--it really isn't that hard to detect "local idioms" and optimize
them to something significantly more efficient.
As for interprocess concerns, the interacting processes should have a protocol
under which they communicate. Any process that can't be bothered to convert
the data appropriately (i.e., a flat text string, in this case) probably
shouldn't be trusted to deliver data, anyway. Big example: Computers
communicate just fine, despite the fact that Intel machines internally order
their integers "backwards" from most everyone else. This is because each
application is responsible for transmitting data in "network format."
Jonadab the Unsightly One
> A previous post mentioned Assembly as the worst. Wouldn't it be, since it's
> pretty much the most basic language there is, on top of which most others
> are written?
No. String handling in assembly language (well, 8086 anyway) is
_way_ easier than in CoBOL. For example, a first-semester assembly
student can write a program that constructs a string the length
of which is determined at runtime. In CoBOL, you need a tenured
graduate student to show you how to do that, if it's even possible.
Also, if you're going to accept a string from the keyboard and
print it to the screen, CoBOL requires you to declare no fewer
than three separate memory locations for your string (one for
reading it in, one for storing it, and one for printing). In
assembly, you can get away with one. Also, in assembly, it's
way easier to use the same subroutine to read in multiple
different strings into multiple different memory locations,
or write out multiple strings from multiple memory locations.
Calling C++ the second-worst language for string manipulation
is an exaggeration, but it certainly pales in comparison to
most modern languages.
Oddly, Inform is even _worse_ about string manipulation than
C or C++, but it's _great_ for writing IF. But that's because
you don't _need_ string manipulation when you can just use
routines in lieu of all your strings.
--
Your font seems to be: proportional fixed
^
|
(Fontmeter only accurate for about 90% of fonts.)
Jonadab the Unsightly One
> Hey, I liked Basic!
There will always be a soft spot in my heart for BASIC.
For certain kinds of things, it's way better than, say,
C. (For other kinds of things it's worthless, but
nevermind.)
> You could search for occurrences of characters in strings, convert strings
> to numbers, convert numbers to strings, and do all sorts of nifty things.
I used to use BASIC for all my text-munging needs, until I
discovered elisp and Perl.
Now, I'm not sure a language's string-manipulation facilities
are worth talking about if they don't include regular
expression functionality. Regexps are very addictive.
Jonadab the Unsightly One
> Perl. No doubt. Undisputed champion of string processing.
Perl is very good. elisp is marginally better. The regexes
aren't quite as versatile, but buffers as a fundamental data
type just put it over the top. Also, text properties (as Dan
Schmidt alluded) allow for some nifty things. And markers.
Any text manipulation that can't be done in elisp must be
AI-complete or plain impossible. And if it's AI-complete,
elisp is really good at allowing user-interaction when
necessary. (Odd, that.)
Also, some of the things Perl would do with regexes,
elisp does other ways. For example, Perl has lookahead
assertions in the regexes, but in elisp you just call
looking-at and and the result with your regex matching.
With save-excursion, you can get deep nesting effects
that actually exceed the versatility of Perl's regexes.
Marginally.
Although Perl does string manipulation in fewer bytes
of code; elisp has some relatively long function names...
which is probably either good or bad, depending on
how you look at it.
Jonadab the Unsightly One
> > One of these days I'm going to look into Perl. No time, no time.
>
> No! Go for it!
There are plenty of testimonials to be had on the Perl
newsgroups, but here's one short one for free: I took
out the Camel Book on interlibrary loan (two weeks), and
before I had to return it I had written stuff that I'd
previously attempted in other languages and failed to
accomplish after weeks. (I then went and bought my
own copy of the book. It resides under my mouse pad.)