What object definition Syntax would you choose?
Uli Kusterer
Imagine you were creating an IF interpreter like Inform, TADS, Hugo or
whatever. How would you define objects in the source code if your
objectives were:
1) Readability: English is the ideal.
2) Rememberability: the user should not have to remember in what order
to specify short and long descriptions
3) Inheritance: You should be able to base one object on another.
4) Basic structure: an object can contain actions (i.e. functions or
methods) and data (i.e. properties)
Any replies (both from newbies/non-programmers and experienced authors)
would be greatly appreciated. Replies would ideally contain of an
example object, which contains the name to display e.g. when showing the
object in the inventory, an "examine xy"-message, and an example verb
action. But even simple suggestions, warnings and requests are welcome.
Thank you very much in advance.
Cheers,
M. Uli Kusterer
"The Witnesses of TeachText are everywhere..."
Jim Aikin
> whatever. How would you define objects in the source code if your
> objectives were:
Mmm. Maybe I'm being especially dense tonight, but I don't quite understand
the question.
> 1) Readability: English is the ideal.
You mean, what sort of syntax would one use in the source code in order to
make the source code readable? I haven't found that to be a big problem in
either Inform or TADS. One gets used to having to use escape sequences for
quotes and that sort of thing, but I suppose you could use angle-brackets
for all text that's destined to be output, and then let people use single
and double quotes freely within the brackets without forcing them to use
escape sequences.
> 2) Rememberability: the user should not have to remember in what order
> to specify short and long descriptions
> 3) Inheritance: You should be able to base one object on another.
> 4) Basic structure: an object can contain actions (i.e. functions or
> methods) and data (i.e. properties)
TADS does all that. I don't remember offhand whether Inform forces you to
specify the short description before the long one (I haven't used it since
'99) but I doubt it.
If you're thinking of writing a new game engine/compiler/interpreter, I'd
suggest that almost any natural syntax will do the job. Other questions are
deeper.
I would definitely recommend using braces, for instance, to enclose function
bodies. I recently had a look at Lingo (the Director scripting language),
and the lack of braces made my head hurt. Lingo also has hundreds of
keywords -- another weakness.
For my money, the more a language looks like C++, the better. The only
exceptions would be things that are IF-specific, like how you specify and
concatenate strings. C syntax doesn't do this at all well.
--Jim Aikin
David Welbourn
"Uli Kusterer" wrote:
> Imagine you were creating an IF interpreter like Inform, TADS, Hugo or
> whatever. How would you define objects in the source code if your
> objectives were:
>
> 1) Readability: English is the ideal.
Uh, that's kinda debatable. English isn't the most structured natural
language around, and programming languages like to be more rigidly
structured than any natural language. Further, English is kinda wordy. For
example, consider the common task of assigning a value. A programming
language that's readable like English would have statements like:
Set description of mailbox to "There's an old-fashioned mailbox
attached to the wall here.".
But you'd get really tired of typing "Set x of y to z", or "Let x of y be
z", or "The x of y is z", and you'll want to use shorter operands to do the
same thing, eg:
mailbox.description = "There's an old-fashioned mailbox attached to the
wall here.".
Even repeating the word "mailbox" is going to get tiresome after a long
string of assignments in a row, and you'll want to have a block of code
where "mailbox" can be left out, eg:
define mailbox of class container, scenery [
.nouns = ["box", "mailbox"];
.adjectives = ["mail", "old", "old-fashioned", "fashioned"];
.name = "old-fashioned mailbox";
.article = "an";
.description = "There's an old-fashioned mailbox that looks
somewhat out of place, mounted on the wall. It would probably look better in
front of a white house. The mailbox is " & { if (self.is_open) "open."; else
"closed." };
.is_open = true;
.is_visible = true;
.location = StrangeLobby;
.on_open = { if (self.is_open) { "But the mailbox is already
open!"; } else { "You open the mailbox."; self.is_open = true; } };
.on_close = { if (self.is_open) { "You close the mailbox.";
self.is_open = false; } else { "But the mailbox is already closed!"; } };
]
Notice that I decided to treat properties and attributes like full members
of the object. At the very least, this avoids the "is" / "with" / "has" /
"give" x "to" y business of Inform.
Anyway, that's my first draft attempt at an answer. Hope it helps define the
question a little better.
-- David Welbourn
Uli Kusterer
"David Welbourn" <dsw...@look.ca> wrote:
> Uh, that's kinda debatable. English isn't the most structured natural
> language around, and programming languages like to be more rigidly
> structured than any natural language. Further, English is kinda wordy.
David,
thank you a lot for your input. Actually, in my case, I considered it
one of the points that wasn't "debatable". That's why I put
"Readability" at position #1. I know the variety of English grammatical
constructs and real-life restraints like parsing speed and
disambiguation makes it impossible to use real English as a programming
language, but my goal is to come close, to make creating IF more
accessible for authors (in the traditional sense of the term).
I am aware of the downsides of this approach, but there are already
enough languages that let programmers contend on their own playgrounds,
while few of the languages (I think Hugo is the only exception) really
purposely cater to people who aren't seasoned programmers already.
(except for excellent documentation)
> define mailbox of class container, scenery [
> .nouns = ["box", "mailbox"];
> .adjectives = ["mail", "old", "old-fashioned", "fashioned"];
> .name = "old-fashioned mailbox";
> .article = "an";
> .description = "There's an old-fashioned mailbox that looks
> somewhat out of place, mounted on the wall. It would probably look better in
> front of a white house. The mailbox is " & { if (self.is_open) "open."; else
> "closed." };
> .is_open = true;
> .is_visible = true;
> .location = StrangeLobby;
> .on_open = { if (self.is_open) { "But the mailbox is already
> open!"; } else { "You open the mailbox."; self.is_open = true; } };
> .on_close = { if (self.is_open) { "You close the mailbox.";
> self.is_open = false; } else { "But the mailbox is already closed!"; } };
> ]
>
> Notice that I decided to treat properties and attributes like full members
> of the object. At the very least, this avoids the "is" / "with" / "has" /
> "give" x "to" y business of Inform.
Could you elaborate what you mean by the distinction "full members" ?
What would be a "half member" or whatever is the appropriate counterpart?
> Anyway, that's my first draft attempt at an answer.
I will definitely take your thoughts into consideration, though my
general intent was to go for something that purposely doesn't look like
C/C++, you have provided a good starting point for further discussion.
Thanks!
Uli Kusterer
"Jim Aikin" <spam...@musicwords.net> wrote:
> Mmm. Maybe I'm being especially dense tonight, but I don't quite understand
> the question.
I'm sorry. English isn't my first language...
> > 1) Readability: English is the ideal.
>
> You mean, what sort of syntax would one use in the source code in order to
> make the source code readable? I haven't found that to be a big problem in
> either Inform or TADS. One gets used to having to use escape sequences for
> quotes and that sort of thing, but I suppose you could use angle-brackets
> for all text that's destined to be output, and then let people use single
> and double quotes freely within the brackets without forcing them to use
> escape sequences.
That's a nice thought, thanks!
> TADS does all that. I don't remember offhand whether Inform forces you to
> specify the short description before the long one (I haven't used it since
> '99) but I doubt it.
I did some dabbling in TADS, and I liked it the best of the major
languages I had a look at.
There are other features for which I don't quite agree with MJR's
choices (like the way Multimedia is done), and he already told me he
didn't have any plans to go where I would want such a language to go.
> I'd
> suggest that almost any natural syntax will do the job. Other questions are
> deeper.
I have an idea of my own, but I would like to see other people's
approaches at really readable object definitions (as in "readable like a
novel" and not necessarily as in "short and concise mathematical
notation"), in case anyone has a much better idea than me. I've been
programming a little too long to be trusted to distinguish between
machine-readable and human-readable syntax.
> I would definitely recommend using braces, for instance, to enclose function
> bodies. I recently had a look at Lingo (the Director scripting language),
> and the lack of braces made my head hurt. Lingo also has hundreds of
> keywords -- another weakness.
Do you think this is really something every language should do, or is
it perhaps just your being used to C-like languages? (this is a genuine
question, no offense meant) Although I've been programming for years and
I can read C++ in my dreams (ignoring that typically you can't really
read in dreams, but I digress), I do not necessarily consider it the
most accessible syntax for people new to programming.
Sure, it's a "learn once - use for the rest of your life" syntax if you
take into account that everything from TADS to Objective C uses syntax
derived from C, but people for whom an adventure game will probably be
the deepest they get into programming it might be easier to choose
something closer to what they already know as they might never need to
learn Java or C++ in their entire life.
> For my money, the more a language looks like C++, the better. The only
> exceptions would be things that are IF-specific, like how you specify and
> concatenate strings. C syntax doesn't do this at all well.
Except for the problem with the token used for starting/ending strings,
TADS already does what you want perfectly well (TADS 3 is even closer to
C than its kind of Pascal-ish predecessor). I should have made it more
clear what I'm thinking of, I guess, but with my most recent two posts,
I suppose I will have made it more clearly what I was hoping for.
But anyway, thanks for reminding me of the issue of quotes in strings.
I should really give this some thought as well.
Uli Kusterer
"Jim Aikin" <spam...@musicwords.net> wrote:
> I would definitely recommend using braces, for instance, to enclose function
> bodies. I recently had a look at Lingo (the Director scripting language),
> and the lack of braces made my head hurt. Lingo also has hundreds of
> keywords -- another weakness.
In what regard do you think having many keywords is a weakness? Do you
mean there is too much to memorize? Or are you talking about reserved
keywords which make it impossible to find variable names that aren't
used? The last time I used Director was probably in the early nineties,
and Lingo has changed a lot since then... for example Director's grown a
Windows version...
EPerson
5) Being concise.
There shouldn't have to be scores of unnesscessary parts like "let
value of score increase by value of points property of magic diamond".
when you could say "score += diamond.points".
Uli Kusterer
esch...@safeaccess.com (EPerson) wrote:
Hi,
Well, since it is point #5, and thus in order less important as #1
(readability), I have no problem with that. But to continue your
example, if I had the choice between
score += diamond.points
and
add diamond's points to score
I'd go with the latter, even though it's 5 characters longer. But
actually, I was looking for object definitions. If anybody still has any
suggestions in that direction, I'd be grateful.
Andrew Plotkin
> In article <10co8.4051$Ya2.2...@newsread1.prod.itd.earthlink.net>,
> "Jim Aikin" <spam...@musicwords.net> wrote:
>> I would definitely recommend using braces, for instance, to enclose function
>> bodies. I recently had a look at Lingo (the Director scripting language),
>> and the lack of braces made my head hurt. Lingo also has hundreds of
>> keywords -- another weakness.
> In what regard do you think having many keywords is a weakness? Do you
> mean there is too much to memorize? Or are you talking about reserved
> keywords which make it impossible to find variable names that aren't
> used?
I would worry about both... also, if you've set up a general approach
of "one keyword per feature", then you have to keep *adding* keywords,
which is bad. Old code can break if previously unreserved keywords
become reserved.
Of course, there are ways to avoid this.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
David Welbourn
> > Notice that I decided to treat properties and attributes like full
members
> > of the object. At the very least, this avoids the "is" / "with" / "has"
/
> > "give" x "to" y business of Inform.
Uli Kusterer replied:
> Could you elaborate what you mean by the distinction "full members" ?
> What would be a "half member" or whatever is the appropriate counterpart?
Well, when I was writing up my example, at first I had a line line this in
the code:
.properties = ~open container ~takeable visible;
and I ran into problems with a) how does one modify inherited properties, b)
how does one test a property, c) how does one set a property. And I found
myself writing snippets of code like:
.properties = super.properties ~open visible;
.properties.open = 1;
if (self is open) {....}
{"You close the mailbox."; self <- ~open; }
And I didn't like any of that. It isn't clean. I shouldn't have to invent
new keywords like "is" or new operands like "<-" to express established
operations like testing for equivalence or assigning a value, just because
"open" is a property. So I rewrote it so that "is_open" is just yet another
member of mailbox with a boolean value, to be treated the same way as the
members with array, string, or code values.
----
Returning to the issue of making programming statements look more like
English, yes, assignment operators can be some form of "let/set (the) x of
(the) y equal/be/be equal to/to/is z", but other common operations are not
so easy to enanglisize. To wit, how would the following statement be more
closely expressed in English?:
mailbox.description = "The mailbox is " & { if (self.is_open) { "
open."; } else { "closed."; } };
Would it really be easier to encode this as:
Set the mailbox's description to "The mailbox is " plus either "open."
if the mailbox's is_open is true else "closed.".
-- David Welbourn
Joe Mason
David Welbourn <dsw...@look.ca> wrote:
>Well, when I was writing up my example, at first I had a line line this in
>the code:
>
> .properties = ~open container ~takeable visible;
Ick.
properties = not open, container, not takeable, visible
I agree that English-style for the sake of English-style is a bad thing to
aim for, but there's no reason to use a cryptic symbol for *everything*.
>Returning to the issue of making programming statements look more like
>English, yes, assignment operators can be some form of "let/set (the) x of
>(the) y equal/be/be equal to/to/is z", but other common operations are not
>so easy to enanglisize. To wit, how would the following statement be more
>closely expressed in English?:
>
> mailbox.description = "The mailbox is " & { if (self.is_open) { "
>open."; } else { "closed."; } };
>
>Would it really be easier to encode this as:
>
> Set the mailbox's description to "The mailbox is " plus either "open."
>if the mailbox's is_open is true else "closed.".
set mailbox's description to "The mailbox is "
if mailbox isOpen then:
add "open." to mailbox's description
otherwise:
add "closed." to mailbox's description
(Notice I'm using Python's indentation-delimitation syntax here. None of that
ugly 'end' crap.)
But 'set ... to ...' would get pretty annoying to type after a while. I like
a minimalist syntax.
set mailbox's description to "The mailbox is ..."
set house's description to "The house is ..."
set this
set that
Much easier to type
mailbox's description = "The mailbox is ..."
house's description = "The house is ..."
etc.
People know enough to be able to tell what = does. Or you can use "is" for
assignment and = to test equality.
(One thing I am in favour of is using "and", "or" and "not" instead of &&, ||,
!-or-~-or-whatever.)
These have been random comments brought to you by the campaign-to-avoid-
doing-schoolwork.
Joe
wo...@one.net
Hi Uli Kusterer:
> I will definitely take your thoughts into consideration, though my
>general intent was to go for something that purposely doesn't look like
>C/C++, you have provided a good starting point for further discussion.
>Thanks!
You might look at Python for inspiration, PAWS is quite simple and
English-like. I believe you asked for a simple object, how about:
Acorn = ClassScenery("acorn,acorns","large,huge,enormous,big")
Acorn.StartingLocation = Brenin
Acorn.Article = "an"
Acorn.SetDesc("L","The acorns are huge, but otherwise unremarkable.")
Acorn.SetDesc("Feel","""
It weighs about a pound but except for its large
size and weight feels
like a normal acorn.
""")
Acorn.SetDesc("Odor","It smells like any other acorn")
Acorn.SetDesc("Take","""
The acorns are unremarkable, except in size.
After examining one you
realize its uselessness and drop it.
""")
Acorn.SetDesc("Taste","""
The acorn's shell is way too tough to bite thru,
and licking it merely
leaves a slightly bitter taste in your mouth.
""")
It doesn't matter what order you set properties in, there's no syntax
sugar to sour the taste. Python is object oriented, English-like,
simple and consistant. Block structure uses indentation, like an
outline.
Here's how to create a new kind of room:
class ClassCliffRoom(ClassOutside):
"""Class for an outdoor 'room' alongside the cliff."""
#------------
# Default Map
#------------
DefaultMap = {North: "There is a cliff there.",
Northeast: "There is a cliff there.",
East: "There is a cliff there.",
Southeast: "There is a cliff there.",
South: "There is a cliff there.",
Southwest: "There is a cliff there.",
West: "There is a cliff there.",
Northwest: "There is a cliff there.",
Up: "The cliffs are unclimbable.",
Down: "There's no way down.",
Upstream: "There's no stream here.",
Downstream: "There's no stream here.",
In: "There's nothing here to enter.",
Out: "There's nothing here to exit."}
def SetMyProperties(self):
"""Sets default instance properties"""
self.HasCliff = TRUE
self.HasWall = FALSE
self.SetDesc("Ground","""
The ground is rocky and stony, with
liberal
amounts of dirt showing. Not at all
inviting,
but nothing unusual for the base of a
cliff.
""")
self.SetDesc("Sky","""
Most of the sky is cut off by the cliffs
and the
trees, but what you can see is blue with a
few
fluffy white clounds. Good weather to be
OUT of
this valley, hmm?
""")
And this is actually doing some pretty complex things. You can use
this room type to further refine other room types, like this:
class ClassValleyWall(ClassCliffRoom):
#------------
# Default Map
#------------
DefaultMap = {North: "There is a cliff there.",
Northeast: "There is a cliff there.",
East: "There is a cliff there.",
Southeast: "There is a cliff there.",
South: "There is a cliff there.",
Southwest: "There is a cliff there.",
West: "There is a cliff there.",
Northwest: "There is a cliff there.",
Up: "The cliffs are unclimbable.",
Down: "Not without mining tools, friend.",
Upstream: "There's no stream here.",
Downstream: "There's no stream here.",
In: "There's nothing here to enter.",
Out: "There's nothing here to exit."}
def SetMyProperties(self):
"""Sets default instance properties"""
self.SetDesc("Odor","The air carries the sharp reek of dust.")
self.SetDesc("Sound","You can hear the wind whispering around
the cliff tops.")
Which can be *further* refined:
class ClassNorthValleyWall(ClassValleyWall):
def SetMyProperties(self):
"""Sets default instance properties"""
self.NamePhrase = "North Valley Wall"
self.SetDesc("L","""
You are standing before the north wall of the
valley.
Behind you (to the south) the forest stands
silent and
dim. The valley walls stretch out of sight to
either
side.
""")
So that when you want to make several identical rooms all you have to
say is:
NorthWall1 = ClassNorthValleyWall() # Room 7
NorthWall2 = ClassNorthValleyWall() # Room 19
NorthWall3 = ClassNorthValleyWall() # Room 23
NorthWall4 = ClassNorthValleyWall() # Room 24
NorthWall5 = ClassNorthValleyWall() # Room 35
and just change whatever individual properties you want to later on.
Inheritance is a marvelous thing...
Does that help, or have I missed the point? :)
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
EPerson
object crate oftype container
in platform,
called ("old crate"),
nouns "crate" "box",
adjectives "old" defaults,
examine ("The crate is old and wooden. It contains ";
ListContents(crate); "."),
take ("A security officer notices you holding the
crate and makes you put it down."),
enter (player.in = crate;
"You quickly enter the crate before anybody
notices."),
close defaults (if (player.in = crate) "You are now hidden
from the outside."),
open true;
The word defaults includes the things inherited from "container" that
would otherwise be lost. in the new adjectives definition (words like
"open" and closed" from the adjective list, say).
David A. Cornelson
news:witness-867111...@news.t-online.com...
> Hi,
>
> Imagine you were creating an IF interpreter like Inform, TADS, Hugo or
> whatever. How would you define objects in the source code if your
> objectives were:
>
This is a nice question and rendered differently enough to garner my
attention. It's not a Java vs. c++ vs. xyz post...more of comfort question.
I use Inform, but have recently picked up c# and have used JavaScript a lot
in my webdev work. I have varying likes and dislikes about all the languages
I know. Let's see what I like here:
- curly braces: for some reason these have grown on me...i'm not a natural
c/c++ programmer, but having used them in Inform and in C#, I'd say they're
essential to any object definition.
- constructors: Inform forces you to list the property names you're
assigning. Might not be bad to have some default constructors (overidable)
that skipped the property names and allowed the programmer to just do
something like:
object.new(oLivingRoom, "Living Room", {'living','room'},"This is the living
room of your house. It's a mess.",{light,scenery});
oLivingRoom.addChild(oChair,"LazyBoy Chair",{'lazyboy','chair'},"It's your
favorite chair.",{scenery});
instead of
object oLivingRoom "Living Room"
with name 'living' 'room',
description "This is the living room of your house. It's a
mess.",
has light scenery;
--
I guess this lends itself to a strongly typed environment and I don't know
if that's appropriate for IF.
Why do I feel like I'm writing TADS code here. This C# stuff has rubbed off
_way too much_.
Jarb
kodrik
> English-like. I believe you asked for a simple object, how about:
For a C like language that's easier, I find php amazing. You pick it up in
no time if you know a modular language and it got rid of most annoying
things you encounter in C or Java.
It is developed and maintained by a large open source community and they
have done an incredible job at defining a great syntax.
http://php.net
kodrik
> keywords which make it impossible to find variable names that aren't
> used?
About the reserver keywords in variables, in php you must put a variable
name in front of variables so you can name them almost anything you want.
$echo="Hello world";
echo $echo;
It even let's you do things like:
$name="$kodrik";
printf("Hello, my name is $name and I am happy to see you\n");
I find it to work really well.
David Given
"David Welbourn" <dsw...@look.ca> writes:
> "Uli Kusterer" wrote:
[...]
>> 1) Readability: English is the ideal.
>
> Uh, that's kinda debatable. English isn't the most structured natural
> language around, and programming languages like to be more rigidly
> structured than any natural language.
Indeed.
At this point it would be worth repeating the old Unix-user's lecture on
learning curves. There's a different between easy to learn, and easy to
use.
An application that's easy to learn would be Notepad. You point, you
type, text appears. Very little training is required to make it work,
but you can't do much. The learning curve in this case is concave
(starts out shallow, gets very steep very fast).
An application that's easy to use would be Vi. You need to have lots of
training to make it do anything at all, but once you have that training,
you can make it do just about anything. The learning curve here is
convex (starts out steep, gets shallower).
Now, when it comes to programming, you *have* to have some training.
It's usually easier to require a little bit more training at the
beginning and save a lot of time later. Instead of training the language
to understand the user being vague, and trust me, English *is* vague, it
saves far more time in the long run to train the user to be precise and
have the language reject anything that isn't precise. It means that the
user is forced to express its problems precisely.
David's example is a good one. I'd say, however, that the reason for
using the more complex syntax is not to save time in typing out long
statements, but rather to change the emphasis from the statements
themselves to the operations they represent. The more time you worry
about getting the syntax right, the less time you have to worry about
getting the logic right.
--
+- David Given --------McQ-+ "Under communism, man exploits man. Under
| Work: d...@tao-group.com | capitalism, it's just the opposite." --- John
| Play: d...@cowlark.com | Kenneth Galbrith
+- http://www.cowlark.com -+
Kevin Forchione
I don't see why.
> Why do I feel like I'm writing TADS code here. This C# stuff has rubbed off
> _way too much_.
Heh. Watch it Dave, you're borderline TADS Convert....
In TADS 3 you'd code:
oLivingRoom: Room
{
'living room' 'living room'
"This is the living room of your house. It's a mess."
}
The lighting and scenery equivalents would be handled by the Room
class. Doing what you suggest above... the TADS 3 equivalent:
x = new Room(...);
would assign a dynamically-created object to x. You wouldn't be able
to reference the object as oLivingRoom, but you could certainly handle
nearly all of the assignments you suggest - except the double quoted
string would have to be a single-quoted string and Room.desc() would
have to be a method that displayed the string.
--Kevin
Aris Katsaris
"EPerson" <esch...@safeaccess.com> wrote in message
news:6e5fc465.02032...@posting.google.com...
> Okay, I'd aim for something like
>
> object crate oftype container
> in platform,
> called ("old crate"),
> nouns "crate" "box",
> adjectives "old" defaults,
> examine ("The crate is old and wooden. It contains ";
> ListContents(crate); "."),
> take ("A security officer notices you holding the
> crate and makes you put it down."),
> enter (player.in = crate;
> "You quickly enter the crate before anybody
> notices."),
> close defaults (if (player.in = crate) "You are now hidden
> from the outside."),
> open true;
This seems a bit nasty - the minglings of verbs with characteristics.
The confusion between "open"-as-adjective and "close"-as-verb shows
that best I think...
And why the parenthesis around "old crate" when it's the same usage
as nouns "crate" "box"?
How about:
object crate oftype container
in platform,
called "old crate",
nouns "crate" "box",
adjectives "old" defaults,
open true,
actions [
examine ("The crate is old and wooden. It contains ";
ListContents(crate); "."),
take ("A security officer notices you holding the
crate and makes you put it down."),
enter (player.in = crate;
"You quickly enter the crate before anybody
notices."),
close defaults (if (player.in = crate) "You are now hidden
from the outside."),
];
Ofcourse that's close enough to Inform that I guess I'm just influenced
by it in the way I think...
Aris Katsaris
kodrik
> The confusion between "open"-as-adjective and "close"-as-verb shows
> that best I think...
>
> And why the parenthesis around "old crate" when it's the same usage
> as nouns "crate" "box"?
I find it very interesting and it could be a scripting format to put behind
my engine on top of a gui interface.
If the parser tells the difference between an
adjective and a verb than it could understand "close the box" as well as
"close the open box" just from what he specified in his code.
As for the parenthesis, I think it is to define an object name, it is not
used by the parser but it could be used in inventory description, echoing
message related to this object and as an easy reference to the object.
If his goal is readability, I found his code much esier to understand to
someone alien to IF coding than the one you posted.
EPerson
> "EPerson" <esch...@safeaccess.com> wrote in message
> news:6e5fc465.02032...@posting.google.com...
> > Okay, I'd aim for something like
> >
> > object crate oftype container
> > in platform,
> > called ("old crate"),
> > nouns "crate" "box",
> > adjectives "old" defaults,
> > examine ("The crate is old and wooden. It contains ";
> > ListContents(crate); "."),
> > take ("A security officer notices you holding the
> > crate and makes you put it down."),
> > enter (player.in = crate;
> > "You quickly enter the crate before anybody
> > notices."),
> > close defaults (if (player.in = crate) "You are now hidden
> > from the outside."),
> > open true;
>
> This seems a bit nasty - the minglings of verbs with characteristics.
> The confusion between "open"-as-adjective and "close"-as-verb shows
> that best I think...
Oh, you're right. I didn't see that. Anyway, we'll need some way
differing between the "open" verb and "open" property.
> And why the parenthesis around "old crate" when it's the same usage
> as nouns "crate" "box"?
It's supposed to be a routine to print the "short name" of the crate.
It would be kind of cumbersome, so we could say if it's just a string
it's printed (making it even closer to Inform than your revision
below.)
> How about:
>
> object crate oftype container
> in platform,
> called "old crate",
> nouns "crate" "box",
> adjectives "old" defaults,
> open true,
> actions [
> examine ("The crate is old and wooden. It contains ";
> ListContents(crate); "."),
> take ("A security officer notices you holding the
> crate and makes you put it down."),
> enter (player.in = crate;
> "You quickly enter the crate before anybody
> notices."),
> close defaults (if (player.in = crate) "You are now hidden
> from the outside."),
> ];
>
> Ofcourse that's close enough to Inform that I guess I'm just influenced
> by it in the way I think...
>
> Aris Katsaris
This is a fair revision. The verbs are now sub-properties. So this is
what the symbols are: commas separate properties, semi-colons seperate
statements and definitions, brackets enclose a set of sub-properties,
and parentheses enclose routines.
Eric Schmidt, F-iest
David Given
wo...@one.net writes:
[...]
> You might look at Python for inspiration, PAWS is quite simple and
> English-like. I believe you asked for a simple object, how about:
The prototype Smalltalk IF library I've been vaguely thinking about
would look something like:
(world addObject: #Acorn ofClass: #Scenery
withNames: #(acorn acorns))
set: #adjectives to:
#(large huge enormous big);
set: #location to:
#brenin;
set: #article to:
#an;
setHandler: #describe to:
'The acorns are huge, but otherwise unremarkable.';
setHandler: #feel to:
'It weighs about a pound but except for its large size
and weight feels like a normal acorn.';
setHandler: #smell to:
'It smells like any other acorn.';
setHandler: #take to:
[
player tell: 'The acorns are unremarkable, except in size.
After examining one you realize its uselessness
and drop it.'.
self abortHandler
];
setHandler: #taste to:
'The acorn's shell is way too tough to bite through, and
licking it merely leaves a slightly bitter taste in your
mouth.';
realise
Internally, addObject would create a new class called WorldSceneryClass,
create Smalltalk properties for every set:to: call, create methods to
access the properties, create methods to *set* the properties, etc. I'm
still thinking about it.
--
+- David Given --McQ-+ Q. How much wood would a woodchuck chuck if a
| d...@cowlark.com | woodchuck could chuck wood?
| (d...@tao-group.com) | A. A woodchuck that could chuck wood would chuck as
+- www.cowlark.com --+ much wood as a woodchuck would.
Uli Kusterer
> object crate oftype container
I'd probably add a space between "of" and "type", but so far I like it.
> in platform,
> called ("old crate"),
"in" and "called" are quite a nice idea. Though they don't look very
good when used in statements like "if crate.in = platform then..."
> nouns "crate" "box",
> adjectives "old" defaults,
> (...)
> The word defaults includes the things inherited from "container" that
> would otherwise be lost. in the new adjectives definition (words like
> "open" and closed" from the adjective list, say).
Hmmm... nice idea :-)
Uli Kusterer
thanks for all the input. I had something in mind already, but I was
trying to find out whether it's really a good solution. I have already
learned a couple of things during this thread, but mostly it is similar
to my idea. My main objective was really coming up with english-like
syntax, and my apologies go to all whose syntax I rejected because it
looked like C or Inform or something in that vein.
Here's what I came to now:
object pete of type Actor
in startroom
called ''Peter "the Spider" Parker''
nouns "peter", "parker"
adjectives "peter"
has description: "Peter is your typical wallflower student."
has isHim: true
on take
output "You can't just take a human!!!"
exit take -- anybody have an idea for a sensible shortcut?
end take
end pete
Any suggestions, improvements? You can leave away "output" to print a
string. Strings in double apostrophes are the same as quoted strings,
they just make it easier to write quotes and apostrophes in your text.
You only need escape sequences (\n and the likes) if you want line
breaks or two apostrophes immediately following each other.
I'll probably allow defining an object all in one row, and properties
and actions will be order-independent. I.e. you can also do:
object pete called "Peter" of type Actor has description: "Boring"
end pete
Any ideas how I can get rid of the "end pete" without causing
ambiguities? My only idea so far is having a period be a synonym for
"end pete" in this case.
kodrik
>
> in startroom
> called ''Peter "the Spider" Parker''
> nouns "peter", "parker"
> adjectives "peter"
> has description: "Peter is your typical wallflower student."
> has isHim: true
>
> on take
> output "You can't just take a human!!!"
> exit take -- anybody have an idea for a sensible shortcut?
> end take
>
> end pete
1:
I would use a begin and end symbol, I actualy think it is more readable
than using text, even for non programmers. When it get complex you can add
comment to specify what ending you are reffering to.
The user only has to read important text, and ending command is noise that
clogs the english reading, at least in my view.
2:
I would end the lines with ";" so a user can specify multiple lines as one
without worrying of reserved keyword.
Being able to lay on multiple lines makes the code more easy to read.
3:
What will be the name referred for inventory and other output referring to
the object, the first one listed?
4:
Being able to easily comment makes a huge difference in coding.
I like the // synthax for single line comment
5:
Youare using a comma sperator for the nouns but not the name. I would use
the comma seperator, it works well.
Example:
// Spider man actor
object pete of type Actor
{
in startroom;
called "Peter", // Default referring is to Peter
'the "Spider"', // I could have written this in one line
"Parker",
"It's majesty"; // the ; marks the end
nouns "peter", "parker";
adjectives "peter";
has description: "Peter is your typical wallflower student.";
has isHim: true;
on take
{
output "You can't just take a human!!!";
}
} // end pete
Daniel Barkalow
> Hi,
>
> Imagine you were creating an IF interpreter like Inform, TADS, Hugo or
> whatever. How would you define objects in the source code if your
> objectives were:
>
> 1) Readability: English is the ideal.
It's sort of odd to hear both this and that English isn't your first
language. Assuming you mean that natural language is the ideal, and
English is the most common one here, though...
The thing about computer programs is that the punctuation is very
important. Natural languages resolve ambiguity through context, and more
often than not, through interaction. This is not at all appropriate for
computer programs.
> 2) Rememberability: the user should not have to remember in what order
> to specify short and long descriptions
This can be solved by labelling things, or at least giving the option of
labelling things. You still have to remember things, but at least you have
something more sensible to remember.
> 3) Inheritance: You should be able to base one object on another.
> 4) Basic structure: an object can contain actions (i.e. functions or
> methods) and data (i.e. properties)
>
> Any replies (both from newbies/non-programmers and experienced authors)
> would be greatly appreciated. Replies would ideally contain of an
> example object, which contains the name to display e.g. when showing the
> object in the inventory, an "examine xy"-message, and an example verb
> action. But even simple suggestions, warnings and requests are welcome.
Object -> {
parseName 'phone' 'book' 'phonebook';
called "phone book";
description "#It #is yellow and formidable.";
reactAfter() {
match (action) {
dropAction:
insteadPrint "#You somehow manage#i to drop #ito right on "
"#your foot. #It #is quite heavy.";
}
}
} PhoneBook;
Verb {
parse() {
match (text) {
'drop' "#O":
if (!actor.holds(object))
continue;
return dropAction;
}
}
}
Action {
action() {
object.location = actor.location;
print "Dropped";
}
}
This means:
We create an object (not derived from another class). It is placed in the
most recently defined room (Inform-derived syntax, which turns out to be
easy to understand and very short).
Its parseName includes the words 'phone', 'book', and 'phonebook'. The
single quotes indicate that these are single-word patterns, which
basically means that the case doesn't matter, because the player could do
different things with it. The parseName is what the player calls the
object.
Its called field is what the game calls the object.
The description is a single string. The words starting with # signs are
marked as such to indicate how the interpreter should modify them if it
needs to fix the syntax. In this case it is unlikely to matter. However,
the game may respond with "The phone book is yellow and formidable"; it
uses "the" as the article, since none is specified, and will replace the
"#It" with the object's called field if the object is not the most
recently mentioned value for "it".
reactAfter() is called after the action's core implementation has been run
(i.e., the object has been moved to the location).
insteadPrint ditches what would normally be printed, and instead prints
its message. In this message "#You" gets replaced by the current actor
(generally the player, but not necessarily; any actor who drops the phone
book has it land on their foot), which will normally lead to it being
"You" (although it could be "John" or "He"). The "#i" inflects the verb
for the subject. "#ito" is like "#it", but is the object of the verb, and
doesn't affect #i. "#is" woulds like "#i", but for the verb to be.
At the end of the declaration is a global variable name for the object.
The verb is similar.
parse() is called to compare what the player typed to what should trigger
the verb. This pattern compares the dictionary word 'drop' with the first
word, and then looks for an object. Any objects which fit but aren't held
by the actor are ignored. For any held by the player, we have a drop
action.
The drop action moves the object to the actor's location, and prints a
message. Note that the message may be overridden by a particular object,
however.
If you want, you can put brackets around lists and commas between the
items in them, but that isn't necessary in these situations. Parentheses
are permitted around function arguments (like for print), but these are
also optional.
-Iabervon
*This .sig unintentionally changed*
Joe Mason
>1:
>I would use a begin and end symbol, I actualy think it is more readable
>than using text, even for non programmers. When it get complex you can add
>comment to specify what ending you are reffering to.
>The user only has to read important text, and ending command is noise that
>clogs the english reading, at least in my view.
Having used both { } and Python's indentation rules, I find them about
equally good. But the word 'end' is a really bad thing. First of all, you
type it a lot. A lot a lot. Almost as much as "foo = bar", you want
something short to end your blocks with. Second, most good programming
editors will either have a "find the matching }" function or will
automatically mark code with mismatched braces and such. With "end", that's
much harder to do. (Unless, like Pascal, you use both "begin" and "end",
which is even wordier than "if <whatever> end".)
>4:
>Being able to easily comment makes a huge difference in coding.
>I like the // synthax for single line comment
Yes, an easy way to do a single line comment is good. But also a way to do
multiline comments, so that if a whole object isn't working yet, you can
take the whole thing out temporarily without having to type // before every
line.
// An object which could mess up the rest of the game
/* Not working yet
Object ...
*/
That's the one thing I hate most about working with Inform. (And Python.)
Though I suppose, now that I think of it, in Inform I could use "If 0" ...
"EndIf" to take out blocks of text without actually deleteing them. Man,
I've wasted a lot of time before realizing that just now.
Joe
kodrik
> /* Not working yet
> Object ...
>
> */
>
> That's the one thing I hate most about working with Inform. (And Python.)
> Though I suppose, now that I think of it, in Inform I could use "If 0" ...
> "EndIf" to take out blocks of text without actually deleteing them. Man,
> I've wasted a lot of time before realizing that just now.
If you're trying to debug a synthax error that may be due to someting a few
lines up (like not closing "), this won't help you as much as commenting
out.
For me block text commenting was a given and it's synthax doesn't need to
be as simple as single line commenting since you don't use it a much (I do
prefer the synthax /* */ if I had a choice).
On top of that, like you mentionned for the {}, many editors will render
comments differently for easier reading of the code.
Uli Kusterer
Daniel Barkalow <iabe...@iabervon.org> wrote:
> It's sort of odd to hear both this and that English isn't your first
> language. Assuming you mean that natural language is the ideal, and
> English is the most common one here, though...
Yes, that's basically what I'm saying. I just didn't want to get too
philosophical in my first post of this thread...
> The thing about computer programs is that the punctuation is very
> important. Natural languages resolve ambiguity through context, and more
> often than not, through interaction. This is not at all appropriate for
> computer programs.
Yes. But I would like to avoid too much "punctuation" like a semicolon
following every instruction, and instead go for things the authors
already know, like whitespace and line breaks.
> This can be solved by labelling things, or at least giving the option of
> labelling things. You still have to remember things, but at least you have
> something more sensible to remember.
Exactly. And since English is what the users very likely know how to
speak, I'll try to label things in English, so it looks like a real
sentence. Why use goTo to satisfy a simplistic language when you can
write "go to" and thus make it look even more natural and easy to
remember.
> Object -> {
What's the "->" for?
> parseName 'phone' 'book' 'phonebook';
> called "phone book";
> description "#It #is yellow and formidable.";
> reactAfter() {
> match (action) {
> dropAction:
> insteadPrint "#You somehow manage#i to drop #ito right on "
> "#your foot. #It #is quite heavy.";
> }
> }
> } PhoneBook;
>
> Verb {
> parse() {
> match (text) {
> 'drop' "#O":
> if (!actor.holds(object))
> continue;
> return dropAction;
> }
> }
> }
>
> Action {
> action() {
> object.location = actor.location;
> print "Dropped";
> }
> }
>
> This means:
>
> We create an object (not derived from another class). It is placed in the
> most recently defined room (Inform-derived syntax, which turns out to be
> easy to understand and very short).
That thing with the most recently defined room is a nice idea :-)
> Its parseName includes the words 'phone', 'book', and 'phonebook'. The
> single quotes indicate that these are single-word patterns, which
> basically means that the case doesn't matter, because the player could do
> different things with it. The parseName is what the player calls the
> object.
I prefer the TADS-like concept of nouns and adjectives. Makes for
better gameplay (less ambiguities about things like "plant pot plant in
plant pot"), and is easy to understand even for people who weren't great
at school.
> Its called field is what the game calls the object.
Yeah, someone else already suggested that.
> The description is a single string. The words starting with # signs are
> marked as such to indicate how the interpreter should modify them if it
> needs to fix the syntax. In this case it is unlikely to matter. However,
> the game may respond with "The phone book is yellow and formidable"; it
> uses "the" as the article, since none is specified, and will replace the
> "#It" with the object's called field if the object is not the most
> recently mentioned value for "it".
Hmmm... that's something to consider. TADS has this with %you% and such
things ... Though the # sign is used much too frequently, and same goes
for %.
> reactAfter() is called after the action's core implementation has been run
> (i.e., the object has been moved to the location).
I don't think having a separate reactAfter method is that good. Doesn't
being able to call through to the inherited code work just fine for such
cases? Just make an action like:
on drop
call inherited drop
"Somehow you manage to drop it right on your foot. It's quite heavy."
end drop
Or are there cases I'm missing where a reactAfter() method is actually
useful?
> insteadPrint ditches what would normally be printed, and instead prints
> its message.
Nice idea, though I like TADS's outcapture better. To extend the
example above, I'd do the following pseudo-English:
on drop
without output
call inherited drop
end without
"Somehow you ..."
end drop
> At the end of the declaration is a global variable name for the object.
Well, being so pedantic about English, I think it'd be more natural if
the object's variable name stayed with the "Object" term.
> parse() is called to compare what the player typed to what should trigger
> the verb. This pattern compares the dictionary word 'drop' with the first
> word, and then looks for an object. Any objects which fit but aren't held
> by the actor are ignored. For any held by the player, we have a drop
> action.
>
> The drop action moves the object to the actor's location, and prints a
> message. Note that the message may be overridden by a particular object,
> however.
>
> If you want, you can put brackets around lists and commas between the
> items in them, but that isn't necessary in these situations. Parentheses
> are permitted around function arguments (like for print), but these are
> also optional.
I'm not really caring about customizing the parser right now. A pretty
simple built-in parser is enough right now, and having a verb do its
parsing itself is kind of annoying I'd go for:
verb goVerb
verb: "go"
preposition: "to"
on goTo dobj
send goTo dobj to Player -- call player's goTo method that moves it.
end goTo
end goTo
Uli Kusterer
> 1:
> I would use a begin and end symbol, I actualy think it is more readable
> than using text, even for non programmers. When it get complex you can add
> comment to specify what ending you are reffering to.
> The user only has to read important text, and ending command is noise that
> clogs the english reading, at least in my view.
I've been thinking about supporting { and } as alternate syntax kind of
like you did as well. Though I'm loathe to introduce unnecessary
alternative syntax. But I agree that the "end" statement is kind of
awkward. What I'd really like to do is do away with _any_kind_ of ending
indicator, but that would make it hard to define functions, because it'd
essentially force you to either declare them in a special way, or before
you start defining your first object. Any ideas?
> 2:
> I would end the lines with ";" so a user can specify multiple lines as one
> without worrying of reserved keyword.
> Being able to lay on multiple lines makes the code more easy to read.
I gave this some thought, but I rarely have code where I needed to put
several statements on one line. Where I did it, it usually hampered
readability. However, I do have the concept of a line continuation
character (currently \), which you can specify at the end of a line to
allow it to continue in the next line.
> 3:
> What will be the name referred for inventory and other output referring to
> the object, the first one listed?
the "called" thing. I just wanted to show off my special double quotes.
It would be:
called "Peter \"the Spider\" Parker"
if you can read that Syntax better. I just chose ''Peter "the Spider"
Parker'' instead, to show off that by using two apostrophes instead of a
quote, you have a more natural way of using quotes in a string. After
all, IF has lots of text with lots of quotes usually.
> 4:
> Being able to easily comment makes a huge difference in coding.
> I like the // synthax for single line comment
I have -- and # for one-line comments, and (* ... *) for multi-line
right now. "--" looks more like a side note, and (* ... *) is
reminiscent of ( ... ) which also makes people understand more easily
that it's a comment. I couldn't use () because that would have screwed
up the maths stuff.
> 5:
> Youare using a comma sperator for the nouns but not the name. I would use
> the comma seperator, it works well.
The comma wasn't necessary, because the name wasn't a list. It was just
text.
> // Spider man actor
> object pete of type Actor
> {
> in startroom;
> called "Peter", // Default referring is to Peter
> 'the "Spider"', // I could have written this in one line
> "Parker",
> "It's majesty"; // the ; marks the end
> nouns "peter", "parker";
> adjectives "peter";
> has description: "Peter is your typical wallflower student.";
> has isHim: true;
>
> on take
> {
> output "You can't just take a human!!!";
> }
> } // end pete
After adding a couple more spaces, I can kind of live with {} as
alternatives to having an "end take" at the end.
Uli Kusterer
jcm...@student.math.uwaterloo.ca (Joe Mason) wrote:
> Having used both { } and Python's indentation rules, I find them about
> equally good. But the word 'end' is a really bad thing. First of all, you
> type it a lot. A lot a lot. Almost as much as "foo = bar", you want
> something short to end your blocks with. Second, most good programming
> editors will either have a "find the matching }" function or will
> automatically mark code with mismatched braces and such. With "end", that's
> much harder to do. (Unless, like Pascal, you use both "begin" and "end",
> which is even wordier than "if <whatever> end".)
It's not hard to do that with "end". Oh, and you do have a "begin":
It's the "object" or "on". But I agree, it would require a specialized
editor for this language. But "end" alone would be too dangerous. It
would sound like some kind of "quit" or "exit" command.
kodrik
> It would be:
>
> called "Peter \"the Spider\" Parker"
>
> if you can read that Syntax better. I just chose ''Peter "the Spider"
> Parker'' instead, to show off that by using two apostrophes instead of a
> quote, you have a more natural way of using quotes in a string. After
> all, IF has lots of text with lots of quotes usually.
The best is if you can enclose your strings in single quotes or double
quotes and only have to escape the ones matching the enclosing:
Both would be recognized and processed accordingly:
"It's \"Spider\" the man"
'It\s "Spider" the man'
> I have -- and # for one-line comments, and (* ... *) for multi-line
> right now. "--" looks more like a side note, and (* ... *) is
> reminiscent of ( ... ) which also makes people understand more easily
> that it's a comment. I couldn't use () because that would have screwed
> up the maths stuff.
I think // and /* */ is the best synthax, it is good to the eye. You
shoud use a standard syntax for comments, it is important that editors can
view them as comment and format them accordingly. It makes your code so
much more readible.
Bennett Standeven
> In article <uaah1r4...@corp.supernews.com>, kodrik <kod...@zc8.net>
> wrote:
>
> > 1:
> > I would use a begin and end symbol, I actualy think it is more readable
> > than using text, even for non programmers. When it get complex you can add
> > comment to specify what ending you are reffering to.
> > The user only has to read important text, and ending command is noise that
> > clogs the english reading, at least in my view.
>
> I've been thinking about supporting { and } as alternate syntax kind of
> like you did as well. Though I'm loathe to introduce unnecessary
> alternative syntax. But I agree that the "end" statement is kind of
> awkward. What I'd really like to do is do away with _any_kind_ of ending
> indicator, but that would make it hard to define functions, because it'd
> essentially force you to either declare them in a special way, or before
> you start defining your first object. Any ideas?
Why not use the semicolon as a block terminator, if you aren't using
it to end lines? Alternatively, require blocks, functions, etc. to end
with a return statement.
Uli Kusterer
be...@pop.networkusa.net (Bennett Standeven) wrote:
> Why not use the semicolon as a block terminator, if you aren't using
> it to end lines? Alternatively, require blocks, functions, etc. to end
> with a return statement.
I was considering using a period for a while, but both a semicolon as
well as the period are too easily overlooked. Lines like "end xy"
quickly make it clear that here is an object's end.
Uli Kusterer
wrote:
> The best is if you can enclose your strings in single quotes or double
> quotes and only have to escape the ones matching the enclosing:
>
> Both would be recognized and processed accordingly:
> "It's \"Spider\" the man"
> 'It\s "Spider" the man'
That's basically how it works. But since I had huge problems to
remember escaping single quotes in TADS, I thought I'd use two single
quotes instead. That way, you can write:
''It's "red", you fool''
and you don't have to escape anything.
> I think // and /* */ is the best synthax, it is good to the eye. You
> shoud use a standard syntax for comments, it is important that editors can
> view them as comment and format them accordingly. It makes your code so
> much more readible.
My goal is to make it readable to humans, not to make it look nice to
programmers. I'm catering to writers, to which -- and (**) will look
much more rememberable than the // and /* */ that programmers use.
I still have #, which most Unix people should recognize as the comment
character used in shell scripts.
kodrik
> remember escaping single quotes in TADS, I thought I'd use two single
> quotes instead. That way, you can write:
>
> ''It's "red", you fool''
>
> and you don't have to escape anything.
I didn't realize that, that is really smart.
You will have to provide a nice editor with code highlight because most
editors won't support your syntax.
SteveG
It's a good working example of a language that emphasizes readability
over conciseness.
For example, it uses 'end' rather than {} to delimit blocks; 'make x
y' for boolean attributes or 'set x to y' rather than 'x==y'; refers
to attributes as 'attribute of object' rather than 'object.attribute'.
Object definitions look like this:
object rock
has weight 5.
is inanimate.
is not takeable.
description "There is a big rock thing here."
end object.
Bits of code (in verb definitions for example) might look like this
verb chip
check chisel in inventory
else "You'd need a chisel to do that."
does
"You chip a hunk off the rock with your chisel."
decrease weight of rock.
if weight of rock < 3 then
make rock takeable.
end if.
end verb.
-- SteveG
remove _X_ from my address to send me email
Uli Kusterer
stev_...@actrix.gen.nz (SteveG) wrote:
> object rock
> has weight 5.
> is inanimate.
> is not takeable.
> description "There is a big rock thing here."
> end object.
Huh? That looks pretty much like what I came up with ?!
> Bits of code (in verb definitions for example) might look like this
>
> verb chip
> check chisel in inventory
> else "You'd need a chisel to do that."
>
> does
> "You chip a hunk off the rock with your chisel."
> decrease weight of rock.
> if weight of rock < 3 then
> make rock takeable.
> end if.
> end verb.
Does ALAN also do per-object verbs? Or do you have to scatter the code
for each object across the verbs? Is it available for Unix/Mac?
-- um, wait, ignore that last paragraph. I'll try to look up the URL for
ALAN.
Uli Kusterer
wrote:
> I didn't realize that, that is really smart.
> You will have to provide a nice editor with code highlight because most
> editors won't support your syntax.
Gee, thanks :-)
But last time I tried to write my own text editor it ended in lots of
funny text scattered all across my window as soon as I tried to select
anything :-(
But I'm sure Emacs folks will be able to write a syntax coloring script
for that ...
wo...@one.net
>That's the one thing I hate most about working with Inform. (And Python.)
>Though I suppose, now that I think of it, in Inform I could use "If 0" ...
>"EndIf" to take out blocks of text without actually deleteing them. Man,
>I've wasted a lot of time before realizing that just now.
You might consider an editor that can comment all highlighted lines,
both the PowerBuilder IDE and the FoxPro IDE allow this.
Respectfully,
Wolf
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
wo...@one.net
Hi Uli,
>I've been thinking about supporting { and } as alternate syntax kind of
>like you did as well. Though I'm loathe to introduce unnecessary
>alternative syntax. But I agree that the "end" statement is kind of
>awkward. What I'd really like to do is do away with _any_kind_ of ending
>indicator, but that would make it hard to define functions, because it'd
>essentially force you to either declare them in a special way, or before
>you start defining your first object. Any ideas?
Python does this with indentation, there's no "end" marker in Python.
Of course indentation has its own issues, TANSTAFFL and all that...
SteveG
wrote:
[snip]
> Does ALAN also do per-object verbs? Or do you have to scatter the code
>for each object across the verbs? Is it available for Unix/Mac?
yes, no and yes
>-- um, wait, ignore that last paragraph. I'll try to look up the URL for
>ALAN.
To make it easier for you ...
"The ALAN Home Pages" -- http://www.welcome.to/alan-if
>
>Cheers,
>M. Uli Kusterer
>"The Witnesses of TeachText are everywhere..."
-- SteveG
Daniel Barkalow
> In article <Pine.LNX.4.21.02033...@iabervon.org>,
> Daniel Barkalow <iabe...@iabervon.org> wrote:
>
> > It's sort of odd to hear both this and that English isn't your first
> > language. Assuming you mean that natural language is the ideal, and
> > English is the most common one here, though...
>
> Yes, that's basically what I'm saying. I just didn't want to get too
> philosophical in my first post of this thread...
>
> > The thing about computer programs is that the punctuation is very
> > important. Natural languages resolve ambiguity through context, and more
> > often than not, through interaction. This is not at all appropriate for
> > computer programs.
>
> Yes. But I would like to avoid too much "punctuation" like a semicolon
> following every instruction, and instead go for things the authors
> already know, like whitespace and line breaks.
I think authors are generally pretty accustomed to having punctuation at
the end of each instruction-sized chunk of natural language. As long as
you only have one sort of punctuation, I don't think this will be a source
of confusion. I don't think natural language tends toward using words to
finish things.
> > This can be solved by labelling things, or at least giving the option of
> > labelling things. You still have to remember things, but at least you have
> > something more sensible to remember.
>
> Exactly. And since English is what the users very likely know how to
> speak, I'll try to label things in English, so it looks like a real
> sentence. Why use goTo to satisfy a simplistic language when you can
> write "go to" and thus make it look even more natural and easy to
> remember.
>
> > Object -> {
>
> What's the "->" for?
It's the "put the object in the room" syntax. If you don't put one, the
object is not in anything (it's a verb or action or something, or a room,
or will be brought into play later). If you have one, the new object goes
in the most recent object with none. If you have two, the new object goes
in the most recent object with one, etc. I can't think of a word to use,
but it's sufficiently handy that it would be worth explaining. It works a
bit like nestable bullet lists.
I've never found that it is terribly important to be able to have objects
where the order of words in the name matters.
> > The description is a single string. The words starting with # signs are
> > marked as such to indicate how the interpreter should modify them if it
> > needs to fix the syntax. In this case it is unlikely to matter. However,
> > the game may respond with "The phone book is yellow and formidable"; it
> > uses "the" as the article, since none is specified, and will replace the
> > "#It" with the object's called field if the object is not the most
> > recently mentioned value for "it".
>
> Hmmm... that's something to consider. TADS has this with %you% and such
> things ... Though the # sign is used much too frequently, and same goes
> for %.
I like the idea of being able to tag the pronouns with something and have
the game deal with getting the pronouns right, even when a bunch of
messages are strung together in an unexpected order. Of course, this isn't
necessary if you don't want to do it (unless you're planning to change
from 2nd person to 3rd person or something). It's mostly that the library
could be written that way for extra flexibility, so that library messages
don't sound bad in conjunction with the author's own text.
> > reactAfter() is called after the action's core implementation has been run
> > (i.e., the object has been moved to the location).
>
> I don't think having a separate reactAfter method is that good. Doesn't
> being able to call through to the inherited code work just fine for such
> cases? Just make an action like:
>
> on drop
> call inherited drop
> "Somehow you manage to drop it right on your foot. It's quite heavy."
> end drop
>
> Or are there cases I'm missing where a reactAfter() method is actually
> useful?
reactAfter() itself isn't that useful, but it suggests other methods which
are useful. You can have one which works like reactAfter() except gets
called on the indirect object. You can have one which gets triggered when
an object is simply in the same room as the action. You can do both
"before" and "after" versions, where the former can prevent the action
from happening, and the latter expect that the action has already
happened.
> > insteadPrint ditches what would normally be printed, and instead prints
> > its message.
>
> Nice idea, though I like TADS's outcapture better. To extend the
> example above, I'd do the following pseudo-English:
>
> on drop
> without output
> call inherited drop
> end without
> "Somehow you ..."
> end drop
>
> > At the end of the declaration is a global variable name for the object.
>
> Well, being so pedantic about English, I think it'd be more natural if
> the object's variable name stayed with the "Object" term.
I usually find that the object's in-game naming properties usually end up
at the top (since they're easy to do first), and it would be nice to have
the name at the end.
> > If you want, you can put brackets around lists and commas between the
> > items in them, but that isn't necessary in these situations. Parentheses
> > are permitted around function arguments (like for print), but these are
> > also optional.
>
> I'm not really caring about customizing the parser right now. A pretty
> simple built-in parser is enough right now, and having a verb do its
> parsing itself is kind of annoying I'd go for:
>
> verb goVerb
> verb: "go"
> preposition: "to"
> on goTo dobj
> send goTo dobj to Player -- call player's goTo method that moves it.
> end goTo
> end goTo
I think you're likely to run into trouble with verbs that can take
different prepositions for different purposes. Also, I think having all of
the common actions expected of a physical object defined on the base class
is going to be less convenient than having the basic activity for a verb
defined in the verb, and only special cases on the objects. But that is,
in any case, a library issue, and not syntactic at all.
John W. Kennedy
> Exactly. And since English is what the users very likely know how to
> speak, I'll try to label things in English, so it looks like a real
> sentence. Why use goTo to satisfy a simplistic language when you can
> write "go to" and thus make it look even more natural and easy to
> remember.
Because several early languages allowed both "go to" and "goto" and
users invariably preferred "goto".
And because "natural" is bad. Programming isn't natural. Programming
is a difficult mental exercise requiring concentrated logical thought.
Do you do use English to do algebra? Do you think logic was better in
the days when Aristotle ruled and students had to use Latin mnemonics to
remember which of the 256 possible syllogism forms were valid? Do you
prefer, "The slope of a line tangent to the curve representing the locus
of points in which the vertical coordinate is equal to the square of the
horizontal coordinate is equal to twice the horizontal coordinate," to:
2
d/dx x = 2x
?
> > Object -> {
>
> What's the "->" for?
It means this object starts out contained in the prior object that does
not say "->".
Object pirate_room
Object -> treasure_chest
Object ->-> gold_doubloons
Object ->-> map
Object -> chair
Object ->-> skeleton
Object pit_room
...and so on.
--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html
Uli Kusterer
> I think authors are generally pretty accustomed to having punctuation at
> the end of each instruction-sized chunk of natural language. As long as
> you only have one sort of punctuation, I don't think this will be a source
> of confusion. I don't think natural language tends toward using words to
> finish things.
True, but punctuation is so easily left out, and is then rather hard to
track down. Also, it's pretty annoying to have to end each sentence on
each line with a period (a semicolon is common in programming, but is
actually a rarely used thing in actual writing), especially considering
how short instructions in a game are. But I'll give it some thought. It
wouldn't be too hard to make a period an equivalent to a line break.
> It's the "put the object in the room" syntax. If you don't put one, the
> object is not in anything (it's a verb or action or something, or a room,
> or will be brought into play later). If you have one, the new object goes
> in the most recent object with none. If you have two, the new object goes
> in the most recent object with one, etc. I can't think of a word to use,
> but it's sufficiently handy that it would be worth explaining. It works a
> bit like nestable bullet lists.
Using "->" for that really isn't obvious enough for me. To me, arrows
indicate connections, but a "connection to nothing" seems kind of
strange. This "with one" "with none" etc. business also seems kind of
error-prone. Location-dependent changes can become really hairy. It's a
nice idea as far as typing less is concerned, though.
I could probably just get away with having the "location" property
default to the previous room if not explicitly specified (for objects,
not for verbs, and not for other rooms, of course), but even that seems
awkward.
> I've never found that it is terribly important to be able to have objects
> where the order of words in the name matters.
Well, the example I mentioned definitely causes problems in Inform, but
not in TADS, and TADS has a certain kind of order-dependency. However,
there is nothing keeping you from writing small red chair or red small
chair, as long as the defining word, the chair, is at the end. My
example was:
$ put pot plant in plant pot
"pot plant" and "plant pot" have 100% the same names, just that the
order is different. I've already done a parser that can handle this, and
it does so by using adjectives and nouns. It is quite a nice feature and
still IMHO simple to understand. I never released a game, but I started
a couple, and I had several places where this dictinction came in handy.
> I like the idea of being able to tag the pronouns with something and have
> the game deal with getting the pronouns right, even when a bunch of
> messages are strung together in an unexpected order. Of course, this isn't
> necessary if you don't want to do it (unless you're planning to change
> from 2nd person to 3rd person or something). It's mostly that the library
> could be written that way for extra flexibility, so that library messages
> don't sound bad in conjunction with the author's own text.
Yeah. It's a great feature. I just don't like sentences like "%it% %is%
a strange object, but %you% like%s% %ito%" Because "ito" is not a real
word. I'd probably go with something like "he" instead of "it", where
these two are different (e.g. "%he% is a very strange object, but %you%
like%s% %him%"). This sounds a little weird, but not as Italian as "ito"
:-)
> reactAfter() itself isn't that useful, but it suggests other methods which
> are useful. You can have one which works like reactAfter() except gets
> called on the indirect object. You can have one which gets triggered when
> an object is simply in the same room as the action. You can do both
> "before" and "after" versions, where the former can prevent the action
> from happening, and the latter expect that the action has already
> happened.
I like the concept, though in OOP it can be done pretty easily. You can
do something _before_ calling the inherited method, instead of calling
the inherited method, and _after_ calling the inherited method. Also,
you can, if aborting a method is done using exceptions, catch the
exception and do something when the inherited method was aborted.
But I see the advantage of beforeXXX and afterXXX now: They can be
replaced separately. That means, while the player code would actually
override doXXX, the library could for certain objects override afterXXX
and this would be called even _after_ the user's doXXX. That's smart,
and with a consistent naming scheme will work great! Thanks :-)
> I usually find that the object's in-game naming properties usually end up
> at the top (since they're easy to do first), and it would be nice to have
> the name at the end.
I don't like that much. The player will only see the in-game name,
true, but to the game author (NB -- by "author" I previously actually
meant "writer", sorry for the confusion), the object's "variable name"
as you call it is actually more important. That's why I personally
prefer it at the top. I guess it's a matter of personal preferences.
> I think you're likely to run into trouble with verbs that can take
> different prepositions for different purposes. Also, I think having all of
> the common actions expected of a physical object defined on the base class
> is going to be less convenient than having the basic activity for a verb
> defined in the verb, and only special cases on the objects. But that is,
> in any case, a library issue, and not syntactic at all.
Um, no. I'm supporting several prepositions. The doXXX message always
consists of the verb name and any prepositions used that aren't
adjectives to objects (i.e. the "of" in "international house of mojo" is
not considered a preposition, but rather an adjective). That means that
several prepositions will be handled as:
verb go
verb: "go"
prepositions: "to" "around" "into"
on doGoTo
-- react
end doGoTo
on doGoAround
-- react
end doGoAround
on doGoInto
-- react
end doGoInto
end go
Uli Kusterer
stev_...@actrix.gen.nz (SteveG) wrote:
> yes, no and yes
Thanks! I just DLed the latest Mac version. It's nice, but I'm not yet
sure if it's what I'm looking for... I didn't notice its great Syntax
because the author of the sample scripts kept writing certain keywords
in uppercase...
> "The ALAN Home Pages" -- http://www.welcome.to/alan-if
Thanks, but I found it pretty quickly in the FAQ. It's really great to
have a newsreader that lets you simply select "Get FAQ" for a newsgroup
:-)
Uli Kusterer
wrote:
> Python does this with indentation, there's no "end" marker in Python.
> Of course indentation has its own issues, TANSTAFFL and all that...
Wolf,
after a delightful trip to AskJeeves (and a short stopover at one of
the "catch unsuspecting users"-pages that has registered a mistyped
aksjeeves), I now know what TANSTAFFL means :-)
Anyway, indentation would probably be a nice idea. But I'm not sure it
fits in with my current designs, and I _am_ a little lazy on such
occasions ;-)
L. Ross Raszewski
> True, but punctuation is so easily left out, and is then rather hard to
>track down. Also, it's pretty annoying to have to end each sentence on
>each line with a period (a semicolon is common in programming, but is
>actually a rarely used thing in actual writing), especially considering
>how short instructions in a game are. But I'll give it some thought. It
>wouldn't be too hard to make a period an equivalent to a line break.
>
If language dictated that you had to start each sentence on a line of
its own, and end out on the same line, the period would probably not
be in common use. Books would be rather longer, I think, and more telegraphic.
I think the relative obscurity of the semicolon is directly related
to its use in programming; it happens to mean what it's supposed to
mean, and it's uncommon enough in english that it's not liable to be
misused -- The period might be an "easier" statement separator,
but because it's common, it's got a lot of uses. YOu can't have a '.'
separate statements if you're going to use it for anything else --
particularly for a radix point (as in languages which support floating
point numbers) or the object-property separator (as in most OO
languages besides smalltalk)
(ANd if you think you can, by having clever context-dependent rules,
well, even if context-dependent rules were a good idea, I'm quite sure
it won't work. There will always be a context in which your meaning
is ambiguous)
>
> Using "->" for that really isn't obvious enough for me. To me, arrows
>indicate connections, but a "connection to nothing" seems kind of
>strange. This "with one" "with none" etc. business also seems kind of
>error-prone. Location-dependent changes can become really hairy. It's a
>nice idea as far as typing less is concerned, though.
>
> I could probably just get away with having the "location" property
>default to the previous room if not explicitly specified (for objects,
>not for verbs, and not for other rooms, of course), but even that seems
>awkward.
Well, lots of people object to inform's convention of allowibng you to
inexplicitly set the location of an object. On the other hand, it's a
lot less error prone than manually specifying all the parent-child
relationships, then changing one of them. (also, it allows you to not
explicitly name objects at all, which is a boon if you sdon't care to
clutter the namespace.
If you don't like the syntatctic feel of '->', call it "therein", as I
do when I feel the need to read inform aloud.
Jim Aikin
> >What I'd really like to do is do away with _any_kind_ of ending
> >indicator,
My god -- why?
> Python does this with indentation, there's no "end" marker in Python.
> Of course indentation has its own issues, TANSTAFFL and all that...
(1) Indentation sucks. That is, it sucks if it's required as a syntax
element in order to get the code to compile. It's lovely as an optional
element to make the code easier to read.
(2) That would be TANSTAAFL.
--Jim Aikin
Joe Mason
Jim Aikin <spam...@musicwords.net> wrote:
>> Python does this with indentation, there's no "end" marker in Python.
>> Of course indentation has its own issues, TANSTAFFL and all that...
>
>(1) Indentation sucks. That is, it sucks if it's required as a syntax
>element in order to get the code to compile. It's lovely as an optional
>element to make the code easier to read.
Have you used Python? You're not allowed to criticize Python due to its
indentation until you've used it. If you've tried it (that is, written at
least one useful script) and you still think it sucks, then you can say
that.
Joe
Andrew Plotkin
I've used Python (see Boodler on my web site), and the indentation
thing clearly sucks.
I like Python because every language has to suck in at least one way,
and the way Python sucks is tidy and self-contained. The indentation
thing doesn't interfere with any *other* feature of the language.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Ferlin Scarborough
"Jim Aikin" <spam...@musicwords.net> wrote in message
news:35cq8.9991$nt1.7...@newsread2.prod.itd.earthlink.net...
>
> (1) Indentation sucks. That is, it sucks if it's required as a syntax
> element in order to get the code to compile. It's lovely as an optional
> element to make the code easier to read.
>
Any of you ever program in RPG?
I did several years back, and every thing had to be in a CERTAIN COLUMN, now
that SUCKED!!!!!!
Later.
Ferlin.
Uli Kusterer
"Jim Aikin" <spam...@musicwords.net> wrote:
> > >What I'd really like to do is do away with _any_kind_ of ending
> > >indicator,
>
> My god -- why?
Because when I usually speak I don't say "end of sentence" after every
sentence, but rather I just lower my voice a little at the end and
everybody knows the sentence is ending here. It's more natural.
But so far I haven't found a way that pleased me to simulate this
natural way of speaking in a programming language, save for a period,
which is way too easily overlooked.
Uli Kusterer
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
> If language dictated that you had to start each sentence on a line of
> its own, and end out on the same line, the period would probably not
> be in common use. Books would be rather longer, I think, and more
> telegraphic.
You have agood point there ...
> I think the relative obscurity of the semicolon is directly related
> to its use in programming; it happens to mean what it's supposed to
> mean, and it's uncommon enough in english that it's not liable to be
> misused -- The period might be an "easier" statement separator,
> but because it's common, it's got a lot of uses. YOu can't have a '.'
> separate statements if you're going to use it for anything else --
> particularly for a radix point (as in languages which support floating
> point numbers) or the object-property separator (as in most OO
> languages besides smalltalk)
>
> (ANd if you think you can, by having clever context-dependent rules,
> well, even if context-dependent rules were a good idea, I'm quite sure
> it won't work. There will always be a context in which your meaning
> is ambiguous)
Well, the language I currently have in mind wouldn't have much of a
problem with this. It doesn't use the period for object properties, and
I think floating point numbers aren't much of a problem since most
seasoned writers follow a period that ends a sentence with at least one
space, while they don't do that for floating point numbers.
But this is way too iffy still for me to do it. I agree, having them
broken per line isn't very nice either, but so far that tradeoff seems
to be less critical for a programming language than having people mix
this up with floating point numbers or simply overlooking them.
> Well, lots of people object to inform's convention of allowibng you to
> inexplicitly set the location of an object. On the other hand, it's a
> lot less error prone than manually specifying all the parent-child
> relationships, then changing one of them. (also, it allows you to not
> explicitly name objects at all, which is a boon if you sdon't care to
> clutter the namespace.
>
> If you don't like the syntatctic feel of '->', call it "therein", as I
> do when I feel the need to read inform aloud.
I'll give it a thought. Thanks for making me aware of these issues!
wo...@one.net
Hi Jim,
>> >What I'd really like to do is do away with _any_kind_ of ending
>> >indicator,
>
>My god -- why?
Because they're a pain in the butt. Forget one and it's cascade city.
:) They're also harder to spot in a quick scan of the code.
>> Python does this with indentation, there's no "end" marker in Python.
>> Of course indentation has its own issues, TANSTAFFL and all that...
>
>(1) Indentation sucks. That is, it sucks if it's required as a syntax
>element in order to get the code to compile. It's lovely as an optional
>element to make the code easier to read.
Having used the indentation in Python for some time I find it quite
desirable. While it has some drawbacks (such as a problem with tabs
and spaces) it enforces good coding behavior, it's simple, and
unambigous to the eye.
Using an editor that automatically converts tab to spaces (most
editors) and voila! No tab/space problem...
>(2) That would be TANSTAAFL.
That would be correct... :) Darned fat-fingered typing. :)
Magnus Olsson
Uli Kusterer <wit...@t-online.de> wrote:
>In article <35cq8.9991$nt1.7...@newsread2.prod.itd.earthlink.net>,
> "Jim Aikin" <spam...@musicwords.net> wrote:
>
>> > >What I'd really like to do is do away with _any_kind_ of ending
>> > >indicator,
>>
>> My god -- why?
>
> Because when I usually speak I don't say "end of sentence" after every
>sentence, but rather I just lower my voice a little at the end and
>everybody knows the sentence is ending here. It's more natural.
>
> But so far I haven't found a way that pleased me to simulate this
>natural way of speaking in a programming language, save for a period,
>which is way too easily overlooked.
The main reason programming languages have to be much more formal
about such details than natural language is to simplify
parsing. Languages can be categorized according to how complex their
grammar is, in the sense of how much work needs to be done to parse
the language correctly. Natural languages are off the scale on the
difficult end; programming languages are designed to lie at the easy
end, ven if it inconveniences the programmer.
A trivial example is the need in Pascal to declare a function before
it is used. This is not necessary: the compiler could in principle
simply read ahead in the source code until it finds the function
declaration; however, this would complicate the parsing process (IIRC,
Pascal was deliberately designed to allow one-pass compilers with low
memory usage).
--
Magnus Olsson (m...@df.lth.se)
Magnus Olsson
Uli Kusterer <wit...@t-online.de> wrote:
>In article <a8b4e1$7sg$1...@foobar.cs.jhu.edu>,
> lrasz...@loyola.edu (L. Ross Raszewski) wrote:
>
>> If language dictated that you had to start each sentence on a line of
>> its own, and end out on the same line, the period would probably not
>> be in common use. Books would be rather longer, I think, and more
>> telegraphic.
>
> You have agood point there ...
Punctuation is a pretty recent innovation. In antiquity, the Greeks
wrote their texts in one continuous stream, often without even word
breaks. Andyoucanstillreadtextwithoutspacesorpunctuationitjustbecomes
abitharderontheeyesdoesntit
>> I think the relative obscurity of the semicolon is directly related
>> to its use in programming; it happens to mean what it's supposed to
>> mean, and it's uncommon enough in english that it's not liable to be
>> misused -- The period might be an "easier" statement separator,
>> but because it's common, it's got a lot of uses. YOu can't have a '.'
>> separate statements if you're going to use it for anything else --
>> particularly for a radix point (as in languages which support floating
>> point numbers) or the object-property separator (as in most OO
>> languages besides smalltalk)
Cobol uses . as a statement terminator. And Forth, while not using
it as a statement terminator, uses it in several different ways.
In a C-like language, you could replace ';' with '.' if you tightened
up the rules on whitespace somewhat and disallowed floating-point
numbers ending in a point ("12." vs. "12.0").
--
Magnus Olsson (m...@df.lth.se)
L. Ross Raszewski
> Well, the language I currently have in mind wouldn't have much of a
>problem with this. It doesn't use the period for object properties, and
>I think floating point numbers aren't much of a problem since most
>seasoned writers follow a period that ends a sentence with at least one
>space, while they don't do that for floating point numbers.
Tricky. I've actually written programs which determine whether a '.'
character is an end of sentence or not, using training data from
respectable news sources, and the best I could do was about 98%
accuracy. You do not want to heuristically compile programs.
L. Ross Raszewski
>
>In a C-like language, you could replace ';' with '.' if you tightened
>up the rules on whitespace somewhat and disallowed floating-point
>numbers ending in a point ("12." vs. "12.0").
Well, yes. But you'd actually have to insist that the statement separator
was 'period+whitespace'; 4+12.3+9 vs 4+12. 3+9 Generally, I'm opposed
to making whitespace meaningful, and I'm even more opposed to making
it a part of some other token (if you're going to mandate the
whitespace after the period, you might as well do away with the period
and fall back on a whitespace-based separator, which seems naughty)
I do think it's interesting that *so many* languages use the semicolon
as the statement separator; all the C-like languages do, of course,
but non C-likes such as Ml do as well. I'm harder pressed to find a
language that *doesn't* use a semicolon (among languages which don't
use a newline), though I seem to recall smalltalk using '!' in some
contexts (presumably the "and I really mean it" operator.)
Magnus Olsson
L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>On 3 Apr 2002 07:36:47 GMT, Magnus Olsson <m...@df.lth.se> wrote:
>>
>>In a C-like language, you could replace ';' with '.' if you tightened
>>up the rules on whitespace somewhat and disallowed floating-point
>>numbers ending in a point ("12." vs. "12.0").
>
>Well, yes. But you'd actually have to insist that the statement separator
>was 'period+whitespace'; 4+12.3+9 vs 4+12. 3+9
Not quite: you could go the way of Forth, and use whitespace as a
*token* separator. Or disallow statements starting with numbers, and
replace the qualification operator (as in class.member) with something
else.
>I do think it's interesting that *so many* languages use the semicolon
>as the statement separator; all the C-like languages do, of course,
>but non C-likes such as Ml do as well.
I think it's simply the heritage from Algol 60.
>I'm harder pressed to find a
>language that *doesn't* use a semicolon (among languages which don't
>use a newline), though I seem to recall smalltalk using '!' in some
>contexts (presumably the "and I really mean it" operator.)
Many Basics use a colon instead (because the semicolon is used in
print statements):
10 PRINT X; : X = X + 1 : GOTO 10
and I seem to remember that BCPL used something different from semicolon
as well, but I may be wrong.
And, of course, many assemblers use ; to indicate a comment.
--
Magnus Olsson (m...@df.lth.se)
Matthew Russotto
--
Matthew T. Russotto mrus...@speakeasy.net
=====
Every time you buy a CD, a programmer is kicked in the teeth.
Every time you buy or rent a DVD, a programmer is kicked where it counts.
Every time they kick a programmer, 1000 users are kicked too, and harder.
A proposed US law called the CBDTPA would ban the PC as we know it.
This is not a joke, not an exaggeration. This is real.
http://www.cryptome.org/broadbandits.htm
Matthew Russotto
>it a part of some other token (if you're going to mandate the
>whitespace after the period, you might as well do away with the period
>and fall back on a whitespace-based separator, which seems naughty)
So are you going to join me in picketing Stroustroup?
Daryl McCullough
>A trivial example is the need in Pascal to declare a function before
>it is used. This is not necessary: the compiler could in principle
>simply read ahead in the source code until it finds the function
>declaration; however, this would complicate the parsing process (IIRC,
>Pascal was deliberately designed to allow one-pass compilers with low
>memory usage).
I think that a lot of the grammar restrictions for programming
languages serve another purpose besides ease of parsing: ease
of understanding (and debugging). In the cases where parsing
is difficult, often it's also hard for a programmer looking
over the code to figure out what the code is supposed to be
doing.
--
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Magnus Olsson
> I think that a lot of the grammar restrictions for programming
> languages serve another purpose besides ease of parsing: ease
> of understanding (and debugging). In the cases where parsing
> is difficult, often it's also hard for a programmer looking
> over the code to figure out what the code is supposed to be
> doing.
Yes, that's an important reason - but humans are still better than
computers at understanding. One example is the following template
instantiation in C++:
vector<vector<int>> foo;
A human has no problem understanding that the ">>" token is the closing
template parenthesis, and not the right shift operator, but many compilers
can't figure that out, and require extra whitespace in order not to give
a syntax error:
vector<vector<int> > foo;
I'm not quite current with whether the C++ standard requires the space
or not, but I've used compilers that were smart enough not to require it,
and it's certainly not needed for human comprehension (unless the code
is of obfuscated-C-contest quality, of course :-) ).
--
Magnus Olsson (m...@df.lth.se)
John W. Kennedy
> YOu can't have a '.'
> separate statements if you're going to use it for anything else --
> particularly for a radix point (as in languages which support floating
> point numbers)
...or fixed-point fractions, for that matter.
John W. Kennedy
> I do think it's interesting that *so many* languages use the semicolon
> as the statement separator; all the C-like languages do, of course,
> but non C-likes such as Ml do as well. I'm harder pressed to find a
> language that *doesn't* use a semicolon (among languages which don't
> use a newline), though I seem to recall smalltalk using '!' in some
> contexts (presumably the "and I really mean it" operator.)
COBOL and some dialects of BASIC are the only ones that comes to mind,
and COBOL's syntax in this respect is massively screwed up. A period
doesn't just end statements, it ends all outstanding IF's and ELSE's,
for which reason, COBOL statements are also endable by -- ta-da! --
semicolons. (Except for the last statement of a paragraph, which has to
be ended by a period.)
Oh, strictly speaking, of course, in ALGOL and Pascal, semicolons don't
end statements, but separate them. (N statements employ N-1
semicolons.)
L. Ross Raszewski
<russ...@grace.speakeasy.net> wrote:
>In article <a8edrj$hkg$2...@foobar.cs.jhu.edu>,
>L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>>
>>to making whitespace meaningful, and I'm even more opposed to making
>>it a part of some other token (if you're going to mandate the
>>whitespace after the period, you might as well do away with the period
>>and fall back on a whitespace-based separator, which seems naughty)
>
>So are you going to join me in picketing Stroustroup?
Eh. There are so many other reasons to fill with anger toward him, I
think I'll let that one slide -- I prefer to just pretend that
templates don't exist anyway.
Uli Kusterer
wrote:
> Punctuation is a pretty recent innovation. In antiquity, the Greeks
> wrote their texts in one continuous stream, often without even word
> breaks. Andyoucanstillreadtextwithoutspacesorpunctuationitjustbecomes
> abitharderontheeyesdoesntit
Reminds me of that book I saw at the store: Yxx cxn rxxd wxthxxt vxwxls.
> Cobol uses . as a statement terminator. And Forth, while not using
> it as a statement terminator, uses it in several different ways.
>
> In a C-like language, you could replace ';' with '.' if you tightened
> up the rules on whitespace somewhat and disallowed floating-point
> numbers ending in a point ("12." vs. "12.0").
Same thing I thought. My language doesn't do strong data typing, which
means it will convert between integers and floats as necessary.
Currently, a floating point number has to be consist of at least two
numeric characters separated by a period. No spaces or line breaks are
allowed inside a number. So, it would be fairly straightforward to use
"." as a sentence separator.
But, as I'm dealing with English right now, where it is pretty common
to write .44 instead of 0.44 (in German you _always_ write the leading
zero) I'm not sure I really should be that restrictive. But as in my
language 4. doesn't make sense, because it's just an integer, it would
still work.
Uli Kusterer
lrasz...@loyola.edu (L. Ross Raszewski) wrote:
> Well, yes. But you'd actually have to insist that the statement separator
> was 'period+whitespace'; 4+12.3+9 vs 4+12. 3+9 Generally, I'm opposed
> to making whitespace meaningful, and I'm even more opposed to making
> it a part of some other token (if you're going to mandate the
> whitespace after the period, you might as well do away with the period
> and fall back on a whitespace-based separator, which seems naughty)
This is a requirement I can probably make from my target audience,
because writers are used to having whitespace after a period.
> I do think it's interesting that *so many* languages use the semicolon
> as the statement separator; all the C-like languages do, of course,
> but non C-likes such as Ml do as well. I'm harder pressed to find a
> language that *doesn't* use a semicolon (among languages which don't
> use a newline), though I seem to recall smalltalk using '!' in some
> contexts (presumably the "and I really mean it" operator.)
Well, probably because a period is such a small character that it seems
a little too easy to overlook compared to a colon or a semicolon. The
comma is usually less important and only separates elements _inside_ a
sentence, which is why it gets away with being so tiny.
Uli Kusterer
wrote:
> The main reason programming languages have to be much more formal
> about such details than natural language is to simplify
> parsing. Languages can be categorized according to how complex their
> grammar is, in the sense of how much work needs to be done to parse
> the language correctly. Natural languages are off the scale on the
> difficult end; programming languages are designed to lie at the easy
> end, ven if it inconveniences the programmer.
I'm aware of that. However, my goal is to try to not inconvenience the
programmer if I can help it. Thus, being closer to natural language is a
plus, but of course I'm not a linguistics expert, which means actually
parsing natural language is beyond me (and anyway the way linguistics
pros see it, it's also beyond today's computers).
> A trivial example is the need in Pascal to declare a function before
> it is used. This is not necessary: the compiler could in principle
> simply read ahead in the source code until it finds the function
> declaration; however, this would complicate the parsing process (IIRC,
> Pascal was deliberately designed to allow one-pass compilers with low
> memory usage).
This is something I did away with in my language. You don't have to
define function prototypes (actually, they don't even exist). You just
call a function (or rather "send a message") and it is resolved at
runtime.
kodrik
It is also written with a comma instead of a period in may languages:
1.240,67
Magnus Prickus
[...]
> Punctuation is a pretty recent innovation. In antiquity, the Greeks
> wrote their texts in one continuous stream, often without even word
> breaks.
[...]
> Cobol uses . as a statement terminator. And Forth, while not using
> it as a statement terminator, uses it in several different ways.
>
> In a C-like language, you could replace ';' with '.' if you tightened
> up the rules on whitespace somewhat and disallowed floating-point
> numbers ending in a point ("12." vs. "12.0").
Note how wide and superficial my field of knowledge is. Not only does
my would-be wisdom cover computer language syntax, but also various
misconceptions concerning the history of punctuation. Even the
moderately educated person knows that there are punctuated Greek
inscriptions dating back to 7th c. BCE (e.g. Nestor's Cup). Obviously
I know next to nothing about ancient Greece. Does that stop me from
making sweeping and ignorant statements about ancient Greek
punctuation? Hell no! Nothing can stop me from talking about things I
know absolutely nothing about!
kodrik
>> wrote their texts in one continuous stream, often without even word
>> breaks.
>
> my would-be wisdom cover computer language syntax, but also various
> misconceptions concerning the history of punctuation. Even the
> moderately educated person knows that there are punctuated Greek
> inscriptions dating back to 7th c. BCE (e.g. Nestor's Cup). Obviously
> I know next to nothing about ancient Greece. Does that stop me from
> making sweeping and ignorant statements about ancient Greek
> punctuation? Hell no! Nothing can stop me from talking about things I
> know absolutely nothing about!
Punctuation in those days had no synthatical meaning. You could remove all
the punctuation and what you read had the same meaning. It was for
elocutionary purposes.
So his statement is prefectly justified, punctuation as a syntatical tool
Magnus Olsson
> Uli Kusterer wrote:
>
> > In article <a8ebef$smn$2...@news.lth.se>, m...@df.lth.se (Magnus Olsson)
> > wrote:
> >> In a C-like language, you could replace ';' with '.' if you tightened
> >> up the rules on whitespace somewhat and disallowed floating-point
> >> numbers ending in a point ("12." vs. "12.0").
> >
> > Same thing I thought. My language doesn't do strong data typing, which
> > means it will convert between integers and floats as necessary.
> > Currently, a floating point number has to be consist of at least two
> > numeric characters separated by a period. No spaces or line breaks are
> > allowed inside a number. So, it would be fairly straightforward to use
> > "." as a sentence separator.
> >
> > But, as I'm dealing with English right now, where it is pretty common
> > to write .44 instead of 0.44 (in German you _always_ write the leading
> > zero) I'm not sure I really should be that restrictive.
I forgot about numbers like ".44". The hypothetical language would have to
forbid that as well. I think it's a matter of what is most convenient for
the programmer: being allowed to use numbers such as ".44" or "4.", or being
allowed to use '.' as a statement terminator/separator.
By the way, what do you mean with that you're "dealing with English right
now"? Are you parsing natural English or a formal language that should
be similar to English?
> >But as in my
> > language 4. doesn't make sense, because it's just an integer, it would
> > still work.
Of course I can't say anything about your language, but in many programming
languages "4." does make sense - in C, for example, there's a big difference
between the expressions "1 / 4" (which evaluates to the integer 0) and
"1 / 4." (which evaluates to 0.25). Of course, being required to type
"4.0" instead is no big deal.
> It is also written with a comma instead of a period in may languages:
> 1.240,67
Yes. And Cobol actually has a statement "DECIMAL POINT IS COMMA" which
switches the meaning of '.' and ',' when dealing with numerical data.
--
Magnus Olsson (m...@df.lth.se)
Magnus Olsson
> >> Punctuation is a pretty recent innovation. In antiquity, the Greeks
> >> wrote their texts in one continuous stream, often without even word
> >> breaks.
> >
> > moderately educated person knows that there are punctuated Greek
> > inscriptions dating back to 7th c. BCE (e.g. Nestor's Cup).
>
> the punctuation and what you read had the same meaning. It was for
> elocutionary purposes.
> So his statement is prefectly justified, punctuation as a syntatical tool
> is a pretty recent innovation.
And the "Nestor's Cup" inscription doesn't really have punctuation in the
modern sense. It uses colons to separate words, as in "NESTOR:HAD:A:FINE:CUP",
which shows that the Greeks did not always write words together in one
continuos stream, but I didn't claim that, either.
--
Magnus Olsson (m...@df.lth.se)
Michael Burschik
> Hi,
>
> Imagine you were creating an IF interpreter like Inform, TADS, Hugo or
> whatever. How would you define objects in the source code if your
> objectives were:
If you were designing such a system, you would attempt to implement it
as a subsystem of or an addition to a general-purpose language, thus
freeing prospective programmers from learning yet another set of
syntax rules.
Of course, the most elegant general-purpose language designed to date
is scheme, so you would naturally choose it as the yardstick to
measure your own system.
Regards
Michael Burschik
Karl Filenius
> Punctuation is a pretty recent innovation. In antiquity, the Greeks
> wrote their texts in one continuous stream, often without even word
> breaks.
Said like that, the statement is wrong : Greeks used punctuation since
c.1750 BC (Phaistos Disk, written in Proto-Ionic), c.1450 BC (Linear
B tablets in Mycenaean Greek), and the 9/8th Century BC (First
alphabetic inscriptions).
ML
> Punctuation is a pretty recent innovation. In antiquity, the Greeks
> wrote their texts in one continuous stream, often without even word
> breaks.
"In antiquity"? From Homer to Byzantine, or what?
Uli Kusterer
m...@df.lth.se (Magnus Olsson) wrote:
> By the way, what do you mean with that you're "dealing with English right
> now"? Are you parsing natural English or a formal language that should
> be similar to English?
The latter.
> Of course I can't say anything about your language, but in many programming
> languages "4." does make sense - in C, for example, there's a big difference
> between the expressions "1 / 4" (which evaluates to the integer 0) and
> "1 / 4." (which evaluates to 0.25). Of course, being required to type
> "4.0" instead is no big deal.
As I mentioned in another posting, my language handles this
transparently. Though, now that I think about it ... I think it doesn't
quite ... but it will, soon.
> Yes. And Cobol actually has a statement "DECIMAL POINT IS COMMA" which
> switches the meaning of '.' and ',' when dealing with numerical data.
Heh, nice idea :-) But won't work for me, I'm afraid... :-(
John W. Kennedy
> Yes. And Cobol actually has a statement "DECIMAL POINT IS COMMA" which
> switches the meaning of '.' and ',' when dealing with numerical data.
A typically bad COBOL idea, since it can be applied only as a universal.
Uli Kusterer
Uli Kusterer <wit...@t-online.de> wrote:
> > Of course I can't say anything about your language, but in many programming
> > languages "4." does make sense - in C, for example, there's a big difference
> > between the expressions "1 / 4" (which evaluates to the integer 0) and
> > "1 / 4." (which evaluates to 0.25). Of course, being required to type
> > "4.0" instead is no big deal.
>
> As I mentioned in another posting, my language handles this
> transparently. Though, now that I think about it ... I think it doesn't
> quite ... but it will, soon.
I know following up to oneself is regarded as a sign of senility...
just wanted to mention that now it does. In the case of this language,
which is supposed to be close to English and easy to understand, small
things like having to write 4. instead of 4 to get correct division is
simply too unnatural. When writing 4 / 3, a non-programmer would never
expect to get 1...
>
> > Yes. And Cobol actually has a statement "DECIMAL POINT IS COMMA" which
> > switches the meaning of '.' and ',' when dealing with numerical data.
>
> Heh, nice idea :-) But won't work for me, I'm afraid... :-(
Let me add that the comma is already in use for lists there. And
anyway, since the entire _language_ is English, it isn't that much of a
stretch to expect from people to use the English delimiter for decimal
numbers. If I were translating the entire language into German, it'd be
different -- but then I'd have to recreate the entire language anyway...
Lewis Raszewski
>
> In article <witness-22C5D6...@news.t-online.com>,
> Uli Kusterer <wit...@t-online.de> wrote:
>
> > > Of course I can't say anything about your language, but in many programming
> > > languages "4." does make sense - in C, for example, there's a big difference
> > > between the expressions "1 / 4" (which evaluates to the integer 0) and
> > > "1 / 4." (which evaluates to 0.25). Of course, being required to type
> > > "4.0" instead is no big deal.
> >
> > As I mentioned in another posting, my language handles this
> > transparently. Though, now that I think about it ... I think it doesn't
> > quite ... but it will, soon.
>
> I know following up to oneself is regarded as a sign of senility...
> just wanted to mention that now it does. In the case of this language,
> which is supposed to be close to English and easy to understand, small
> things like having to write 4. instead of 4 to get correct division is
> simply too unnatural. When writing 4 / 3, a non-programmer would never
> expect to get 1...
>
A mathematician would.
real numbers aren't integers and don't behave the same way. Anyone who's
taken fourth grade math knows that.
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407
(12+144+20+(3*4^.5))/7)+5*11=9^2+0 -- Math Limerick
Uli Kusterer
Lewis Raszewski <rras...@hotmail.com> wrote:
> A mathematician would.
You are right there. I should have been more concise and specified that
I'm targeting prose writers or lyrical writers, not maths handbook
writers. Sorry.
> real numbers aren't integers and don't behave the same way. Anyone who's
> taken fourth grade math knows that.
Well, most people I know would call 5 / 2 = 2 to simply be an incorrect
result. They'd either expect 2.5 or 2 Remainder 1. Everything else, they
call "inaccurate". But this may be a Europe/U.S. difference...
Matthew F Funke
>
>(12+144+20+(3*4^.5))/7)+5*11=9^2+0 -- Math Limerick
Can you give this out in words, please? The only thing I can get to
work out in terms of the proper meter and rhyme are:
A dozen, its square, and a score
Plus three times the square root of four
Divided by seven
Plus five times eleven
Equals nine squared and no more.
Am I close?
--
-- With Best Regards,
Matthew Funke (m...@hopper.unh.edu)
chy...@ludens.elte.hu
> Lewis Raszewski <rras...@hotmail.com> wrote:
>>
>>(12+144+20+(3*4^.5))/7)+5*11=9^2+0 -- Math Limerick
>
> Can you give this out in words, please? The only thing I can get to
> work out in terms of the proper meter and rhyme are:
>
> A dozen, its square, and a score
> Plus three times the square root of four
> Divided by seven
> Plus five times eleven
> Equals nine squared and no more.
>
> Am I close?
Yes, very. The only thing you missed was the word "gross"
for 144. Well, that and the last five words are "and not
a bit more". Good job.
It's a very well-known limerick, plastered all over the
Net.
Chyron
--
"Beware of he who would deny you access to information, for in his
heart he dreams himself your master." -- Commissioner Pravin Lal
"People who think they have a right not to be offended are trouble."
-- Alsee
Roger Kenyon
You are. For this and other math limericks, see:
http://members.tripod.com/~Mysterium/limerix5.txt.html
Are you writing IF based on limericks?
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
L. Ross Raszewski
<m...@hypatia.unh.edu> wrote:
>Lewis Raszewski <rras...@hotmail.com> wrote:
>>
>>(12+144+20+(3*4^.5))/7)+5*11=9^2+0 -- Math Limerick
>
> Can you give this out in words, please? The only thing I can get to
>work out in terms of the proper meter and rhyme are:
>
>A dozen, its square, and a score
>Plus three times the square root of four
>Divided by seven
>Plus five times eleven
>Equals nine squared and no more.
>
> Am I close?
*Very*. The first line is actually 'A dozen, a gross, and a score'.
Otherwise, you're right on the money.
Frankly, I'm a little amazed you came as close as you did. I had to
have it explained to me the first time.
Matthew F Funke
>> Am I close?
>
>You are. For this and other math limericks, see:
>
>http://members.tripod.com/~Mysterium/limerix5.txt.html
Great URL! Thanks!
>Are you writing IF based on limericks?
Well, no -- time travel, actually. But I really like word puzzles.
(Ad Verbum was a great kick in the head. And I mean that in a *good*
way. <grin>)