[QTAC] C/C++ or other style of language?
Chris Wilson
Hi all,
Before I impliment the programming language in QTAC (The Quick Text
Adventure Creator), I would like to know which style of language you think I
should make it like. I will probably end up making it similar to C/C++, but
if you want to disagree or argue, do it now.
I could make it like C, add object oriented components in an easier to use
manner than C++, and then tweak it for QTAC, or let it adhere strictly to
the rules of ANSI C++. What should I do? Any feedback would be useful,
either post here(recommended) or mail it to me at (troja...@yahoo.com or
tro...@ihug.co.nz).
Thanks, Chris
-----------
Visit the QTAC homepage at:
http://homepages.ihug.co.nz/~trojan/qtac
note: this may not work under netscape...(I'm working on that)
Greg Ewing
Chris Wilson wrote:
>
> I will probably end up making it similar to C/C++, but
> if you want to disagree or argue, do it now.
I strongly suggest that you don't model it on anything
remotely resembling either C or C++.
Something along the style of Alan would be much nicer!
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
Chris Wilson
>> I will probably end up making it similar to C/C++, but
>> if you want to disagree or argue, do it now.
>
>I strongly suggest that you don't model it on anything
>remotely resembling either C or C++.
>
>Something along the style of Alan would be much nicer!
Can I have some reasons please?
I was thinking along the lines that people wanted for me to implement
something similar to a language that they knew.
However, if the consensus is that I don't use C/C++ syntax, then I will
create my own language, which could be better suited for IF and QTAC.
Perhaps I could implement both syntaxes?
More comments please guys!
Chris (troja...@yahoo.com, tro...@ihug.co.nz)
http://homepages.ihug.co.nz/~trojan/qtac
Eric O'Dell
On Tue, 2 Jun 1998 10:58:27 +1200, "Chris Wilson" <tro...@ihug.co.nz>
wrote:
>Before I impliment the programming language in QTAC (The Quick Text
>Adventure Creator), I would like to know which style of language you think I
>should make it like. I will probably end up making it similar to C/C++, but
>if you want to disagree or argue, do it now.
>I could make it like C, add object oriented components in an easier to use
>manner than C++, and then tweak it for QTAC, or let it adhere strictly to
>the rules of ANSI C++. What should I do?
Reimplementing C++ would, IMHO, be a monumental waste of time. Firstly
because it's overkill for a restricted problem domain like text
adventures, and secondly because C++ already exists. (OTOH, it might
be interesting if you were to implement a C++ class library that made
authoring C++ text adventures easier.)
If it were me (and someday, it will be), I'd implement a subset of C
using something like struct syntax to implement objects --- which is
what C++ does, albeit on a vastly more complex scale. And I'd worry
less about language than I would about new and innovative features.
What will QTAC offer, syntactic sugar aside, that TADS, Inform, Hugo,
and Alan don't? You need to answer this question before you implement
the language, anyway.
--Eric
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
GLYPH
Chris Wilson wrote:
> Hi all,
> Before I impliment the programming language in QTAC (The Quick Text
> Adventure Creator), I would like to know which style of language you think I
> should make it like. I will probably end up making it similar to C/C++, but
> if you want to disagree or argue, do it now.
How about making it like Inform? ;)
Actually, I think a C-ish structure is nice, because it is very uniform,
and my text editor can find bracket pairs for me. { and } is nice. Use
{ and } for everything involving blocking. Actually, I kind of like the
way Inform uses [ and ] for functions, since it's easier to see them
that way.
Don't use anything remotely resembling cobol. No "error: missing
period" for me, thanks! C is nice because EVERYTHING ends in a
semicolon. Consistency, consistency, consistency!
Basically, my preference would be Inform, but using ; in FOR loops
instead of :
- GLYPH
David A. Cornelson
Chris Wilson wrote in message <6l0ltc$nhv$1...@newsource.ihug.co.nz>...
>Hi all,
>Before I impliment the programming language in QTAC (The Quick Text
>Adventure Creator), I would like to know which style of language you think
I
>should make it like. I will probably end up making it similar to C/C++,
but
Hmm, interesting question. Well, we've had numerous (billions) of posts on
the ease of use and power of TADS, Inform, Alan, Hugo, AGT, as well as C,
C++, Basic (in all of it's forms).
The lines usually get drawn on the following (not in any order):
1) Everyone wants power. Flexibility in that you can create a simple game
without coding too much AND the ability to write sophisticated code where
needed. These are, to some degree, exclusive objectives, but maybe not.
2) Ease of use. This is subjective. Some think C++ syntax is simple,
elegant, and powerful. Some people believe it's difficult, unreadable, and
overkill. Some people believe that using english in the language (Basic,
Inform, others?) is important because many IF authors start out knowing very
little programming. Some people believe this is a waste of time because no
matter what, IF requires programming knowledge at some point.
(No flames please. I tried to paint an 'open' picture here. I'm biased a
certain direction, but I'm trying _not_ to publish my biases in this post.
Those will come later.)
3) Parsing. You're most difficult task is to create a working parser. We
have some extraordinary developer's that have created very sophisticated
parsers within their development systems. Look at TADS and Inform for more
information. Without a parser of equal stature, you will have a tough time
breaking into the IF development community.
There's more, but this is a start.
Jarb
David A. Cornelson
Chris Wilson wrote in message <6l0ltc$nhv$1...@newsource.ihug.co.nz>...
>Hi all,
>Before I impliment the programming language in QTAC (The Quick Text
>Adventure Creator), I would like to know which style of language you think
I
>should make it like. I will probably end up making it similar to C/C++,
but
Now for my _opinion_.
I have a philosophy about programming and it's generally a minority one,
especially where IF is concerned.
First, ask the question, What is the goal of the language?
My answer is: To produce an interactive fiction executable or game file.
So, the primary goal of an IF development tool should be:
- Provide an interface, language, compiler, and interpreter within which
users can effectively write interactive fiction.
So the goal is to take an author's 'ideas' and create an executable version
of those ideas.
We already have languages to produce programs. That is what C, C++, Basic,
etc are for.
A new language, specifically designed for Interactive Fiction, should be a
'level higher' than these languages. The language should contain macros and
shortcuts to 'common' things that are relative to Interactive Fiction.
Okay. So maybe a library of routines in C++ might adequately cover this
need, but here's where I break from the IF crowd.
I like words. I like to 'read' my code. When I see square brackets and
squiggly brackets everywhere, I get nervous because, to me, it's not always
_obvious_ what these are being used for.
For instance, you could use { } to define a block of code or, if it's a
specific block of code, like a Location Description, it would seem to me to
be more obvious to a novice IF programmer if the syntax were:
Begin Location
Name = livingroom
Short = "Living Room"
Long = "You are standing in the middle of a beautiful living room in
the D'Amico mansion"
East = diningroom
West = hallway
End Location
I know that the less common IF languages use a bit of this syntax, but I
don't think it's ever been taken to a 'power' extreme. If a full blown
powerful IF language had english syntax such as above, I think many more
non-programmers would get involved with writing games and as long as the
power was there, it would satisfy the hardcore developpers too.
And if it was designed well, the hardcode developers could build 'tags' of
their own to add to the development environment.
Anyway, this is just a portion of my thoughts on the subject.
Jarb
GLYPH
Chris Wilson wrote:
> However, if the consensus is that I don't use C/C++ syntax, then I will
> create my own language, which could be better suited for IF and QTAC.
> Perhaps I could implement both syntaxes?
> More comments please guys!
Ack! Well, I'll like it as long as you block stuff with {} or []. NO
If-EndIf, While-Wend, For-Next, Do-Loop!! These are hard to pick out of
the rest of the text so it's much harder to see the structure of the
program, and they're 4 words to remember instead of always }.
Consistency is paramount.
- GLYPH
Joe Mason
Chris Wilson wrote:
>
> I was thinking along the lines that people wanted for me to implement
> something similar to a language that they knew.
> create my own language, which could be better suited for IF and QTAC.
Personally, I'd like to see something different, for the simple reason
that if people want to code in a C-like language, they already have at
least three good choices. But people who DON'T like C-like syntax are
out of luck.
As for making it look like ALAN - well, I don't know what ALAN looks
like, but if you wanted to use a system that "looks like ALAN", why not
just use ALAN? (Unless there are other problems with it that I'm
unaware of.)
What's your target audience? I remember hearing some calls for a
LISP-like syntax. I don't think any recent IF language is organized
that way.
> Perhaps I could implement both syntaxes?
I wouldn't. It'd end up being too hard to maintain, and also confusing
for users. If somebody says, "How do you do x in QTAC?" they'd get a
million different answers, for both syntaxes.
Joe
Andrew Brault
>> I was thinking along the lines that people wanted for me to implement
>> something similar to a language that they knew.
>> However, if the consensus is that I don't use C/C++ syntax, then I will
>> create my own language, which could be better suited for IF and QTAC.
>
>Personally, I'd like to see something different, for the simple reason
>that if people want to code in a C-like language, they already have at
>least three good choices. But people who DON'T like C-like syntax are
>out of luck.
How about using the Smalltalk syntax? Very expressive and can be
used for both high-level and low-level things.
Bomb>>#explode
player tell: 'The ', self name, ' explodes loudly!'.
location contents do: [:each | each shatter].
self destroy.
Note that you have functions (methods) called like this:
player put: object in: container
rather than:
put_in(object, container)
Much more English-like, right?
And, there is no need for keywords (for, while, if, and so on).
They're part of the library:
"Count from 1 to 10 - integers understand #to:do:"
1 to: 10 do: [:value | value print]
"Blocks (code in []'s) understand #whileTrue:"
[self shouldContinue]
whileTrue: [self doSomething]
"True and false understand #ifTrue:ifFalse:"
self isBlocked
ifTrue: [self move]
ifFalse: [self complain]
Not to mention automatic garbage collection and easy collection
processing:
| list |
list := #(1 2 3 4 5 6). "array of numbers"
list collect: [:each | each squared].
"the result is: #(1 4 9 16 25 36)"
---
Andrew Brault <a...@tiac.net>
Eric O'Dell
>I like words. I like to 'read' my code. When I see square brackets and
>squiggly brackets everywhere, I get nervous because, to me, it's not always
>_obvious_ what these are being used for.
>
>For instance, you could use { } to define a block of code or, if it's a
>specific block of code, like a Location Description, it would seem to me to
>be more obvious to a novice IF programmer if the syntax were:
>
>Begin Location
> Name = livingroom
> Short = "Living Room"
> Long = "You are standing in the middle of a beautiful living room in
> the D'Amico mansion"
> East = diningroom
> West = hallway
>End Location
The problem is that verbose syntax in the Basic and Pascal tradition,
while easy for beginners, is a stumbling block for experienced users.
C is easier for me to read than Pascal precisely because it uses terse
symbols rather than entire English words or phrases that require
somewhat more time for the brain to parse. "The circumference of a
circle is equal to pi times the square of the radius," is certainly
more lucid to a mathematical novice, but the formal mathematical
notation is more desirable to the expert. This is especially the case
when complexity rises above a certain point --- Pascal-style
begin...end blocks nested six deep are a lot messier and hard to read,
IMHO, than C-style braces.
If we want to satisfy both novices and veterans, we might want to
consider a standard virtual machine -- something more powerful than
any of the existing models -- targeted by compilers for different
languages.
GLYPH
What if the language were to accept this:
Begin Location;
Name = livingroom;
Short = "Living Room";
Long = "You are standing in the middle of a beautiful living room in
the D'Amico mansion";
East = diningroom;
West = hallway;
End Location;
OR this:
[ Location;
Name = livingroom;
Short = "Living Room";
Long = "You are standing in the middle of a beautiful living room in
the D'Amico mansion";
East = diningroom;
West = hallway;
]
Where [ is a synonym for Begin and ] is a synonym for End*;
By the way, I strongly suggest delineating with semicolons. Consistent
that way. No confusion about spanning multiple lines, decimals, white
spaces, etc. etc. When in doubt, slap a semicolon on it. Couldn't be
simpler.
Now you just have to decide whether to use := and =, or = and ==. :)
- GLYPH
Iain Merrick
GLYPH wrote:
The syntax above seems friendly enough... especially if it's
case-insensitive; so that all of the following would be allowed:
Begin Location;
...
begin Location ;
...
BEGIN location;
...
And so on. The 'usefulness' of having, say, 'FOO' and 'foo' as distinct
variable names is outweighed by the convenience of not having to bother
with cases, or using different cases as emphasis without restriction.
Is Inform case-insensitive? I can't remember... but I have found that
'professional' case-sensitive languages like C++ are more difficult for
beginners.
Oh, and I'd vote for ':=' and '='. Seems pretty natural to read them as
'becomes equal to' and 'equals' -- whereas 'equals' and 'equals-equals'
aren't very helpful.
Iain Merrick
Andrew Brault wrote:
> How about using the Smalltalk syntax? Very expressive and can be
> used for both high-level and low-level things.
>
> Bomb>>#explode
> player tell: 'The ', self name, ' explodes loudly!'.
> location contents do: [:each | each shatter].
> self destroy.
>
> Note that you have functions (methods) called like this:
> player put: object in: container
>
> rather than:
> put_in(object, container)
>
> Much more English-like, right?
I'm not convinced... it's not obvious to me how the Smalltalk syntax
would be used in different situations, while the function-call syntax
seems very natural. But perhaps I'm just too used to C-like languages.
I did a bit of Smalltalk as part of a course once, but I never did get
the hang of it. I can see what's happening in your Bomb example, but the
positioning of the various symbols ('>>', '#', ':') just seems
arbitrary.
Another suggestion: anyone used Hypercard? The Hypertalk scripting
language is rather nice -- a bit verbose for some tastes, maybe, but
it's _very_ easy to learn.
Darin Johnson
> > How about using the Smalltalk syntax? Very expressive and can be
> > used for both high-level and low-level things.
I like it, but the syntax itself needs cleaning up (Smalltalk was
really designed with a GUI in mind, and it's syntax is much less
readable in a pure ascii environment).
Other than that, I would *love* a language where you could
do things so simply as in Smalltalk. As in the following:
> > location contents do: [:each | each shatter].
As someone else said, braces were more readable than begin-end;
but this is even more readable than both (for the expert).
Also, "mapcar" and similar functions add a lot of power.
> I'm not convinced... it's not obvious to me how the Smalltalk syntax
> would be used in different situations, while the function-call syntax
> seems very natural. But perhaps I'm just too used to C-like
> languages.
The smalltalk syntax for function calls (er, method calls) is not hard
to learn. Saying that a C/Pascal like "function(arg1,arg2)" is very
natural is only because you're used to it.
container->remove(item)
vs.
container remove: item
It's not that difficult. It also becomes much more readable when you
have multiple arguments, since you can readily tell what each argument
is for.
Item->create("jewel",10,20,true)
vs.
Item create name: "jewel" weight: 10 bulk: 20 hasLight: true
it's more verbose, but readable, and just as powerful. Terseness does
*not* add power to a language, and C is not more powerful because it
uses braces instead of begin/end, or because you can write obfuscated
code.
> get the hang of it. I can see what's happening in your Bomb example,
> but the positioning of the various symbols ('>>', '#', ':') just
> seems arbitrary.
That's because of the translation into pure text. But, you don't need
to keep the exact syntax of Smalltalk in order to use Smalltalk-like
syntax. The "#" denotes a symbol (in other languages, one might use a
string "explode", but it's less efficient if you have to compare each
character). The ":" is actually a part of the method name, and
indicates that an argument is expected (it's also part of the ":each"
parameter). The ">>" I'm vague on, but I think it's saying that
"explode" is a method of clas "Bomb" (this varies with different
varieties of smalltalk, and you're really supposed to edit code in the
GUI, not actually type that in, or even see it).
--
Darin Johnson
da...@usa.net.delete_me
Eric O'Dell
On Thu, 04 Jun 1998 13:20:39 +0100, Iain Merrick <i...@cs.york.ac.uk>
wrote:
>And so on. The 'usefulness' of having, say, 'FOO' and 'foo' as distinct
>variable names is outweighed by the convenience of not having to bother
>with cases, or using different cases as emphasis without restriction.
>
>Is Inform case-insensitive? I can't remember... but I have found that
>'professional' case-sensitive languages like C++ are more difficult for
>beginners.
As much as I like C, I've always considered case sensitivity to be
closer to a bug than a feature. Using only case to distinguish
variable names is, IMHO, dangerously unclear programming. Even if you
refrain from having 'foo' and 'FOO' in the same program, mixed case
variable names such as are common in Microsoft code, are a constant
source of typos.
>Oh, and I'd vote for ':=' and '='. Seems pretty natural to read them as
>'becomes equal to' and 'equals' -- whereas 'equals' and 'equals-equals'
>aren't very helpful.
I think TADS will let you decide which version of the comparison and
assignment operators to use, which is probably the best way to do it.
Personally, I find the Pascalesque ':=' to be more difficult to type
than C's '='.
Andrew Brault
>I like it, but the syntax itself needs cleaning up (Smalltalk was
>really designed with a GUI in mind, and it's syntax is much less
>readable in a pure ascii environment).
Actually.. modern Smalltalk only uses ASCII symbols. You're probably
thinking of the older versions that used wacky symbols such as hands
with pointing fingers for assignment, eyeballs, arrows, and various
other goodies :)
>The smalltalk syntax for function calls (er, method calls) is not hard
>to learn. Saying that a C/Pascal like "function(arg1,arg2)" is very
>natural is only because you're used to it.
Yes, the Smalltalk keyword syntax is one of the best parts.
>> get the hang of it. I can see what's happening in your Bomb example,
>> but the positioning of the various symbols ('>>', '#', ':') just
>> seems arbitrary.
>
>That's because of the translation into pure text. But, you don't need
>to keep the exact syntax of Smalltalk in order to use Smalltalk-like
>syntax. The "#" denotes a symbol (in other languages, one might use a
>string "explode", but it's less efficient if you have to compare each
>character). The ":" is actually a part of the method name, and
>indicates that an argument is expected (it's also part of the ":each"
>parameter). The ">>" I'm vague on, but I think it's saying that
>"explode" is a method of clas "Bomb" (this varies with different
>varieties of smalltalk, and you're really supposed to edit code in the
>GUI, not actually type that in, or even see it).
Yep, Smalltalk actually has very little syntax... there are things
like # for symbols and 'string' for strings and "comment" for
comments and | temp1 temp2 | for local variables. Not too much else.
The >> is an ordinary selector (method name), like + or *. It's
an abbreviation for #compiledMethodAt:, so Bomb>>#explode: would
be an expression evaluating to the method in class Bomb with the
selector #explode:. The Class>>#method notation is just a convenience
when quoting source code outside the Smalltalk IDE environment.
Anyways, it might be worth trying to take an existing Smalltalk
(probably Squeak) and implement an IF game in it.
---
Andrew Brault <a...@tiac.net>
Greg Ewing
GLYPH wrote:
>
> Ack! Well, I'll like it as long as you block stuff with {} or []. NO
> If-EndIf, While-Wend, For-Next, Do-Loop!!
As an alternative to either bracket-delimiting or keyword-delimiting
for code blocks, consider indentation.
location LivingRoom:
dirty = true
description:
"This is your living room."
if LivingRoom.dirty:
"It's very dirty."
exits:
east = Bedroom
south = Kitchen
The idea is that everything belonging to a block is
indented further to the right than the line which started
it.
This idea is taken from Python, a really neat language
which could almost be used as an IF language as it stands.
For more info see
http://www.python.org
Some functional languages such as Haskell also use
this idea.
David Given
In article <357783...@cosc.canterbury.ac.nz>,
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
[...]
>As an alternative to either bracket-delimiting or keyword-delimiting
>for code blocks, consider indentation.
>The idea is that everything belonging to a block is
>indented further to the right than the line which started
>it.
Please, no! Idented scoping like this foul! It forces the programmer to
format its code the way the language designer wants it formatted, not the
way the programmer wants to do it. For example, in C, if I have a long
conditional, I often do:
if ((a == 0) ||
(a == 1) ||
(a == 2))
wibble();
Depending on the language, this could severely confuse the compiler. Or:
do {
stuff();
// About to do more stuff
more_stuff();
// Even more stuff
even_more_stuff();
} while(1);
If the three function calls are replaced by long blocks of code, then the
reverse-indented comments make the code easier to read. Again, an indented
scoping compiler would have a fit with the equivalent.
--
+- David Given ----------------+
| Work: d...@tao.co.uk | The worst thing about censorship is
| Play: (broken, use above) | XXXXXXXXXXXXXXXXX.
+- http://wiredsoc.ml.org/~dg -+
David Given
In article <tvy4sy0...@cn1.connectnet.com>,
Darin Johnson <da...@usa.net.removethis> wrote:
[...]
>Other than that, I would *love* a language where you could
>do things so simply as in Smalltalk. As in the following:
>
>> > location contents do: [:each | each shatter].
I find that Smalltalk need religious indenting and formatting to make it
readable.
location contents do: [ :each |
each shatter
].
[...]
>Item create name: "jewel" weight: 10 bulk: 20 hasLight: true
Item create
name: 'jewel'
weight: 10
bulk: 20
hasLight: true
I've had some experience with Smalltalk (wrote an interpreter for it,
once); yes, it's a wonderful and extremely non-C-like language, and I
think it would be highly suited for writing IF (with the appropriate
libraries). So, who wants to write a Smalltalk to Z-code compiler? You
could probably get away without the self-modifying aspects of it, which
would make things easier, but you'd need some mechanism for creating
objects on-the-fly, and a garbage collector is vital.
Eric O'Dell
On Fri, 05 Jun 1998 13:18:57 GMT, dg@ (David Given) wrote:
>If the three function calls are replaced by long blocks of code, then the
>reverse-indented comments make the code easier to read. Again, an indented
>scoping compiler would have a fit with the equivalent.
The indentation of comments shouldn't make any difference to a
compiler, unless it's extraordinarily dain-bramaged, as comments
should be stripped out of the stream by the input routine, or at the
very latest by the lexical scanner, long before that nonsense gets
near the parser.
That being said, I tend to think indentation scoping is one of those
language features that came into being in order to save the compiler
writer some work. (Virtually the entire Wirth family of languages
springs to mind, but I won't get into that right now.) It's fine for
short programs, but it presents great potential for inadvertantly
placing code at the wrong scoping level.
Of course, in all fairness, the ease with which any lexical convention
is used depends upon one's familiarity with it. C's conventions seem
easy to me because I've been using them daily for years. The Delphi
code I've been struggling over lately is hideously unclear to me
because I am not yet familiar with it. Eventually, I expect it will
become fairly automatic (even if I'm still in awe of its awkward and
boneheaded syntax).
Anyway, provided the rest of the language's syntax is well suited
(i.e., LALR(1)) to the common compiler tools, writing a preprocessor
to handle whatever block delimiter style you might prefer shouldn't be
a problem.
Darin Johnson
er...@gadgetguru.com (Eric O'Dell) writes:
> I think TADS will let you decide which version of the comparison and
> assignment operators to use, which is probably the best way to do it.
> Personally, I find the Pascalesque ':=' to be more difficult to type
> than C's '='.
If I were to ever get around to designing my perfect language,
I would have ":=" and "==". Then no more confusion.
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
Andrew Brault <a...@tiac.net> writes:
> Actually.. modern Smalltalk only uses ASCII symbols. You're probably
> thinking of the older versions that used wacky symbols such as hands
> with pointing fingers for assignment, eyeballs, arrows, and various
> other goodies :)
No, I'm thinking of how the code is displayed, versus how it appears
when you store to a file. Ie, you edit Smalltalk code in the class
browser, and you see the method name bold-faced, etc. In the text
file, you see lots of "!"'s that don't appear in the browser.
> The >> is an ordinary selector (method name), like + or *. It's
> an abbreviation for #compiledMethodAt:, so Bomb>>#explode: would
> be an expression evaluating to the method in class Bomb with the
> selector #explode:. The Class>>#method notation is just a convenience
> when quoting source code outside the Smalltalk IDE environment.
That's what I meant above. The class browser does not show these
things, they only appear when you fileOut (serialize )the class to a
file.
Different Smalltalk implementations also do these things differently
(ie, Smalltalk-80 vs. Smalltalk/V vs. GNU Smalltalk vs. Self, etc).
I've seen at least three ways, only one of which used the ">>".
--
Darin Johnson
da...@usa.net.delete_me
John Francis
>>
>> Ack! Well, I'll like it as long as you block stuff with {} or []. NO
>> If-EndIf, While-Wend, For-Next, Do-Loop!!
>
>for code blocks, consider indentation.
>
> dirty = true
> description:
> "This is your living room."
> if LivingRoom.dirty:
> "It's very dirty."
> exits:
> east = Bedroom
> south = Kitchen
>
>indented further to the right than the line which started
>it.
Aargh! No!. White space is to make things readable by humans.
Signifiant white space to make things easier for machines is a *bad idea*
White space that depends on just how many spaces there are is even worse.
I can still remember just how many hours I wasted because I'd only got
five spaces at the beginning of a line of FORTRAN instead of six . . .
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
GLYPH
Greg Ewing wrote:
> As an alternative to either bracket-delimiting or keyword-delimiting
> for code blocks, consider indentation.
Ack! Whitespaces and columns affecting code! Cobol flashback!
GLYPH throws up on his shoes.
Sorry about that. No offence, but I put whitespace dependancy in the
same pile of bugs as case sensitivity and such.
Indentation is wonderful for making the code more readable, and should
be encouraged and practised as much as possible, but it shouldn't affect
compilation. Too much room for making errors typing and such.
I still like my idea of making BEGIN and [ synonyms, and END*; and ]
synonyms, so that the novice can use english and the expert can type
less.
- GLYPH
Matthew Amster-Burton
On Fri, 5 Jun 1998, GLYPH wrote:
> GLYPH throws up on his shoes.
>
> Sorry about that. No offence, but I put whitespace dependancy in the
> same pile of bugs as case sensitivity and such.
Case sensitivity? Seriously? I can think of plenty of things I'd change
about C, C++, Perl, or TADS, but case sensitivity isn't one of them.
As for whitespace dependency, take a look at Python before you decide it's
pure evil. Then again, make drives me nuts sometimes.
Matthew
Eric O'Dell
On Fri, 05 Jun 1998 19:12:53 GMT, Darin Johnson
<da...@usa.net.removethis> wrote:
>If I were to ever get around to designing my perfect language,
>I would have ":=" and "==". Then no more confusion.
How do you figure? Given := and ==, and being told that one of them
was the equality operator and the other was the assignment operator,
there is no obvious way to know which is which. Personally, I would
guess that := is assignment and == is equality, but that's already
because I know C and Pascal. The symbols of themselves would not be
self-explanatory to a beginner. Language in general is not
self-explanatory, unless by "self-explanatory" you mean "recursively
defined", which it is.
That being said...
The usage of "=" as the assignment operator comes from the popular
misunderstanding of its use in mathematics. When we see the following
in a high school algebra textbook...
x = 5
...it is convenient to think of this as an assignment (copying of the
value) 5 to the variable x, when strictly speaking, the equation is a
statement of identity, not a description of an action. When we write
the same thing in C (provided we append a semicolon), we are copying
the integer value 5 into an address we are referring to as "x", as a
convenient shorthand. When we write
x == 5;
in C, we are instructing the compiler to load the value at address x
into one register, the number five into another, and to perform a
boolean comparison. If address x contains the integer value 5, yet
another register is set to 1, else to 0, and the value is (depending
on the compiler) then copied to an address in the stack frame reserved
for the temporary results of expression evaluations. What happens to
it after that depends, but the point is that our customarily sloppy,
non-technical way of thinking about assignment and comparison creates
some confusion when it runs up against what's actually happening in
the computer.
Personally, in my ideal language, the fact that assignment has exactly
squat to do with the equality comparison would be reflected in the use
of <- as the assignment operator, e.g.
x <- 5;
leaving "=" free to act as the equality comparison operator, that is,
as an assertion whose boolean truth value is placed on the stack. Or,
alternatively, the comparison operators could be alphabetic digraphs
like they are in some languages (Perl and Pascal, fr'example)...
if(x eq 5)...
and "=" might be relegated to the relatively arcane role of creating
variable aliases --- a dynamic version of C++'s references -- which
would actually make sense in context of the English word "equals",
i.e., a statement of identity.
And as ranting about operator syntax involves geeking out further than
I'm comfortable with at half past midnight, I'll just quit now... ;-)
Paul Francis Gilbert
Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
>GLYPH wrote:
>>
>> Ack! Well, I'll like it as long as you block stuff with {} or []. NO
>> If-EndIf, While-Wend, For-Next, Do-Loop!!
Ack! Frankly, I'll like it as long as you *DONT* use those pathetic brace
symbols, which are really unintuative. Frankly, I get enough of them in
C/++/Java to stand them in another language. ;-)
>As an alternative to either bracket-delimiting or keyword-delimiting
>for code blocks, consider indentation.
>location LivingRoom:
> dirty = true
> description:
> "This is your living room."
> if LivingRoom.dirty:
> "It's very dirty."
> exits:
> east = Bedroom
> south = Kitchen
>The idea is that everything belonging to a block is
>indented further to the right than the line which started
>it.
>This idea is taken from Python, a really neat language
>which could almost be used as an IF language as it stands.
>For more info see
I've found that a language which depends on the way something is formatted
is always less clear and harder to compile in the long run. A good exmaple of
something that requires indenting is the Makefile paradigm for compiling
programs... it's output requires you to use a Tab, which I've always though
to be horribly unclear.
> http://www.python.org
>
>Some functional languages such as Haskell also use
>this idea.
>--
>Greg Ewing, Computer Science Dept, | The address below is not spam-
>University of Canterbury, | protected, so as not to waste
>Christchurch, New Zealand | the time of Guido van Rossum.
>gr...@cosc.canterbury.ac.nz
--
Paul Gilbert | p...@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 5, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
Chris Wilson
I like the idea of '<-'. I may impliment it as one of the options in QTAC.
What do you think?
Chris
http://homepages.ihug.co.nz/~trojan/qtac
>[...]
Chris Wilson
I agree with you entirely, and it is my opinion that counts :)
Thanks for all your support of QTAC, guys,
Chris
http://homepages.ihug.co.nz/~trojan/qtac
okbl...@usa.net
In article <87u3605...@ajb.i-have-a-misconfigured-system-so-shoot-me>,
My GOD! I LOVE Smalltalk syntax!
(Sorry. I seldom get to make an outburst like that in an area where people
will understand what I'm talking about.)
>
> Yep, Smalltalk actually has very little syntax... there are things
> like # for symbols and 'string' for strings and "comment" for
> comments and | temp1 temp2 | for local variables. Not too much else.
> The >> is an ordinary selector (method name), like + or *. It's
> an abbreviation for #compiledMethodAt:, so Bomb>>#explode: would
> be an expression evaluating to the method in class Bomb with the
> selector #explode:. The Class>>#method notation is just a convenience
> when quoting source code outside the Smalltalk IDE environment.
>
But, inside the IDE, wouldn't it just be:
Bomb explode
?
> Anyways, it might be worth trying to take an existing Smalltalk
> (probably Squeak) and implement an IF game in it.
>
Aren't there two (small) Smalltalk around? One is Win95 only and the other
isn't?
Actually, you could make the Smalltalk environment an adventure game itself:
player go: west
player throw: axe at: dwarf
Make "player" the implicit object and you have:
go: north
kill: dragon with: hands
To me, this is a natural syntax for AGs.
#subject #action: #directobject #prep: #indirectobject
:-)
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
okbl...@usa.net
In article <35784F...@hotmail.com>,
GLYPH <graham...@hotmail.com> wrote:
>
> I still like my idea of making BEGIN and [ synonyms, and END*; and ]
> synonyms, so that the novice can use english and the expert can type
> less.
>
one way to express anything. (None even approach this ideal, but to flagrantly
fly in the face of it may risk censure by the Authorities.)
For myself, I despise things that are done solely to save typing. You are a
programmer (or a writer): Learn to use your tools (including the keyboard).
Now, before someone tangents off of this (look, Ma! I invented a verb!), let
me point out that a lot of things which save a lot of typing also save in a
lot of other ways. In other words, please don't say that OO saves typing and
therefore I'm nuts. I know OO saves typing, but it does so as a side-effect
of reducing code maintenance.
Whereas someone said it took their brain longer to "parse" the word "BEGIN"
rather than the symbol "{", I find myself more likely to have to pay closer
attention to =notice= the narrow "{" versus the in-your-face "BEGIN",
particularly if I'm in a GUI environment. But then, I prefer to use my mind
for figuring stuff out. My brain is more or less an inert lump of meat
without it.
David Glasser
(crossposted from rec.arts.nit-piction)
Eric O'Dell <er...@gadgetguru.com> wrote:
> Or,
> alternatively, the comparison operators could be alphabetic digraphs
> like they are in some languages (Perl and Pascal, fr'example)...
>
> if(x eq 5)...
Actually, Perl uses eq for strings, and still uses == for other types of
variables.
--David Glasser
gla...@NOSPAMuscom.com | dgla...@NOSPAMfcs.pvt.k12.pa.us
http://onramp.uscom.com/~glasser | http://www.geocities.com/SoHo/6028
DGlasser @ ifMUD : fovea.retina.net:4000 (webpage fovea.retina.net:4001)
Interactive Fiction! MST3K! David Eddings! Macintosh!
David Glasser
Eric O'Dell <er...@gadgetguru.com> wrote:
> On Thu, 04 Jun 1998 13:20:39 +0100, Iain Merrick <i...@cs.york.ac.uk>
> wrote:
>
> >And so on. The 'usefulness' of having, say, 'FOO' and 'foo' as distinct
> >variable names is outweighed by the convenience of not having to bother
> >with cases, or using different cases as emphasis without restriction.
> >
> >Is Inform case-insensitive? I can't remember... but I have found that
> >'professional' case-sensitive languages like C++ are more difficult for
> >beginners.
>
> As much as I like C, I've always considered case sensitivity to be
> closer to a bug than a feature. Using only case to distinguish
> variable names is, IMHO, dangerously unclear programming. Even if you
> refrain from having 'foo' and 'FOO' in the same program, mixed case
> variable names such as are common in Microsoft code, are a constant
> source of typos.
One thing good about case-sensitivity is that you can make guidelines,
like "All #defines in UPPER_CASE" and then any non-uppercase identifier
isn't taken by a #define.
Erik Max Francis
David Glasser wrote:
> One thing good about case-sensitivity is that you can make guidelines,
> like "All #defines in UPPER_CASE" and then any non-uppercase
> identifier
> isn't taken by a #define.
Or:
All objects with global scope or public access are first-letter
capitalized, and all objects with local scope or private/protected
access are first-letter lowercase.
--
Erik Max Francis, &tSftDotIotE / mailto:m...@alcyone.com
Alcyone Systems / http://www.alcyone.com/max/
San Jose, California, United States / icbm:+37.20.07/-121.53.38
\
She glanced at her watch / . . . It was 9:23.
/ James Clavell
Darin Johnson
er...@gadgetguru.com (Eric O'Dell) writes:
> >If I were to ever get around to designing my perfect language,
> >I would have ":=" and "==". Then no more confusion.
>
> How do you figure? Given := and ==, and being told that one of them
> was the equality operator and the other was the assignment operator,
> there is no obvious way to know which is which.
I meant no more confusion in "if" statements and such. You still have
to know which is which. The problem solved is the common "C" problem
of saying "if (a=b)" where you meant "if (a==b)"; and not noticing the
difference when reading through the code, because they look alike.
It also solves problems such as TADS using ":=" and "=", and novices
from C thinking that "=" means assignment.
Knowing which is which is a trivial problem. (I hope. Does anyone
ever get confused between ":=" and "=" in Pascal, or "=" and "==" in
C?) The beginner will have to learn them, just as in *any* language.
The hope is to reduce errors and confusion.
> That being said...
>
> The usage of "=" as the assignment operator comes from the popular
> misunderstanding of its use in mathematics. When we see the following
> in a high school algebra textbook...
>
> x = 5
>
> ...it is convenient to think of this as an assignment
In some computer languages, this is vague. In particular, functional
programming languages can say things like:
fact(x) = x*(x-1), x>1
fact(1) = 1
Here, the "=" does not mean assignment. One can even do things like:
fib(x) = a+b, x > 1
where a = fib(x-1)
b = fib(x-1)
I'm free and loose with syntax here, but you should be able to get the
idea that the notion of "assignment" isn't necessary.
--
Darin Johnson
da...@usa.net.delete_me
Eric O'Dell
On Sat, 6 Jun 1998 22:41:52 -0500, gla...@NOSPAMuscom.com (David
Glasser) wrote:
>> Or,
>> alternatively, the comparison operators could be alphabetic digraphs
>> like they are in some languages (Perl and Pascal, fr'example)...
>>
>> if(x eq 5)...
>
>Actually, Perl uses eq for strings, and still uses == for other types of
>variables.
Actually, Pascal has more than one equality operator, too, but I was
presenting an example, not a language specification. :)
But speaking of operators more generally (and tangentially of operator
overloading), mightn't it be interesting to provided the programmer
with the ability to define operators from scratch? To all intents and
purposes this could be syntactically little different from operator
overloading in C++, except that one need not be restricted to a
predefined set of operators. Provided the urge to abuse the ability
was resisted, the grammar would be familiar to IF player/programmers,
especially if one was allowed to define trinary operators and
operators with "pronouns", e.g.
if(magician is_present) put rabbit into tophat;
...where "is_present" is a binary postfix operator that returns true
if the operand is in the current room, and "put ... into" is a binary
operator that adds the first operand to the second operand's contents
list.
Eric O'Dell
On Sat, 06 Jun 1998 23:02:36 GMT, okbl...@usa.net wrote:
>Whereas someone said it took their brain longer to "parse" the word "BEGIN"
>rather than the symbol "{", I find myself more likely to have to pay closer
>attention to =notice= the narrow "{" versus the in-your-face "BEGIN",
>particularly if I'm in a GUI environment. But then, I prefer to use my mind
>for figuring stuff out. My brain is more or less an inert lump of meat
>without it.
BEGIN_PARAGRAPH That QUOTE someone QUOTE being me COMMA I feel obliged
to clarify my earlier statment PERIOD What I meant was that I thought
that Pascal APOSTROPHE s use of QUOTE BEGIN QUOTE and QUOTE END QUOTE
tags instead of punctuation marks tended to obscure the keywords and
identifiers by cluttering up the text PERIOD It is perhaps because of
this that we use punctuation marks in text instead of special words
COMMA and not because of mental laziness PERIOD Up until the age of
the printed word COMMA
alltextwasruntogetherwithoutspacesbetweenwordsbecausepaperwas
costlyandpeoplewereperfectlycapableofusingtheirbrainstoparsethetext
PERIOD END_PARAGRAPH
Personally, I prefer to use my brain, feeble though it may be, to
focus on the higher-level aspects of programming and leave the parsing
to the machine. :)
Andrew Brault
>> selector #explode:. The Class>>#method notation is just a convenience
>> when quoting source code outside the Smalltalk IDE environment.
>>
>
>But, inside the IDE, wouldn't it just be:
>
>Bomb explode
>
>?
Well, the Bomb class would be a selection in a list box, and the
actual source code in the GUI would look like this:
explode
[...whatever lines of code...]
The first line (explode) is part of the syntax... the first
word (or words, in some cases) in a piece of source code is
taken to be the name of the method.
As another poster mentioned, if you "filed out" the source
code (i.e., saved it to an ASCII format text file) you would
get something like this:
!Bomb methodsFor: 'exploding'!
explode
[...code...]
! !
That's where the comment about lots of extra !'s came from...
in the file-out format, !'s are used to separate pieces of the
code. (the 'exploding' part above is an optional "method
category" which you can assign to help organize things.)
>Aren't there two (small) Smalltalk around? One is Win95 only and the other
>isn't?
There are quite a few, nowadays... prices ranging from free to
$100 or so to $4000 or more (really!). If anyone's interested
in trying out the language here's a quick (and incomplete) list
off the top of my head:
Squeak Smalltalk:
Free, very strange system, under constant development.
It's being written by a Linux-like community headed by some of
the original Smalltalk guys. Runs on many OS's (including Win95,
Mac, Acorn, Unix, MS-DOS, some PDAs)
http://squeak.cs.uiuc.edu
Dolphin Smalltalk:
This is my favorite. Free, but requires a licence to
distribute commercial products (around $150). Win95 only, but
has some great technical advantages over the competition.
http://www.object-arts.com
Smalltalk MT:
Commercial, but has a free demo version. I don't
remember the price. Win95 only. It has a very lean class
library, and a very small image footprint. The speed is
about the same, and sometimes faster, than optimized C++.
This is great if you are a C developer who wants to build
software faster.
http://www.objectconnect.com
VisualWorks:
This is the mother of all Smalltalks, with a lineage
going all the way back to the original Smalltalk-80. Very
expensive commercial software (in the thousands of dollars)
but they recently released a noncommercial version for free.
Runs on many OS's.
http://www.objectshare.com
VisualAge Smalltalk:
Another major, expensive Smalltalk. I haven't used
it, but others have said good things about it.
Not sure of the URL, but try http://www.ibm.com
>Actually, you could make the Smalltalk environment an adventure game itself:
>
>player go: west
>player throw: axe at: dwarf
>
>Make "player" the implicit object and you have:
>
>go: north
>kill: dragon with: hands
>
>To me, this is a natural syntax for AGs.
Yes indeed!
---
Andrew Brault <a...@tiac.net>
Andrew Brault
>But speaking of operators more generally (and tangentially of operator
>overloading), mightn't it be interesting to provided the programmer
>with the ability to define operators from scratch? To all intents and
>purposes this could be syntactically little different from operator
>overloading in C++, except that one need not be restricted to a
>predefined set of operators. Provided the urge to abuse the ability
>was resisted, the grammar would be familiar to IF player/programmers,
>especially if one was allowed to define trinary operators and
>operators with "pronouns", e.g.
>
> if(magician is_present) put rabbit into tophat;
I can't resist another plug for Smalltalk here... in Smalltalk
you can define new operators by just making new methods whose
names are the operator... for example, if I wanted to override
the = operator for some class, I would write
= anotherObject
[..some code to decide if self and anotherObject are equal..]
The = here is actually the name of the method. Smalltalk sees that
the name is composed of operator characters and implicitly assumes
that the method has one argument. (actually, it has two arguments,
since every method implicitly has "self" (the left hand side) as
an argument.)
But Smalltalk doesn't stop there. You are not limited to the
traditional +, -, *, / operators. In fact, you can create your
own operators by tacking together one or more "special" characters,
taken from the set: @%&*-+=~,<>?/ (and probably a few more).
So, you could define a "put into" operator, say => as follows:
=> container
self location: container.
container add: self.
Then you could write:
rabbit => hat.
> if(magician is_present) put rabbit into tophat;
>
>...where "is_present" is a binary postfix operator that returns true
>if the operand is in the current room, and "put ... into" is a binary
>operator that adds the first operand to the second operand's contents
>list.
Of course, you could write is_present as a simple no-argument
method in Smalltalk:
isPresent
"Note: ^ is the Smalltalk return operator"
^self location == player location.
Then, putting it all together:
magician isPresent ifTrue: [rabbit => tophat].
(ifTrue: is Smalltalk's version of the if() statement.)
---
Andrew Brault <a...@tiac.net>
Barry Smith
> One thing good about case-sensitivity is that you can make guidelines,
> like "All #defines in UPPER_CASE" and then any non-uppercase identifier
> isn't taken by a #define.
> --David Glasser
I don't think the point is to completely eliminate the upper case,
just to have it so that #define, #DEFINE or #DeFiNe are all the same
to the compiler.
--
Barry Smith
resi...@zetnet.co.uk
Erik Max Francis
Barry Smith wrote:
> > One thing good about case-sensitivity is that you can make
> > guidelines,
> > like "All #defines in UPPER_CASE" and then any non-uppercase
> > identifier
> > isn't taken by a #define.
>
> I don't think the point is to completely eliminate the upper case,
> just to have it so that #define, #DEFINE or #DeFiNe are all the same
> to the compiler.
If the compiler is case insensitive, then such guidelines are
meaningless.
Frank Filz
In article <357d2d4a.3341347@news>, Eric O'Dell (er...@gadgetguru.com) says...
> ....It is perhaps because of this that we use punctuation marks in text
> instead of special words COMMA and not because of mental laziness PERIOD Up
> until the age of the printed word COMMA
Of course in certain contexts, where it is important to not miss punctuation,
we do use words (inparticular I'm thinking of telegrams use of "stop" to end a
sentance - though I think that also is a case of not having a code for the
period).
Someone else commented about syntax making spaces significant. In SNOBOL,
the string concatenation operator was a blank (though more technically "no
character at all", the blank being required anyways to delimit the two
operands).
I personally am ambivalent on begin/end vs {}. Proper indentation and
formatting of code make the braces fairly obvious, and there are editors which
show you which block of code is encompassed by a set of braces, but I also
like the clarity of begin/end. And while some people are even more against
different begin/end pairs for if/for/while etc, I also see a lot of code like
if (xyz)
{
....
} /* end if */
(As you can see above, for highlighting purposes, I tend to prefer the
opening brace on a line by itself)
Frank
Frank Filz
In article <357b2a43.2566849@news>, Eric O'Dell (er...@gadgetguru.com) says...
>
>On Sat, 6 Jun 1998 22:41:52 -0500, gla...@NOSPAMuscom.com (David
>Glasser) wrote:
>
>>> Or,
>>> alternatively, the comparison operators could be alphabetic digraphs
>>> like they are in some languages (Perl and Pascal, fr'example)...
>>>
>>> if(x eq 5)...
>>
>>Actually, Perl uses eq for strings, and still uses == for other types of
>>variables.
>
>Actually, Pascal has more than one equality operator, too, but I was
>presenting an example, not a language specification. :)
But Pascal doesn't have "eq"... (it does spell out and/or/not/mod though,
which I think is good, also using types to determine whether you mean logical
or bitwise for boolean operators so no more confusion of "&" vs "&&".
For a real mind bender on equality operators is Icon, where
= tests numerical equality
== tests string equality (not pointer equality)
=== tests equality of anything else
=== functions basically the same as C's ==, where things which are really
pointers have their addresses compared, not their values (Icon doesn't expose
pointers to the programmer). The first two operators do type conversion if
possible (so "5" = 5 is true (as is "5" == 5, but "+5" == 5 is false where
"+5" = 5 is still true)).
Frank
Greg Ewing
John Francis wrote:
>
> Signifiant white space to make things easier for machines is a *bad idea*
You've got it backwards. It's curly braces and begin-ends
that were invented to make things easier for machines.
Code with delimiters but without indentation is readable
by machines but unreadable by humans.
Code with indentation but without delimiters is readable
by humans. It can also be made readable by machines.
So why clutter it up with extra symbology?
> I can still remember just how many hours I wasted because I'd only got
> five spaces at the beginning of a line of FORTRAN instead of six . . .
That's bad because it's impossible to tell whether
there are 5 or 6 spaces just by looking.
What I'm suggesting doesn't depend on the absolute
number of spaces - only on how things line up in
relation to each other. If it looks right, then
it is right.
Take a look at some Python code some time and think
about whether you would really find it any easier to
follow if it had {} or begin-end added everywhere.
Matt Kimball
Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
: Code with indentation but without delimiters is readable
: by humans. It can also be made readable by machines.
: So why clutter it up with extra symbology?
I'll shout a loud "me too" about this. The
indentation-as-block-structure is one of the coolest things about
Python, and something I'd definitely emulate if designing a new
language. Comparing it to FORTRAN is missing the point.
(OTOH, reference counting without true GC is the one thing about
Python that just makes me say, "Why not do it right?").
--
Matt Kimball
mkim...@xmission.com
Mary K. Kuhner
In article <6lfmqu$2au$1...@news.xmission.com>,
Matt Kimball <mkim...@xmission.com> wrote:
>Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
>: Code with indentation but without delimiters is readable
>: by humans. It can also be made readable by machines.
>: So why clutter it up with extra symbology?
>I'll shout a loud "me too" about this. The
>indentation-as-block-structure is one of the coolest things about
>Python, and something I'd definitely emulate if designing a new
>language. Comparing it to FORTRAN is missing the point.
While I don't know Python, I'd wonder how well the technique
scales up. Indentation is wonderful for loops nested one
or two levels deep. Nest ten levels deep, as my production
code does now and again, and you run off the end of the line.
Long lines sound like they'd be a pest in general. And some
kinds of if/then/else constructions just don't want to be
indented in the normal fashion (as when you're using if/then/else
to fake a switch statement, but would prefer to indent it more
like a switch statement).
It strikes me that a long program might easily lose the
human readability.
On the other hand, I'd love to have a C compiler with a
"check indentation" option so that it would complain about
statements whose indentation didn't match their sense.
Mary Kuhner mkku...@genetics.washington.edu
Francis Irving
On Sat, 06 Jun 1998 05:28:09 GMT, er...@gadgetguru.com (Eric O'Dell)
wrote:
>How do you figure? Given := and ==, and being told that one of them
>was the equality operator and the other was the assignment operator,
>there is no obvious way to know which is which.
There is a very logical way of knowing, however.
"==" is equality because the symbol is symmetrical, and the operation
is symmetrical (i.e. commutative, a==b <==> b==a).
":=" is assignment because the symbol is asymetrical, as is the
operation.
Francis.
Home: fra...@pobox.co.uk Web: www.meta.demon.co.uk
Iain Merrick
Eric O'Dell wrote:
> On Fri, 05 Jun 1998 13:18:57 GMT, dg@ (David Given) wrote:
>
> >If the three function calls are replaced by long blocks of code, then the
> >reverse-indented comments make the code easier to read. Again, an indented
> >scoping compiler would have a fit with the equivalent.
>
> The indentation of comments shouldn't make any difference to a
> compiler, unless it's extraordinarily dain-bramaged, as comments
> should be stripped out of the stream by the input routine, or at the
> very latest by the lexical scanner, long before that nonsense gets
> near the parser.
>
> That being said, I tend to think indentation scoping is one of those
> language features that came into being in order to save the compiler
> writer some work. (Virtually the entire Wirth family of languages
> springs to mind, but I won't get into that right now.) It's fine for
> short programs, but it presents great potential for inadvertantly
> placing code at the wrong scoping level.
The language Haskell (www.haskell.org) has a 'layout rule' which
implements this in a pretty consistent and usable way. You can write
_very_ terse but readable code in Haskell; this is mostly due to the
fact that it's a very powerful functional language, but the layout rule
undoubtedly helps.
When you come to actually use it, it works very nicely about 99% of the
time; for the other 1% you'll get a more-or-less misleading error
message, depending on how friendly the compiler is.
[...]
> Anyway, provided the rest of the language's syntax is well suited
> (i.e., LALR(1)) to the common compiler tools, writing a preprocessor
> to handle whatever block delimiter style you might prefer shouldn't be
> a problem.
The Haskell language itself is defined with braces, semicolons and so on
as delimiters; the layout rule describes how to insert these symbols if
they're missing, based on the indentation of the program. For more
information, have a look at:
http://haskell.systemsz.cs.yale.edu/onlinereport/intro.html#sect1.5
(AFAIK this feature isn't original with Haskell - it probably comes from
earlier functional languages, possibly Miranda.)
--
Iain Merrick
Iain Merrick
David Glasser wrote:
> Eric O'Dell <er...@gadgetguru.com> wrote:
>
> > On Thu, 04 Jun 1998 13:20:39 +0100, Iain Merrick <i...@cs.york.ac.uk>
> > wrote:
> >
> > >And so on. The 'usefulness' of having, say, 'FOO' and 'foo' as distinct
> > >variable names is outweighed by the convenience of not having to bother
> > >with cases, or using different cases as emphasis without restriction.
> > >
> > >Is Inform case-insensitive? I can't remember... but I have found that
> > >'professional' case-sensitive languages like C++ are more difficult for
> > >beginners.
> >
> > As much as I like C, I've always considered case sensitivity to be
> > closer to a bug than a feature. Using only case to distinguish
> > variable names is, IMHO, dangerously unclear programming. Even if you
> > refrain from having 'foo' and 'FOO' in the same program, mixed case
> > variable names such as are common in Microsoft code, are a constant
> > source of typos.
>
> One thing good about case-sensitivity is that you can make guidelines,
> like "All #defines in UPPER_CASE" and then any non-uppercase identifier
> isn't taken by a #define.
You can be case-preserving without being case-sensitive. The Mac file
system is an excellent example of this. UNIX is generally
case-sensitive, while worst of all DOS (dunno about '95 or NT) is
case-insensitive and _not_ case preserving (all UPPERCASE! Argh!)
The only situation I've encountered where upper-case #define's are
_really_ useful is in writing compilers: "for", "repeat", "let" and so
on might be reserved keywords, so you use "FOR", "REPEAT" and "LET" for
your tokens. But it's not too hard to work round this if need be - say,
"token_FOR", "token_REPEAT" and "token_LET".
I tell a lie... I've found it useful in C++ to have a class called, say,
"Window", and use "window" as a variable name. But again you could use
"w", "myWindow", "the_window" or whatever.
--
Iain Merrick
Iain Merrick
Francis Irving wrote:
> On Sat, 06 Jun 1998 05:28:09 GMT, er...@gadgetguru.com (Eric O'Dell)
> wrote:
>
> >How do you figure? Given := and ==, and being told that one of them
> >was the equality operator and the other was the assignment operator,
> >there is no obvious way to know which is which.
>
> There is a very logical way of knowing, however.
>
> "==" is equality because the symbol is symmetrical, and the operation
> is symmetrical (i.e. commutative, a==b <==> b==a).
>
> ":=" is assignment because the symbol is asymetrical, as is the
> operation.
That makes sense. My rule-of-thumb is much more primitive:
":=" is pronounced 'becomes-equal'.
"==" is pronounced 'equals'.
Hey, it works even better when you use "==" instead of "="; it's as if
'equals' is plural! Neat.
I dislike "<-" for assignment for the trivial aesthetic reason that my
eyes alway want to reverse direction when I'm reading from left to right
and they hit a little left-facing arrow.
--
Iain Merrick
David A. Cornelson
Iain Merrick wrote in message <357BD6...@cs.york.ac.uk>...
>Francis Irving wrote:
>
>> On Sat, 06 Jun 1998 05:28:09 GMT, er...@gadgetguru.com (Eric O'Dell)
>> wrote:
>
>":=" is pronounced 'becomes-equal'.
>"==" is pronounced 'equals'.
>
I have to comment on this. This is one of the things I believe forms of the
Basic language were smarter and better than all of the languages discussed
so far on the equal sign.
Basic uses = for all comparisons and assignments. It's the context that
matters, NOT the damned symbol.
MO
Jarb
Den of Iniquity
On Sat, 6 Jun 1998 okbl...@usa.net wrote:
>Now, before someone tangents off of this (look, Ma! I invented a verb!)
Argh! Don't verb nouns!
Iain Merrick
David A. Cornelson wrote:
> Iain Merrick wrote in message <357BD6...@cs.york.ac.uk>...
>
> >":=" is pronounced 'becomes-equal'.
> >"==" is pronounced 'equals'.
>
> I have to comment on this. This is one of the things I believe forms of the
> Basic language were smarter and better than all of the languages discussed
> so far on the equal sign.
>
> Basic uses = for all comparisons and assignments. It's the context that
> matters, NOT the damned symbol.
There's a tidied-up version of Basic called Comal which is still used in
schools in Scotland. For compatibility with Basic, it would accept '='
for assignment, but immediately replace it with ':='.
I think this is definitely a Good Thing. It enhances readability, and
helps beginning programmers to see the difference between the two kinds
of '='.
Allen Garvin
In article <87af7pz...@ajb.i-have-a-misconfigured-system-so-shoot-me>,
Andrew Brault <a...@tiac.net> wrote:
There are quite a few, nowadays... prices ranging from free to $100
or so to $4000 or more (really!). If anyone's interested in trying
out the language here's a quick (and incomplete) list off the top
of my head:
There's also the free GNU SmallTalk, somewhat buggy and also a memory
hog. It introduced me to smalltalk, which really gave me a clear
understanding of Object Orientedness that I didn't get from C++.
Runs under several OS's.
--
Allen Garvin kisses are a better fate
--------------------------------------------- than wisdom
eare...@faeryland.tamu-commerce.edu
http://faeryland.tamu-commerce.edu/~earendil e e cummings
Allen Garvin
In article <6lb9a5$b3p$1...@newsource.ihug.co.nz>,
Chris Wilson <tro...@ihug.co.nz> wrote:
I like the idea of '<-'. I may impliment it as one of the options
in QTAC. What do you think?
It's nice to allow assignments in expressions, but with this you have a problem
distinguishing assignment from less than the negative of the rvalue. Maybe
<--, provided you don't have C-like minus-minus's. Hm, how about <---- *8-)
David Given
In article <tvyn2br...@cn1.connectnet.com>,>> I think TADS will let you decide which version of the comparison and
>> assignment operators to use, which is probably the best way to do it.
>> Personally, I find the Pascalesque ':=' to be more difficult to type
>> than C's '='.
>
>If I were to ever get around to designing my perfect language,
>I would have ":=" and "==". Then no more confusion.
Hey! I *did* design my perfect language, and I picked := and == for
exactly the same reason. = by itself is not a valid token. Great minds,
eh?
--
+- David Given ----------------+
| Work: d...@tao.co.uk | FNORD
| Play: (broken, use above) |
+- http://wiredsoc.ml.org/~dg -+
GLEEMOTH
Den complains:
>On Sat, 6 Jun 1998 okbl...@usa.net wrote:
>>Now, before someone tangents off of this (look, Ma! I invented a verb!)
>
>Argh! Don't verb nouns!
Shay Caron (Shay_...@letterbox.com
-or-
glee...@aol.com)
Dylan O'Donnell
glee...@aol.com (GLEEMOTH) writes:
> Den complains:
> >On Sat, 6 Jun 1998 okbl...@usa.net wrote:
> >>Now, before someone tangents off of this (look, Ma! I invented a verb!)
> >
> >Argh! Don't verb nouns!
> Verbing weirds language. (3 points)
_Three_ whole points for a Calvin and Hobbes quote? Inflation's really
hit hard...
--
Dylan O'Donnell : O fuge Iabrochium, sanguis meus! Ille recurvis
Demon Internet Ltd : Unguibus, estque avidis dentibus ille minax.
Southend slave deck : Ububae fuge cautus avis vim, gnate! Neque unquam
http://www.fysh.org/~psmith/ : Faedarpax contra te frumiousus eat!
okbl...@usa.net
In article <357d2d4a.3341347@news>,
er...@gadgetguru.com wrote:
>
> BEGIN_PARAGRAPH That QUOTE someone QUOTE being me COMMA I feel obliged
> to clarify my earlier statment PERIOD What I meant was that I thought
> that Pascal APOSTROPHE s use of QUOTE BEGIN QUOTE and QUOTE END QUOTE
> tags instead of punctuation marks tended to obscure the keywords and
> this that we use punctuation marks in text instead of special words
> COMMA and not because of mental laziness PERIOD Up until the age of
> the printed word COMMA
> costlyandpeoplewereperfectlycapableofusingtheirbrainstoparsethetext
> PERIOD END_PARAGRAPH
Good point. In fact, I think we under-use punctuation, since there are many
things in the language that are really not very content rich, and are just as
well expressed without words. We could start by using symbols for all the
obvious things: (& and, | or, ^ not, @ at, etc.) Then we could borrow from
other languages which have efficiently eliminated unnecessary verbiage.
For example, in Russian, the verb to-be is seldom used in the present tense.
They just put a long dash | leave it out altogether. & they have no articles.
I--happy to do that.
Japanese communicate just fine without prepositions, so those should go.
"That"--another good example word,--commonly eliminated. English we often
place "," | nothing @ all instead putting full "that". I--happy do,.
We could also save some unnecessary typing assuming, most
statements--self-referential & eliminate "I", "me", "mine" & other pronouns.
--happy do,.
@ last! Language,--easy read difficulty decoding long words!
> Personally, I prefer to use my brain, feeble though it may be, to
> focus on the higher-level aspects of programming and leave the parsing
> to the machine. :)
Dunno. When I try that, it just sits there. I've tried relying on my brain
before, but then I died, had to get a new brain, and start all over again.
[ko]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
okbl...@usa.net
In article <877m2tz...@ajb.i-have-a-misconfigured-system-so-shoot-me>,
I'm sold. Even if I have to write it!
Hey, we *really* need an entirely new IF language. Really!
[ok]
okbl...@usa.net
In article <87af7pz...@ajb.i-have-a-misconfigured-system-so-shoot-me>,
Andrew Brault <a...@tiac.net> wrote:
>
> Well, the Bomb class would be a selection in a list box, and the
> actual source code in the GUI would look like this:
>
> explode
> [...whatever lines of code...]
>
Yeahyeahyeah, but when someone has to call it, it's just:
bomb explode
I'm just pointing out that class *usage* is notably simple, both in terms of
punctuation and readability.
> Squeak Smalltalk:
> Free, very strange system, under constant development.
> It's being written by a Linux-like community headed by some of
> the original Smalltalk guys. Runs on many OS's (including Win95,
> Mac, Acorn, Unix, MS-DOS, some PDAs)
> http://squeak.cs.uiuc.edu
This is the one I was thinking of, but I get it confused with Dolphin. This
one (Squeak) would be a perfect starting point, considering it's free and runs
on a wide range of OSes.
> Dolphin Smalltalk:
> This is my favorite. Free, but requires a licence to
> distribute commercial products (around $150). Win95 only, but
> has some great technical advantages over the competition.
> http://www.object-arts.com
I've heard good things about this. But--Win95 only--euugh!
> Smalltalk MT:
> VisualWorks:
> VisualAge Smalltalk:
This is the one I've used the most, along with the ex-Digitalk Smalltalk.
okbl...@usa.net
In article <357BD6...@cs.york.ac.uk>,
Iain Merrick <i...@cs.york.ac.uk> wrote:
>
> I dislike "<-" for assignment for the trivial aesthetic reason that my
> eyes alway want to reverse direction when I'm reading from left to right
> and they hit a little left-facing arrow.
>
Well, of course, you could always do it this way, too:
A->B
Set B equal to A. Sorta assembler-esque. ;-) You could allow both!
A<-B
And they could mean different things! The first would be "A, assign yourself
to B" and the second would be "B, assign yourself to A". You would end up
with different results depending on each object's understanding of the other
object's class.
Heh.
aul...@scott.deleteme.net
In article <35771f29.11983859@news>, Eric O'Dell <er...@gadgetguru.com> wrote:
>"The circumference of a
>circle is equal to pi times the square of the radius," is certainly
>more lucid to a mathematical novice...
Though quite dangerous to this novice who might not realize it is also
incorrect.
--
_____
"No one in the world ever gets what they want, and that is beautiful.
Everybody dies frustrated and sad, and that is beautiful." -- TMBG
Darin Johnson
"David A. Cornelson" <dcorn...@placet.com> writes:
> Basic uses = for all comparisons and assignments. It's the context that
> matters, NOT the damned symbol.
But in C, and many other languages, you can use assignment and
comparison in the same context. Basic only allows assignment as a
separate statement. Granted, it can lead to obfuscated code at
times, but it's regular and orthagonal. Other languages allow any
"statement" as part of an expression.
Sometimes ":=" (or the equivalent) is better pronounced as "binds to"
in many languages.
When I first learned Lisp, I misunderstood the professor, and assumed
that setq and prog's were disallowed, so I ended up writing very in a
very functional style (ie, no assignments or sequential statements).
Until the TA asked why I was making life so hard on myself. It did
build character though :-)
--
Darin Johnson
da...@usa.net.delete_me
Darin Johnson
eare...@faeryland.tamu-commerce.edu (Allen Garvin) writes:
> It's nice to allow assignments in expressions, but with this you have a problem
> distinguishing assignment from less than the negative of the rvalue. Maybe
> <--, provided you don't have C-like minus-minus's. Hm, how about <---- *8-)
Nope, that could be one "<" followed by 4 unary "-"'s. At some point,
you just have to let the lexer free, so that it recognizes "<-" as
assignment.
(Note that in the first Smalltalks, a real left-arrow symbol was used.
Since many keyboards outside of Xerox didn't have such a key, or if
they did it was really a backspace, the "_" could be used instead, and
would show up that way in ASCII source code, but be displayed as an
arrow in the GUI. I think it was the last language or OS that used
non-ASCII keys.)
--
Darin Johnson
da...@usa.net.delete_me
okbl...@usa.net
In article <Pine.SGI.3.95L.98060...@ebor.york.ac.uk>,
Den of Iniquity <dms...@york.ac.uk> wrote:
>
> On Sat, 6 Jun 1998 okbl...@usa.net wrote:
> >Now, before someone tangents off of this (look, Ma! I invented a verb!)
>
> Argh! Don't verb nouns!
>
My most humble apoligization.
Darin Johnson
mkku...@evolution.genetics.washington.edu (Mary K. Kuhner) writes:
> While I don't know Python, I'd wonder how well the technique
> scales up. Indentation is wonderful for loops nested one
> or two levels deep. Nest ten levels deep, as my production
> code does now and again, and you run off the end of the line.
> Long lines sound like they'd be a pest in general.
It's a pest in *any* language. If you think you can get around it in
C merely be indenting less, you're just hurting the readers of your
code. A far better solution is split into more functions (make them
inline functions if you're concerned about speed). If you nest ten
levels deep, you've gone a few nesting levels beyond good taste :-)
The first language with this feature that I had seen was Occam. And
it scaled up, as Occam was written in Occam, and I believe there was
an OS in it as well.
> And some
> kinds of if/then/else constructions just don't want to be
> indented in the normal fashion (as when you're using if/then/else
> to fake a switch statement, but would prefer to indent it more
> like a switch statement).
They indent the same way. I don't understand this. See:
if (x=1) case (x) of
statements 1)
else if (x = 2) statements
statements 2)
else if (x = 3) statements
statements 3)
else if (x = 4) statements
.... ....
else default
statements statements
--
Darin Johnson
da...@usa.net.delete_me
David Rush
"Chris Wilson" <tro...@ihug.co.nz> writes:
> I like the idea of '<-'. I may impliment it as one of the options in QTAC.
> What do you think?
Personally, I like it as a syntax. However, this whole thread ignores
the real issue: What features distinguish QTAC from the rest of the
pack? How does it advance the state-of-the-art in IF programming
paradigms? Everything else is trivial detail, compared to those
questions.
david rush
--
Who has programmed in too many different languages to bother listing
them on his resume.
David Rush
er...@gadgetguru.com (Eric O'Dell) writes:
> If we want to satisfy both novices and veterans, we might want to
> consider a standard virtual machine -- something more powerful than
> any of the existing models -- targeted by compilers for different
> languages.
I do think that this is a fairly good idea. Of course we also need at
least an initial language to work with, if for no other reason than
that we'll need to write programs to demonstrate, test and promote it
with. Also, given the way this industry works, I feel like you pretty
much have to get it right the first time. If you don't backwards
compatibility and customer reputation will kill your product.
david rush
--
Unless it succeeds, in which case micr$oft will announce a 'doze01
version that comes bundled with the OS and is an integral part of
their product :|
David Rush
dg@ (David Given) writes:
> In article <357783...@cosc.canterbury.ac.nz>,
> Greg Ewing <gr...@cosc.canterbury.ac.nz> wrote:
> >As an alternative to either bracket-delimiting or keyword-delimiting
> >for code blocks, consider indentation.
> Please, no! Idented scoping like this foul! It forces the programmer to
> format its code the way the language designer wants it formatted, not the
> way the programmer wants to do it.
This is the typical response to Python's syntactic conventions from
people that have never used it. It actually works surprisingly
well. And I'm a bit of a style Nazi, at least I prefer to dictate the
style rather than have it dictated to me.
david rush
--
Eric O'Dell
On Mon, 08 Jun 1998 19:10:42 GMT, okbl...@usa.net wrote:
>@ last! Language,--easy read difficulty decoding long words!
Unless you can derive that from a BNF production, you're belaboring an
irrelevant point about human languages, not programming languages.
My original argument, more or less, was that punctuation in
programming languages and human languages alike serves chiefly to
delimit and group, and that it does so clearly, simply, and
unambiguously in programming languages. Therefore, there is no reason
to give it the same visual weight as more complex parts of the
program.
--Eric
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
Allen Garvin
In article <tvyaf7n...@cn1.connectnet.com>,
Darin Johnson <da...@usa.net.removethis> wrote:
When I first learned Lisp, I misunderstood the professor, and assumed
that setq and prog's were disallowed, so I ended up writing very in a
very functional style (ie, no assignments or sequential statements).
Until the TA asked why I was making life so hard on myself. It did
build character though :-)
Hah! I've seen people purposely torture themselves doing this in lisp
in order to be "purely" functional. But, gee, to go without them on your
first exposure to a functional language would be an impressive feat of
mental gymnastics *8-).
John Francis
In article <6lchqc$fdr$1...@nnrp1.dejanews.com>, <okbl...@usa.net> wrote:
>In article <35784F...@hotmail.com>,
> GLYPH <graham...@hotmail.com> wrote:
>>
>> I still like my idea of making BEGIN and [ synonyms, and END*; and ]
>> synonyms, so that the novice can use english and the expert can type
>> less.
>>
>I always understood the "ideal" in programming languages was to have exactly
>one way to express anything. (None even approach this ideal, but to flagrantly
>fly in the face of it may risk censure by the Authorities.)
I take it you've never met Algol-68?
Not only is ( (or, to be pedantic, a bold "(") synonymous with (bold) BEGIN;
it's also synonymous with IF, and CASE, and probably several other keywords.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Hello. My name is Darth Vader. I am your father. Prepare to die.
John Francis
In article <3578cd17.10324929@news>, Eric O'Dell <er...@gadgetguru.com> wrote:
>
>Personally, in my ideal language, the fact that assignment has exactly
>squat to do with the equality comparison would be reflected in the use
>of <- as the assignment operator, e.g.
>
> x <- 5;
And this is how it used to be, back in the old days when the character
you got by sending octal code 137? to a teletype produced a back-arrow.
Then those annoying standards comittee people decided that this should,
instead, produce an underscore. So everybody scurried to try and find
something that looked vaguely like a backarrow (because underscore was
too hard to see, especially if your print head was slightly misaligned).
And thus was born the habit of using ":=" as the assignment operator.
GLYPH
Matthew Amster-Burton wrote:
>
> On Fri, 5 Jun 1998, GLYPH wrote:
>
> > GLYPH throws up on his shoes.
> >
> > Sorry about that. No offence, but I put whitespace dependancy in the
> > same pile of bugs as case sensitivity and such.
>
> Case sensitivity? Seriously? I can think of plenty of things I'd change
> about C, C++, Perl, or TADS, but case sensitivity isn't one of them.
Yeah. (maybe it's just me, though)
> As for whitespace dependency, take a look at Python before you decide it's
> pure evil. Then again, make drives me nuts sometimes.
I just looked at Python. It's kind of neat, and some people might like
it, but I think I'd go through a lot of shoes if I had to use it. :)
- GLYPH
GLYPH
okbl...@usa.net wrote:
> In article <35784F...@hotmail.com>,
> GLYPH <graham...@hotmail.com> wrote:
> >
> > I still like my idea of making BEGIN and [ synonyms, and END*; and ]
> > synonyms, so that the novice can use english and the expert can type
> > less.
> I always understood the "ideal" in programming languages was to have exactly
> one way to express anything. (None even approach this ideal, but to flagrantly
> fly in the face of it may risk censure by the Authorities.)
You're right in a way: an ideal language (for SIZE purposes) must have
only one way to represent anything. That way it's always hitting
Kolmogorov Complexity. We don't have any conventional programming
languages like this, though. The languages that certain compressors use
(such as ppm with full exclusion) meet this requirement, but people
don't think that way. Since most languages have either zillions or
infinite (litterally) ways to represent a particular program, I don't
see why doubling that value should make a difference, seeing as it will
make several people happy. (It's all the same once it's compiled,
anyway)
> For myself, I despise things that are done solely to save typing. You are a
> programmer (or a writer): Learn to use your tools (including the keyboard).
Uh, so you'd rather I go out and buy a keyboard that has a BEGIN key and
an END key?
The only other possibility is that you mean input to software should be
as explicit as possible, so that the human spends as much time and
effort as possible in typing the program in, instead of that silly
unimportant design and planning stage. ;)
(sorry about that one)
- GLYPH
peter....@natinst.com
eare...@faeryland.tamu-commerce.edu (Allen Garvin) writes:
>
> There's also the free GNU SmallTalk, somewhat buggy and also a memory
> hog. It introduced me to smalltalk, which really gave me a clear
> understanding of Object Orientedness that I didn't get from C++.
>
Timothy Budd wrote "A Little Smalltalk" which is available at:
ftp://ftp.cs.orst.edu/pub/budd/little
This one comes without a GUI though, but it's written mostly in itself and
it runs in almost no memory. It's like 1800 lines of C or so for UNIX.
Should be easily portable/extendible since it's not using anything fancy.
No GUI sucks for development, but as an engine it might work. It's not
fully compatible to standard smalltalk though. Dunno if he allows
modifications.
Peter
-- Peter Ilberg <peter....@natinst.com>
GLYPH
Iain Merrick wrote:
> > There is a very logical way of knowing, however.
> >
> > "==" is equality because the symbol is symmetrical, and the operation
> > is symmetrical (i.e. commutative, a==b <==> b==a).
> >
> > ":=" is assignment because the symbol is asymetrical, as is the
> > operation.
>
> That makes sense. My rule-of-thumb is much more primitive:
>
> ":=" is pronounced 'becomes-equal'.
> "==" is pronounced 'equals'.
My argument would be that a lot of math people use := for "is defined
as" when writing papers and stuff, which makes it the assignment
operator. As for == vs. =, I really don't care (for once)
- GLYPH
Greg Ewing
Mary K. Kuhner wrote:
>
> While I don't know Python, I'd wonder how well the technique
> scales up.
Very well, considering that Python has been used to
implement systems consisting of many thousands of
lines of code. For example, there is an entire web
browser written in Python, and a relational database
system.
> Nest ten levels deep, as my production
> code does now and again, and you run off the end of the line.
So how do you indent your C code when it's nested 10 levels
deep? Whatever the answer to that, the same answer
applies to Python-style code.
(My answers would be: (1) use a sensible amount of
indentation, e.g. 2 or 3 spaces, and (2) consider
breaking the inner 5 or so levels out into a
separate function.)
> And some
> kinds of if/then/else constructions just don't want to be
> indented in the normal fashion
Python has an "elif" keyword for that:
n = random(1, 4)
if n == 1:
"There is a rumble of thunder."
elif n == 2:
"A gust of wind tugs at your coat collar."
elif n == 3:
"Rain trickles down the back of your neck."
else:
"You step in a puddle."
> On the other hand, I'd love to have a C compiler with a
> "check indentation" option
If the indentation and the sense are the same thing,
you don't need a tool like that.
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
Dan Shiovitz
Everyone involved in this thread *is* aware that there is an IF system
written in Python currently available, right? I haven't checked it out
myself, but it's at http://www-acs.ucsd.edu/~jstrout/python/pub/
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)
Simon Tufty Stapleton
GLYPH <graham...@hotmail.com> writes:
> The only other possibility is that you mean input to software should be
> as explicit as possible, so that the human spends as much time and
> effort as possible in typing the program in, instead of that silly
> unimportant design and planning stage. ;)
>
As a professional analyst / designer, I'd be quite happy to see this
as the case. It would ease my workload considerably.
Simon
--
_______
| ----- | Biased output from the demented brain of
||MacOS|| Simon Stapleton.
|| NOW ||
| ----- | sstaple AT liffe DoT com
| -+-.| (if you can't figure it out...)
|洵洵洵洱
-------
Den of Iniquity
On 8 Jun 1998, Dylan O'Donnell cries!
>glee...@aol.com (GLEEMOTH) writes:
>> Den complains:
>> >
>> >Argh! Don't verb nouns!
>> Verbing weirds language. (3 points)
>
>_Three_ whole points for a Calvin and Hobbes quote?
Thanks Dylan. Three points? THREE whole points for a Calvin and Hobes
quote? What kind of a fool do you take me for? I've got to make a living
you know, got two wives a mistress sixteen kids a dog three cats two
gerbils and a goldfish to feed.
I could give you 0.46 points for it but even that's tightening me belt
an inch...
--
Den
aul...@scott.deleteme.net
In article <6lgune$o...@newsops.execpc.com>,
David A. Cornelson <dcorn...@placet.com> wrote:
>>
>>":=" is pronounced 'becomes-equal'.
>>"==" is pronounced 'equals'.
>
>Basic language were smarter and better than all of the languages discussed
>so far on the equal sign.
>
>Basic uses = for all comparisons and assignments. It's the context that
>matters, NOT the damned symbol.
>
Well, yes, BASIC can get away with this. Other languages have return
values defined for both assignment and equality operators.
Consider while (i = 1).
If assignment and equality used the same operator, languages like C
would have no way of knowing what to do with that construct. It could
be either operation.
Since the fact that assignment has a return value is my single favorite
feature of C/C++, I consider this a Good Thing. I do wish K&R had used
:= instead of = but obviously that would have meant an extra keystroke,
which as we all know is the epitome of Pure Evil. =)
Joe
GLYPH
Erik Max Francis wrote:
> Barry Smith wrote:
> > I don't think the point is to completely eliminate the upper case,
> > just to have it so that #define, #DEFINE or #DeFiNe are all the same
> > to the compiler.
> If the compiler is case insensitive, then such guidelines are
> meaningless.
The guidelines may be meaningless to the compiler, but they are useful
to the human.
Similarly, whitespaces may be meaningless for Inform (which is good) but
they are useful to the human.
i.e.
if (thread.going_on_too_long)
{ while (~thread.dead) Beat(thread);
Rejoyce();
}
else Read(thread);
is more readable (in the subjective sense) than:
if(thread.going_on_too_long){while(~thread.dead)beat(thread);rejoyce();}else
read(thread);
- GLYPH
Larry Smith
John Francis wrote:
> In article <3578cd17.10324929@news>, Eric O'Dell <er...@gadgetguru.com> wrote:
> >Personally, in my ideal language, the fact that assignment has exactly
> >squat to do with the equality comparison would be reflected in the use
> >of <- as the assignment operator, e.g.
> > x <- 5;
> And this is how it used to be, back in the old days when the character
> you got by sending octal code 137? to a teletype produced a back-arrow.
> Then those annoying standards comittee people decided that this should,
> instead, produce an underscore. So everybody scurried to try and find
> something that looked vaguely like a backarrow (because underscore was
> too hard to see, especially if your print head was slightly misaligned).
> And thus was born the habit of using ":=" as the assignment operator.
And not a bad choice - certainly less error prone than
C's '=' for assignment and '==' for comparison. But
the arrow has an elegant obviousness about it that is
very compelling. But there is one problem with this
version.
The above example, x <- 5, could be easily misparsed as
x < (-5), a boolean conditional, so <- is not a good
choice. However, as Dennis Ritchie noticed, -> does not
have the same problem. You could simply reverse the
sense of assignment, 5 -> x would be read as "assign
5 to x. To come back to an earlier thread, this also
works nicely with RPN. 3 2 + -> x - rather more sim-
ilar to RPN than RPL in that the assignment is infix,
but parsing the -> provides a convenient marker to the
scanner that the "x" is to be taken as a literal in-
stead of being evaluated.
--
.-. .-. .---. .---. .-..-. |Politics is the art of looking for
| |__ / | \| |-< | |-< > / |trouble, finding it, misdiagnosing
`----'`-^-'`-'`-'`-'`-' `-' |it and then misapplying the wrong
My opinions only. |remedies. Groucho Marx
David Rush
okbl...@usa.net writes:
> In article <877m2tz...@ajb.i-have-a-misconfigured-system-so-shoot-me>,
---------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
BANG! (I use Gnus, too :)
> Andrew Brault <a...@tiac.net> wrote:
> > magician isPresent ifTrue: [rabbit => tophat].
> I'm sold. Even if I have to write it!
As a once and future Smalltalker, I'd have to say that I'm happy to
see such enthusiasm for its syntax. I've recently written a (RL)
library test tool that uses a Smalltalk-derived syntax; parsing it is
not hard, by you do have to think a little differently from
traditional compilers.
> Hey, we *really* need an entirely new IF language. Really!
Well, like yeah! And as soon as I get the inspiration about parser
integration, I'm going to write one, too.
david rush
--
David Rush
This is completely off-topic, but...
okbl...@usa.net writes:
> Japanese communicate just fine without prepositions, so those should go.
No, they don't. Linguists call them uninflected particles ("wa", "ga", "ni",
"o", etc...), but they perform the same functions in Japanese as
prepositions do in English.
david rush
--
Nihongo wakarun ka? Boku wa sukoshi dake...
David Rush
Den of Iniquity <dms...@york.ac.uk> writes:
> On 8 Jun 1998, Dylan O'Donnell cries!
> >glee...@aol.com (GLEEMOTH) writes:
> >> Den complains:
> >_Three_ whole points for a Calvin and Hobbes quote?
>
> Thanks Dylan. Three points? THREE whole points for a Calvin and Hobes
> quote? What kind of a fool do you take me for? I've got to make a living
> you know, got two wives a mistress sixteen kids a dog three cats two
> gerbils and a goldfish to feed.
>
> I could give you 0.46 points for it but even that's tightening me belt
> an inch...
I could give you four points, but that's cutting me own throat, that is...
David Rush
--
No, I don't have any relatives in Ankh-Morpork...
Darin Johnson
eare...@faeryland.tamu-commerce.edu (Allen Garvin) writes:
> Hah! I've seen people purposely torture themselves doing this in lisp
> in order to be "purely" functional. But, gee, to go without them on your
> first exposure to a functional language would be an impressive feat of
> mental gymnastics *8-).
Worse, the only other languages I knew were Pascal and LSI11
assembler. On the other hand, I grokked Lisp quite well from this
experience, and I never had any trouble understanding any other
computer language after this.
--
Darin Johnson
da...@usa.net.delete_me
David A. Cornelson
Larry Smith wrote in message <357D7B...@zk3.dec.com>...
>John Francis wrote:
>
>> In article <3578cd17.10324929@news>, Eric O'Dell <er...@gadgetguru.com>
wrote:
>
>> >Personally, in my ideal language, the fact that assignment has exactly
>> >squat to do with the equality comparison would be reflected in the use
>> >of <- as the assignment operator, e.g.
>
>> > x <- 5;
[Jarb whips out his SuperWhammy Flame Thrower and....]
All of the developers that have been discussing this and that about a
potential new IF language are completely missing the point as far as I'm
concerned.
As far as IF development is concerned, we have several areas where we could
improve the process.
One of these areas is to build upon the parsing ability and add more complex
sentence structures. This is probably not going to happen for a long time
but if someone wants to tackle it, hey, go for it.
Another is to expand the programming capabilities so that more complex code
can be written.
Another is to simplify the language (overall, not specifically) so that
NON-PROGRAMMERS can develop and write interactive fiction.
You put C, C++, SmallTalk, Python, or any of these other references in a
news post and you've just scared a hundred potential IF authors away AGAIN.
The new language should be called EZIF or IF Basic or something similar.
Maybe you're not challenged by the idea of building an easier method of IF
development but I say that doing so would be far more difficult than
building another Lisp or C or SmallTalk oriented language.
I challenge someone to create a language that satisfies both communities.
The author with no programming experience and the author that wrote his own
C compiler at the age of 6.
[Jarb holsters his flame gun and walks away...]
Joe Mason
GLEEMOTH wrote:
>
> >Argh! Don't verb nouns!
Calvin & Hobbes.
Joe
okbl...@usa.net
In article <357d4af7...@enews.newsguy.com>,
er...@gadgetguru.com wrote:
>
> Unless you can derive that from a BNF production, you're belaboring an
> irrelevant point about human languages, not programming languages.
>
Actually, I could, but it's still irrelevant.
> My original argument, more or less, was that punctuation in
> programming languages and human languages alike serves chiefly to
> delimit and group, and that it does so clearly, simply, and
> unambiguously in programming languages. Therefore, there is no reason
> to give it the same visual weight as more complex parts of the
> program.
And my rebuttal, more or less, is that your basic premise is wrong. First of
all, let's discard the human language argument entirely: it does not matter
what human languages are used for when discussing programming languages (see
COBOL for an example of *why* English doesn't and shouldn't necessarily have
anything to do with programming).
As for what punctuation in programming does, well, that depends entirely on
the language. If the argument is not to give delimiters and groups the same
weight as functional parts of a program, well, that leaves us with something
suspiciously like COBOL:
{
ADD 1 TO I.
}
After all, if your premise is true than this:
{
I++;
}
is at least as bad as this:
BEGIN
ADD 1 TO I.
END
because they both give equal (visual) weight to both constructs. And I guess,
this would be (in your estimation) as wrong as possible:
BEGIN
I++;
END
I just don't buy it. Consistency, logic and aesthetics all come into play
here, and while there is "better" and "worse", it isn't as neat as you make
it out to be.
If you're still interested, I'd be happy to look at some examples of how you
think this works in real world examples. I can sort of see what you're saying
as it applies to Smalltalk (which gives less emphasis to delimiters than most
languages, even to eschewing parenthesis around function calls).
But overall, I'm just not getting your point.
[ok]
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
okbl...@usa.net
In article <357C40...@hotmail.com>,
GLYPH <graham...@hotmail.com> wrote:
> You're right in a way: an ideal language (for SIZE purposes) must have
> only one way to represent anything. That way it's always hitting
> Kolmogorov Complexity. We don't have any conventional programming
> languages like this, though. The languages that certain compressors use
> (such as ppm with full exclusion) meet this requirement, but people
> don't think that way.
<nodding>
> Since most languages have either zillions or
> infinite (litterally) ways to represent a particular program, I don't
> see why doubling that value should make a difference, seeing as it will
> make several people happy. (It's all the same once it's compiled,
> anyway)
Because you can't please all the people all the time? In fact, most of the
time, if you're really doing a good job, you're bound to piss a good number
of people off? I dunno. It just seems sloppy to me.
I'd prefer BEGIN and END, but I'd prefer { and } as a single standard before
I'd want to see both styles implemented. I can imagine some folks around here
doing:
{
I += 1
END
or
BEGIN
I ==== I + 1; //Because no one can decide on a good assignment operator.
}
> Uh, so you'd rather I go out and buy a keyboard that has a BEGIN key and
> an END key?
I can type "BEGIN" and "END" about as quickly as I can { and }. That is, if
we were to clock it, I could do "BEGIN" in less than a second and { in less
than a second, and in a program with 1000 begin/end blocks, the difference
may be all of 15 minutes relative to hours and hours of typing.
If it's a real issue, one could use the PL/I "DO" and "END". In either case,
you get to typing particular key words very quickly. I mean, I can type 150
words a minute, as long as the words are all "the".
Smalltalk, which I have already confessed is one of my favorite languages uses
the *same* symbol for BEGIN and END: |. But it seems to work in the context of
the language because every code block is itself an object, and you're actually
delimiting the object with the vertical bars. Also, the very cool passing code
block objects as message parameters works very well as:
1 to: 5 do: |i: j[i] = i factorial |
and it wouldn't as:
1 to: 5 do: begin i: j[i] = i factorial end
In other words, I don't consider my preference for BEGIN and END to be
absolute, but dictated by the language. I don't #define { as BEGIN in my C
code, because it's inconsistent. C is designed to be dense.
Gratuitous density is what I really object to. (You can take that any of
several ways. :-))
> The only other possibility is that you mean input to software should be
> as explicit as possible, so that the human spends as much time and
> effort as possible in typing the program in, instead of that silly
> unimportant design and planning stage. ;)
>
> (sorry about that one)
No, actually, I'm glad you said it, because it seems to be what a lot of
programmers think. I'm *sure* it was a driving consideration behind the "C"
language. But it's nonsense. The time you spend designing is going to dwarf
the time you spend typing, and both are probably going to be dwarfed by the
time you spend debugging.
Explicitness can reduce debugging. So can a language that minimizes
side-effects. Languages that embrace side-effects (C, Smalltalk, REXX) and
subtleties (C especially) can create bugs that are very hard to detect.
I think the shoddiness of our OSes is probably related to the dominance of C
in building them. IBM used a PL/I variant for years on OSes that are more
stable (and still in use) on more complex machines and environments.
But I digress. :-) We now return to your regularly scheduled I-F programming.
"Hey, how 'bout that ZORK!"
okbl...@usa.net
In article <6lh7am$5m...@fido.engr.sgi.com>,
Yes! I think Algol is the language I was thinking of....
> Not only is ( (or, to be pedantic, a bold "(") synonymous with (bold) BEGIN;
> it's also synonymous with IF, and CASE, and probably several other keywords.
Isn't Algol the one that allows you to write enormously powerful matrix
manipulation programs on one line of code? Write-only code, that is.
Barry Smith
The message <357D20...@hotmail.com>
from GLYPH <graham...@hotmail.com> contains these words:
> Erik Max Francis wrote:
> i.e.
> - GLYPH
Damn, and I already had an answer that was long, incomprehensible and said
the same as this. As a minor aside, what exactly is the point of
case-sensitivity?
As far as I can see, all it does is allow you have two different
variables called
`WINDOW` and `window`. Seems like an accident waiting to happen to me.
--
Barry Smith
resi...@spam.thanks.zetnet.co.uk
(Just remove the spam thanks)
okbl...@usa.net
In article <gr867ia...@intercenter.net>,
That's all right. It was a flippant response to an irrelevant point.
(Irrelevant? Irrelevant has a trunk!)
> No, they don't. Linguists call them uninflected particles ("wa", "ga", "ni",
> "o", etc...), but they perform the same functions in Japanese as
> prepositions do in English.
Chinese, then. Swahili! Er, Pig Latin. Aw, heck, I'm sure there must be *some*
language out there that doesn't use prepositions. If not, I'll be forced to
make one up. :-)
> --
> Nihongo wakarun ka? Boku wa sukoshi dake...
>
Wakarimasen. Aisumasen, Yoko.
okbl...@usa.net
In article <6lk76d$5...@newsops.execpc.com>,
> The author with no programming experience and the author that wrote his own
> C compiler at the age of 6.
>
Oh, wait. There's a small bug in it.
Can it wait until after the Chicken/Will Mini-Comp?
"Grandma Zed has left you all her money with one caveat: You must get her
chicken safely across the road...."
Eric O'Dell
On Tue, 09 Jun 1998 14:12:56 -0400, Larry Smith <l...@zk3.dec.com>
wrote:
>The above example, x <- 5, could be easily misparsed as
>x < (-5), a boolean conditional, so <- is not a good
>choice.
Actually, unless I just totally misunderstand how yacc and kindred
tools work (which is quite possible, since I'm still learning), it
would be no great task to write the parsing rules such that
x <- 5
always parsed as "assign 5 to x" instead of
x < -5
which would require a space between the operators.
OTOH, you have a good point, since at that point, the parser wouldn't
be confused, but a human programmer might be. How about
x <= 5
which more or less looks the same, but would not be confused with any
other legal expression?
--Eric
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
Eric O'Dell
On Wed, 10 Jun 1998 01:14:13 GMT, eod...@pobox.com (Eric O'Dell)
wrote:
>OTOH, you have a good point, since at that point, the parser wouldn't
>be confused, but a human programmer might be. How about
>
> x <= 5
>
>which more or less looks the same, but would not be confused with any
>other legal expression?
<slapping forehead> ...except "less than or equal to", of course.
I suppose there's always "<<", unless you want to use it as a stream
operator, a la C++.