Python and Flaming Thunder

[Dave Parker]

I've read that one of the design goals of Python was to create an easy-
to-use English-like language. That's also one of the design goals of
Flaming Thunder at http://www.flamingthunder.com/ , which has proven
easy enough for even elementary school students, even though it is
designed for scientists, mathematicians and engineers.

[s0suk3]

On May 21, 10:34 am, Dave Parker <[e-mail]>
wrote:

On May 20, 7:05 pm, Collin <[e-mail]:

Personally, FT is a bit meh to me. The way you issue your statements I
always think something is wrong, mainly because when I want to define,
say, x, in python I'd go:

x = "whatever"

Instantly noting that I defined x. While in Flaming Thunder I'd have to
type:

Set x to "whatever"

It just feels wrong.

Actually, it felt wrong to me when I first started working on Flaming
Thunder because I've been programming for decades and have had all of
the programming idioms burned into my brain.

But after getting input from children and teachers, etc, it started
feeling right.

For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".

So it seems like you're designing a language for non-programmers.
That's good, I've never heard about anyone so interested in teaching
programming for kids and non-programmers. But in that case, you
shouldn't even be comparing it to Python.

Many computer languages conflate "equality" with "assignment" and then
go to even more confusing measures to disambiguate them (such as using
== for equality, or := for assignment).

That stops being confusing after a few weeks of programming.
(Actually, IMO, it's not confusing, but it's tricky because sometimes
it's a hard typo to find. Though that will only be a syntax error in
Python.) But again, that'll be great for the kids! ;-)

Plus, symbols are more confusing for people to learn about than
words. There are lots of people who are fluent in English, but
dislike math.

Learning the symbols of a programming language is one of the first and
minimum requirements to learning any particular programming language--
we call that the "syntax" of the language.

So, I opted for a simple, unambiguous, non-mathematical way of
expressing "assignment" which makes sense even to the non-
mathematically inclined:

Set x to 8.

That way, = can be reserved unambiguously and unconfusingly for the
mathematical notion of "equality" -- because it's in their math
classes that people learn what = means:

Set QuadraticEquation to a*x^2 + b*x + c = 0.

So it seems that you got a great language for math teachers, non-
mathematicians, non-programmers, and kids! (what a great arsenal of
people...). Maybe if I have a kid someday I'll teach him Flaming
Thunder! (just kidding, you prick).

[Bruno Desthuilliers]

s0****@gmail.com a écrit :
(snip)

Maybe if I have a kid someday I'll teach him Flaming
Thunder! (just kidding, you prick).

Err... Could we please avoid name calling, gentlemens ?

[Nick Craig-Wood]

Dave Parker <da********@flamingthunder.comwrote:

But after getting input from children and teachers, etc, it started
feeling right.

For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".

This is a common feature in functional languages...

Eg

Erlang (BEAM) emulator version 5.6.2 [source] [smp:2]
[async-threads:0] [kernel-poll:false]

Eshell V5.6.2 (abort with ^G)
1X = 8.
8
2X = 10.
** exception error: no match of right hand side value 10
3>

That error message is the erlang interpreter saying "Hey I know X is
8, and you've said it is 10 - that can't be right", which is pretty
much what math teachers say too...

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[Mensanator]

On May 22, 10:30*am, Nick Craig-Wood <[e-mail]:

Dave Parker <[e-mail]:

*But after getting input from children and teachers, etc, it started
*feeling right.

*For example, consider the two statements:

* * * x = 8
* * * x = 10

*The reaction from most math teachers (and kids) was "one of those is
*wrong because x can't equal 2 different things at the same time".

This is a common feature in functional languages...

Eg

Erlang (BEAM) emulator version 5.6.2 [source] [smp:2]
[async-threads:0] [kernel-poll:false]

Eshell V5.6.2 *(abort with ^G)
1X = 8.
8
2X = 10.
** exception error: no match of right hand side value 10
3>

That error message is the erlang interpreter saying "Hey I know X is
8, and you've said it is 10 - that can't be right", which is pretty
much what math teachers say too...

Are you saying that erlang treats 1as an assignment, yet
treats 2as a comparison?

That's inconsistent. No wonder nobody uses erlang.

Why isn't erlang smart, like Python, and avoid such confusion?

IDLE 1.2

>>X = 2**3 # assignment
X == 8 # comparison

True

>>X == 10

False

>>>

>
--
Nick Craig-Wood <[e-mail]--http://www.craig-wood.com/nick

[Mel]

Mensanator wrote:

On May 22, 10:30Â*am, Nick Craig-Wood <[e-mail]:

>Dave Parker <[e-mail]:

But after getting input from children and teachers, etc, it started
feeling right.

For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".

This is a common feature in functional languages...

Eg

Erlang (BEAM) emulator version 5.6.2 [source] [smp:2]
[async-threads:0] [kernel-poll:false]

Eshell V5.6.2 Â*(abort with ^G)
1X = 8.
8
2X = 10.
** exception error: no match of right hand side value 10
3>

That error message is the erlang interpreter saying "Hey I know X is
8, and you've said it is 10 - that can't be right", which is pretty
much what math teachers say too...

Are you saying that erlang treats 1as an assignment, yet
treats 2as a comparison?

That's inconsistent. No wonder nobody uses erlang.

In Prolog terms, they're both unification. If X has never been defined you
can define it as 8 with no chance of contradicting anything. Once X is 8,
the proposition "X is 10" is false.

I act as though Erlang thinks the same. My Erlang chops aren't as good as my
Prolog chops were.

Mel.

[bruno.desthuilliers]

On 22 mai, 18:56, Mensanator <[e-mail]:

On May 22, 10:30 am, Nick Craig-Wood <[e-mail]:

Dave Parker <[e-mail]:

But after getting input from children and teachers, etc, it started
feeling right.

For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".

This is a common feature in functional languages...

Eg

Erlang (BEAM) emulator version 5.6.2 [source] [smp:2]
[async-threads:0] [kernel-poll:false]

Eshell V5.6.2 (abort with ^G)
1X = 8.
8
2X = 10.
** exception error: no match of right hand side value 10
3>

That error message is the erlang interpreter saying "Hey I know X is
8, and you've said it is 10 - that can't be right", which is pretty
much what math teachers say too...

Are you saying that erlang treats 1as an assignment, yet
treats 2as a comparison?

Nope. Both are treated as pattern matching. The first one binds X
because it's by that time a free variable, the second fails because it
doesn't match.

That's inconsistent.

That's consistent when you understand how Erlang works.

No wonder nobody uses erlang.

Strange enough, it seems that more and more developpers and company
start to look at Erlang as a possible solution to massive scaling
problems.

Why isn't erlang smart, like Python, and avoid such confusion?

Erlang *is* smart. It's just totally different from Python. And
there's no confusion here (except on your side...).

[Nick Craig-Wood]

Mel <mw*****@the-wire.comwrote:

Mensanator wrote:

On May 22, 10:30??am, Nick Craig-Wood <[e-mail]:

Dave Parker <[e-mail]:
But after getting input from children and teachers, etc, it started
feeling right.

For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".

This is a common feature in functional languages...

Eg

Erlang (BEAM) emulator version 5.6.2 [source] [smp:2]
[async-threads:0] [kernel-poll:false]

Eshell V5.6.2 ??(abort with ^G)
1X = 8.
8
2X = 10.
** exception error: no match of right hand side value 10
3>

That error message is the erlang interpreter saying "Hey I know X is
8, and you've said it is 10 - that can't be right", which is pretty
much what math teachers say too...

Are you saying that erlang treats 1as an assignment, yet
treats 2as a comparison?

That's inconsistent. No wonder nobody uses erlang.

In Prolog terms, they're both unification. If X has never been defined you
can define it as 8 with no chance of contradicting anything. Once X is 8,
the proposition "X is 10" is false.

I act as though Erlang thinks the same. My Erlang chops aren't as good as my
Prolog chops were.

I had to look up the definition of unification, but yes you are right,
erlang and prolog seem mean roughly the same thing by the = sign. It
is called the pattern matching operator in erlang.

From Armstrong's book: The expression Pattern = Expression causes
Expression to be evaluated and the result matched against Pattern. The
match either succeeds or fails. If the match succeeds any variables
occurring in Pattern become bound.

It is a very powerful idea and one which (along with the concurrency
and message passing from Erlang) has been implemented for python :-

http://candygram.sourceforge.net/

I've been reading the Erlang book and I have to say it has given me a
lot of insight into python...

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[Matthew Woodcraft]

<s0****@gmail.comwrote:

So it seems like you're designing a language for non-programmers.
That's good, I've never heard about anyone so interested in teaching
programming for kids and non-programmers. But in that case, you
shouldn't even be comparing it to Python.

At one time, Guido was very keen on the idea of Python as a language to
introduce non-programmers to (under the 'Computer Programming for
Everybody' slogan).

I think it's rather a shame that this has more-or-less fallen by the
wayside. There are lots of people out there producing buggy
spreadsheets to do things that would be easier to do in a programming
language.

-M-

[Torsten Bronger]

Hallöchen!

Matthew Woodcraft writes:

[...]

At one time, Guido was very keen on the idea of Python as a
language to introduce non-programmers to (under the 'Computer
Programming for Everybody' slogan).

I think it's rather a shame that this has more-or-less fallen by
the wayside. There are lots of people out there producing buggy
spreadsheets to do things that would be easier to do in a
programming language.

I don't think so. It's still reasonably simple to write short
Python programs for e.g. the analysis of measurement results. But
people simply don't trust cheap non-point'n'click programs which
don't occupy two shelves in the bookstore.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Brian Quinlan]

Dave Parker wrote:

>Or just:

If command is "quit" ...

Hmmm. In Flaming Thunder, I'm using "is" (and "is an", "is a", etc)
for assigning and checking types. For example, to read data from a
file and check for errors:

Read data from "input.txt".
If data is an error then go to ...

Hey Dave,

Does this mean that Flaming Thunder requires explicit checking rather
than offering exceptions?

Cheers,
Brian

[Charles Hixson]

On Thursday 22 May 2008 13:30:07 Nick Craig-Wood wrote:

...

From Armstrong's book: The expression Pattern = Expression causes

Expression to be evaluated and the result matched against Pattern. The
match either succeeds or fails. If the match succeeds any variables
occurring in Pattern become bound.

It is a very powerful idea and one which (along with the concurrency
and message passing from Erlang) has been implemented for python :-

http://candygram.sourceforge.net/

I've been reading the Erlang book and I have to say it has given me a
lot of insight into python...

Although when comparing Candygram with Erlang it's worth noting that Candygram
is bound to one processor, where Erlang can operate on multiple processors.
(I'd been planning on using Candygram for a project at one point, but this
made it unusable.)

[I V]

On Thu, 22 May 2008 19:35:50 -0700, Charles Hixson wrote:

Although when comparing Candygram with Erlang it's worth noting that
Candygram is bound to one processor, where Erlang can operate on
multiple processors. (I'd been planning on using Candygram for a project
at one point, but this made it unusable.)

Really? The FAQ says it uses operating system threads, which I would have
thought would mean it runs on multiple processors (modulo, I suppose, the
issues with the GIL).

[Kay Schluehr]

On 13 Mai, 01:39, Dave Parker <[e-mail]:

I've read that one of the design goals of Python was to create an easy-
to-use English-like language. That's also one of the design goals of
Flaming Thunder athttp://www.flamingthunder.com/ , which has proven
easy enough for even elementary school students, even though it is
designed for scientists, mathematicians and engineers.

"Why on earth shall kids program and even more serious: why shall I
program in a language for kids?"

[Iain King]

On May 23, 3:35 am, Charles Hixson <[e-mail]:

On Thursday 22 May 2008 13:30:07 Nick Craig-Wood wrote:

...

>From Armstrong's book: The expression Pattern = Expression causes

Expression to be evaluated and the result matched against Pattern. The
match either succeeds or fails. If the match succeeds any variables
occurring in Pattern become bound.

It is a very powerful idea and one which (along with the concurrency
and message passing from Erlang) has been implemented for python :-

http://candygram.sourceforge.net/

I've been reading the Erlang book and I have to say it has given me a
lot of insight into python...

Although when comparing Candygram with Erlang it's worth noting that Candygram
is bound to one processor, where Erlang can operate on multiple processors..
(I'd been planning on using Candygram for a project at one point, but this
made it unusable.)

lol, nice name. Also surprisingly relevant to the thread:

candygrammar: n.

A programming-language grammar that is mostly syntactic sugar; the
term is also a play on ‘candygram’. COBOL, Apple's Hypertalk language,
and a lot of the so-called ‘4GL’ database languages share this
property. The usual intent of such designs is that they be as English-
like as possible, on the theory that they will then be easier for
unskilled people to program. This intention comes to grief on the
reality that syntax isn't what makes programming hard; it's the mental
effort and organization required to specify an algorithm precisely
that costs. Thus the invariable result is that ‘candygrammar’
languages are just as difficult to program in as terser ones, and far
more painful for the experienced hacker.

[Duncan Booth]

Brian Quinlan <br***@sweetapp.comwrote:

Dave Parker wrote:

>>Or just:

If command is "quit" ...

Hmmm. In Flaming Thunder, I'm using "is" (and "is an", "is a", etc)
for assigning and checking types. For example, to read data from a
file and check for errors:

Read data from "input.txt".
If data is an error then go to ...

Hey Dave,

Does this mean that Flaming Thunder requires explicit checking rather
than offering exceptions?

It looks that way but he doesn't seem to have got as far as documenting
errors: the documentation gives several examples of that form and says that
'error' is a reserved word but says nothing about how you create an error
of if you can distinguish one error from another:

I'm guessing you can't as FT doesn't appear to have any concept of
attributes on objects (or even any concept of objects): so far as I can see
the only types are integers, rationals, intervals and strings (and real
numbers if you pay real money for them).

Maybe I'm missing something though, because I don't see how you can do
anything useful with out at least some sort of arrays (unless you are
supposed to store numbers in long strings).

--
Duncan Booth http://kupuguy.blogspot.com

[Nick Craig-Wood]

I V <iv*****@gmail.comwrote:

On Thu, 22 May 2008 19:35:50 -0700, Charles Hixson wrote:

Although when comparing Candygram with Erlang it's worth noting that
Candygram is bound to one processor, where Erlang can operate on
multiple processors. (I'd been planning on using Candygram for a project
at one point, but this made it unusable.)

Really? The FAQ says it uses operating system threads, which I would have
thought would mean it runs on multiple processors (modulo, I suppose, the
issues with the GIL).

I think candygram is crying out to be married with stackless &or PyPy.
It also needs an IPC channel to compete with Erlang directly.

If you are interested in stackless python vs Erlang then take a look
at this...

http://muharem.wordpress.com/2007/07...rst-benchmark/

....and read the discussion too!

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[Dave Parker]

Does this mean that Flaming Thunder requires explicit checking rather

than offering exceptions?

Right now, yes, Flaming Thunder has minimal error handling. But error
handling is rising on the list of priorities for the next few weeks
(arrays, matrices, and 3D graphics are the hightest).

I think in a month or two, Flaming Thunder will be using catch/throw
exception and error handling. So, for example:

Set result to catch(read x from "input.txt".).
If result is an error then go to quit.

If not caught, errors will propagate up and if they they hit the top
level, cause the program to write an error message and exit.

Using only catch instead of try/catch has several advantages that I
can see. 1) it gets rid of all the impotent try/catch/throw
statements cluttering up Java, etc. 2) since all Flaming Thunder
statements return values (like C statements), Catch also gives you a
single, uniform, syntactically unambiguous way to embed statements (or
whole statement lists) into expressions -- without causing the
syntactic problems of = statements in if statements or the obfuscation
of question mark notation, etc. For example:

If catch(set x to y+z.) < 0.1 then go to tinyanswer.

On May 22, 4:19*pm, Brian Quinlan <[e-mail]:

Dave Parker wrote:

Or just:

If command is "quit" ...

Hmmm. *In Flaming Thunder, I'm using "is" (and "is an", "is a", etc)
for assigning and checking types. *For example, to read data from a
file and check for errors:

* * *Read data from "input.txt".
* * *If data is an error then go to ...

Hey Dave,

Does this mean that Flaming Thunder requires explicit checking rather
than offering exceptions?

Cheers,
Brian

[Dave Parker]

That error message is the erlang interpreter saying "Hey I know X is

8, and you've said it is 10 - that can't be right", which is pretty
much what math teachers say too...

I enjoyed the discussion of how different languages handle the notion
of "="; I learned something new. Thanks.

On May 22, 9:30*am, Nick Craig-Wood <[e-mail]:

Dave Parker <[e-mail]:

*But after getting input from children and teachers, etc, it started
*feeling right.

*For example, consider the two statements:

* * * x = 8
* * * x = 10

*The reaction from most math teachers (and kids) was "one of those is
*wrong because x can't equal 2 different things at the same time".

This is a common feature in functional languages...

Eg

Erlang (BEAM) emulator version 5.6.2 [source] [smp:2]
[async-threads:0] [kernel-poll:false]

Eshell V5.6.2 *(abort with ^G)
1X = 8.
8
2X = 10.
** exception error: no match of right hand side value 10
3>

That error message is the erlang interpreter saying "Hey I know X is
8, and you've said it is 10 - that can't be right", which is pretty
much what math teachers say too...

--
Nick Craig-Wood <[e-mail]--http://www.craig-wood.com/nick

[Duncan Booth]

Dave Parker <da********@flamingthunder.comwrote:

Catch also gives you a
single, uniform, syntactically unambiguous way to embed statements (or
whole statement lists) into expressions -- without causing the
syntactic problems of = statements in if statements or the obfuscation
of question mark notation, etc. For example:

If catch(set x to y+z.) < 0.1 then go to tinyanswer.

So what does this do exactly if the set throws an error? Is the error
message printed at the top level going to be telling you about the failed
addition or the failed comparison? Why do you need the catch anyway, if a
statement is just an expression why can't you just put the statement into
parentheses?

For that matter, is there any way to distinguish between different errors
and only catch particular ones? A bare except clause in Python is usually a
signal of bad code: when handling errors you only want the errors you have
anticipated, and want to be sure that any unexpected errors don't get
caught.

You have a great opportunity to avoid making some of the same mistakes that
Python is trying to get out of. For example as of Python 2.5
KeyboardInterrupt and SystemExit to longer inherit from Exception. That
means a bare except in Python no longer catches either of those: if you
want to handle either of these exceptions you have to be explicit about it.
--
Duncan Booth http://kupuguy.blogspot.com

[Dave Parker]

If catch(set x to y+z.) < 0.1 then go to tinyanswer.

>
So what does this do exactly if the set throws an error?

I think the catch should catch the error thrown by set, compare it to
0.1, the comparison will not return true because the error is not less
than 0.1, and so the go-to to tinyanswer will not be taken.

Is the error
message printed at the top level going to be telling you about the failed
addition or the failed comparison?

I don't think there will be an error message at the top in the case
above, because I don't think the comparison should fail -- the
comparision will return that it is not true that the error is less
than 0.1.

Why do you need the catch anyway, if a
statement is just an expression why can't you just put the statement into
parentheses?

Statements return values, but statements are not just expressions.
Statements are more about control-flow and side-effects; expressions
are more about returning values. Putting a statement into parentheses
in a context where expressions are also allowed in parentheses is (or
can be) both lexically and visually ambiguous. That's why C had to
resort to the confusing "=" vs "==" notation -- to disambiguate the
two cases. The "catch" keyword unambiguously alerts the reader that
the parenthesis contain a statement (or a whole list of statements).

For that matter, is there any way to distinguish between different errors
and only catch particular ones?

I think the catch function should catch all of the errors (and the non-
error result if no error occured), so I think distinguishing the error
would have to come after. Maybe something like:

Set result to catch(read x from "input.txt".).
If result = dividebyzeroerror then ... else throw result.

I'm open to alternate suggestions, though.

You have a great opportunity to avoid making some of the same mistakes that
Python is trying to get out of.

I'm sure that I'll make my own new and different errors. :) However,
I really appreciate your comments because maybe I'll make fewer
errors. Or at least, correct them faster.

On May 28, 7:52*am, Duncan Booth <[e-mail]:

Dave Parker <[e-mail]:

Catch also gives you a
single, uniform, syntactically unambiguous way to embed statements (or
whole statement lists) into expressions -- without causing the
syntactic problems of = statements in if statements or the obfuscation
of question mark notation, etc. *For example:

If catch(set x to y+z.) < 0.1 then go to tinyanswer.

So what does this do exactly if the set throws an error? Is the error
message printed at the top level going to be telling you about the failed
addition or the failed comparison? Why do you need the catch anyway, if a
statement is just an expression why can't you just put the statement into
parentheses?

For that matter, is there any way to distinguish between different errors
and only catch particular ones? A bare except clause in Python is usually a
signal of bad code: when handling errors you only want the errors you have
anticipated, and want to be sure that any unexpected errors don't get
caught.

You have a great opportunity to avoid making some of the same mistakes that
Python is trying to get out of. For example as of Python 2.5
KeyboardInterrupt and SystemExit to longer inherit from Exception. That
means a bare except in Python no longer catches either of those: if you
want to handle either of these exceptions you have to be explicit about it..

--
Duncan Boothhttp://kupuguy.blogspot.com

[Luis Zarrabeitia]

On Wednesday 28 May 2008 09:22:53 am Dave Parker wrote:

I think in a month or two, Flaming Thunder will be using catch/throw
exception and error handling. *So, for example:

Nice... Flaming Thunder sure evolves quickly. Too quickly to be considered
a 'feature' of the language. Following your posts in this thread, I see that
you 'plan to add soon' every cool feature that every other language seems to
have.

That means that I won't have to test my program only against every major
versions of Flaming Thunder... i will have to test it with every week's
version. With no certainty whatsoever that today's program will work on
tomorrow's FT.

Why don't you wait a bit, until Flaming Thunder is mature enough to be stable,
before trying to advertise it to us? And in the meantime, some of us are
going to keep trying to add all the features we've always wanted, to the next
major version of Python.

--
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie

[Dan Upton]

On Wed, May 28, 2008 at 11:09 AM, Dave Parker
<da********@flamingthunder.comwrote:

If catch(set x to y+z.) < 0.1 then go to tinyanswer.

So what does this do exactly if the set throws an error?

I think the catch should catch the error thrown by set, compare it to
0.1, the comparison will not return true because the error is not less
than 0.1, and so the go-to to tinyanswer will not be taken.

The semantics you're describing aren't clear here. I suppose that's
sort of reasonable, given that you haven't implemented it yet, but
let's think about it for a second. You say the catch construct should
catch the error thrown by set, but there's no reason "set" itself
should throw any sort of error in the sense of an exception--in a
statement like "Set x to SomeFunctionThatCanBlowUp()", the semantics
should clearly be that the error comes from the function. In a simple
addition statement, that makes no sense. So then I considered that
maybe you meant the error in the sense of some determination of
floating point roundoff error, but that can't be it, since you've
claimed recently a big win over Python with FT in that it has no
roundoff error. So what, exactly, is the error you could even be
catching in that? Assuming the answer is "You're right, there's no
actual error that could generated by that assignment," there are two
options: the compiler optimizes it away, or you throw a compile-time
error. The latter makes more sense, as someone trying to catch an
exception where one can't possibly exist probably indicates a
misunderstanding of what's going on.

... That's why C had to
resort to the confusing "=" vs "==" notation -- to disambiguate the
two cases. The "catch" keyword unambiguously alerts the reader that
the parenthesis contain a statement (or a whole list of statements).

However, I think overloading your catch error types to include objects
(or integral values, I guess, your example below isn't clear) along
with real values (ignoring the bit above about whether floating-point
assignment could throw an error) makes things confusing. It's nice
that "catch(stuff)" indicates that there's one or more statements
inside, but so does indentation in Python, bracketing in C/C++,
Begin/End in <insert language here>, and so forth, but it doesn't give
any indication to what could come out and ideally, only one thing (or
its descendants in a type hierarchy) can come out. (I suppose this
can be solved by overloading your comparison operators.) Beyond that,
I think you would want a good mechanism for comparing ranges of values
if you want to make exceptions/errors real-valued.

>For that matter, is there any way to distinguish between different errors
and only catch particular ones?

I think the catch function should catch all of the errors (and the non-
error result if no error occured), so I think distinguishing the error
would have to come after. Maybe something like:

Set result to catch(read x from "input.txt".).
If result = dividebyzeroerror then ... else throw result.

I'm open to alternate suggestions, though.

[Dave Parker]

On May 28, 12:09 pm, Luis Zarrabeitia <[e-mail]:

Following your posts in this thread, I see that
you 'plan to add soon' every cool feature that every other language seems to
have.

I've already added a lot of them. For example, loops that don't need
looping variables:

For 1000 times do ...

Explicit infinite loops:

For forever do ...

I don't those are features that every other language seems to have,
not even Python.

Plus, by this weekend, built-in compiled fullscreen 3D graphics will
be in, too.

With no certainty whatsoever that today's program will work on
tomorrow's FT.

Kind of like how this year's program won't work on next year's
Python? Except Flaming Thunder is faster. ;)

[Diez B. Roggisch]

Kind of like how this year's program won't work on next year's

Python?

For somebody who has admitted to have only very rudimentary knowledge of
python that's a pretty bold statement, don't you think?

Except Flaming Thunder is faster. ;)

Faster in execution speed for a very limited domain of problems - maybe.

But unless it grows support for structured data types, arrays and maybe
even an object system - it's nothing but a toy language.

Diez

[Dave Parker]

On May 28, 12:48*pm, "Dan Upton" <[e-mail]:

there's no reason "set" itself
should throw any sort of error in the sense of an exception--in a
statement like "Set x to SomeFunctionThatCanBlowUp()", the semantics
should clearly be that the error comes from the function. *In a simple
addition statement, that makes no sense.

For example:

Set z to catch(somefunctionthatmightblowup(...)).
If catch(set x to y+z.) < 0.1 then go to tinyanswer.

Or something like that. Or if you change the + to a / and z is 0.0,
for example, then it could cause a divide-by-zero exception. There is
no guarantee that the + won't cause an exception, given that there is
no guarantee that y and z are both numeric.

However, I think overloading your catch error types to include objects
(or integral values, I guess, your example below isn't clear) along
with real values (ignoring the bit above about whether floating-point
assignment could throw an error) makes things confusing.

Catch doesn't return just error types or numbers, it can return any
object returned by the statements that are being caught; catch doesn't
care what type they are. For example:

Writeline catch(set x to "hello world".).

will write "hello world".

>*It's nice
that "catch(stuff)" indicates that there's one or more statements
inside, but so does indentation in Python, bracketing in C/C++,
Begin/End in <insert language here>, and so forth, ...

Except that in those languages, I don't think that the indentation,
bracketing, Begin/End, etc, can be used in expressions. Catch can.
For example, catch will return the final value of z:

If catch(Set x to y+z. Set y to x+z. Set z to 1/(x+y).) < 0.1 then go
to tinyanswer.

>*Beyond that,
I think you would want a good mechanism for comparing ranges of values
if you want to make exceptions/errors real-valued.

I am thinking that exceptions/errors should have any kinds of values
the programmer wants to give them. Some people prefer error numbers,
some prefer error messages, some prefer error identifiers, etc. I am
thinking that the Error function should simply take a list of whatever
objects the user wants to throw, and throw them. For example, if the
programmer wanted an error number and an error message for a
particular error:

If x < 10 then throw error(10, "Please enter a number >= 10").

They could then do something like:

Set result to catch(funtionthatcouldblowup(...)).
If result is an error then if result(1) = 10 then writeline
result(2).

Thank you for your comments, they are helping me to clarify my own
thinking on error handling in general and on catch in particular.

[Dave Parker]

On May 28, 3:19*pm, "Diez B. Roggisch" <[e-mail]:

Kind of like how this year's program won't work on next year's
Python?

For somebody who has admitted to have only very rudimentary knowledge of
python that's a pretty bold statement, don't you think?

Everthing I know, I learned from Wikipedia. ;)

http://en.wikipedia.org/wiki/Python_..._compatibility

"Like Perl 6, Python 3.0 will break backward compatibility. There is
no requirement that Python 2.x code will run unmodified on Python 3.0.
There are basic changes such as changing the print statement into a
print function (so any use of the print statement will cause the
program to fail) ..."

[Diez B. Roggisch]

Dave Parker schrieb:

On May 28, 3:19 pm, "Diez B. Roggisch" <[e-mail]:

>>Kind of like how this year's program won't work on next year's
Python?

For somebody who has admitted to have only very rudimentary knowledge of
python that's a pretty bold statement, don't you think?

Everthing I know, I learned from Wikipedia. ;)

http://en.wikipedia.org/wiki/Python_..._compatibility

"Like Perl 6, Python 3.0 will break backward compatibility. There is
no requirement that Python 2.x code will run unmodified on Python 3.0.
There are basic changes such as changing the print statement into a
print function (so any use of the print statement will cause the
program to fail) ..."

You should read further:

"""
However, a tool called "2to3" does most of the job of translation,
pointing out areas where it wasn't sure using comments or warnings. Even
in an alpha stage 2to3 appears to be fairly successful at performing the
translation.
"""

And all this is about Py3k- nobody forces anybody to leave python 2.x
series.

I think you should contort yourself a bit wrt backwards compatibility
and stability - given that FT is by no means an established and
productive tool.

Diez

[Giampaolo Rodola']

On 28 Mag, 23:13, Dave Parker <[e-mail]:

On May 28, 12:09 pm, Luis Zarrabeitia <[e-mail]:

Following your posts in this thread, I see that
you 'plan to add soon' every cool feature that every other language seems to
have.

I've already added a lot of them. *For example, loops that don't need
looping variables:

For 1000 times do ...

Explicit infinite loops:

For forever do ...

I don't those are features that every other language seems to have,
not even Python.

Plus, by this weekend, built-in compiled fullscreen 3D graphics will
be in, too.

With no certainty whatsoever that today's program will work on
tomorrow's FT.

Kind of like how this year's program won't work on next year's
Python? *Except Flaming Thunder is faster. ;)

On 28 Mag, 23:13, Dave Parker <[e-mail]:

On May 28, 12:09 pm, Luis Zarrabeitia <[e-mail]:

Following your posts in this thread, I see that
you 'plan to add soon' every cool feature that every other language seems to
have.

I've already added a lot of them. For example, loops that don't need
looping variables:

For 1000 times do ...

Explicit infinite loops:

For forever do ...

I don't those are features that every other language seems to have,
not even Python.

Plus, by this weekend, built-in compiled fullscreen 3D graphics will
be in, too.

With no certainty whatsoever that today's program will work on
tomorrow's FT.

Kind of like how this year's program won't work on next year's
Python? Except Flaming Thunder is faster. ;)

This is nonsense.
Python 2.x is around since... what is it? Almost 10 years?
It lasted that long maintaining retro-compatibility between the
various versions.
It's very funny that you point your finger at Python's compatibility
as a factor of weakness when your FT breaks it *every week*.
Before trying to convince whoever that your FT is better than Python
you should first decide what to do with your own product by starting
to implement all that *basic* features which are common to all modern
languages (arrays, OOP, error handling, data structures, Unicode
support, etc...).
Once you do that, ask yourself if the way you did it was good/
reliable, ask users what they think about it, and apply changes as
necessary.
At that point you'll be ready to start publicizing FT as an
alternative in respect to other languages.
Currenlty you're trying to push something which is not even a "pre-
alpha" over something else (Python) which has been around since about
20 years and it is known to be one of the cleanest and more elegant
languages around.
--- Giampaolo
http://code.google.com/p/pyftpdlib

[Duncan Booth]

Dave Parker <da********@flamingthunder.comwrote:

Catch doesn't return just error types or numbers, it can return any
object returned by the statements that are being caught; catch doesn't
care what type they are. For example:

Writeline catch(set x to "hello world".).

will write "hello world".

I really don't get this. Surely the point about an error being thrown to a
catch statement is that the error path is separate from the normal
execution path? What you are doing here is ensuring that unexpected errors
have no chance at all of propagating up to the top level: they are
invariably going to get caught by some other handler that was installed
just because someone was too lazy to write a set statement followed by a
writeline.

--
Duncan Booth http://kupuguy.blogspot.com

[Dan Upton]

On Thu, May 29, 2008 at 3:36 AM, Duncan Booth
<du**********@invalid.invalidwrote:

Dave Parker <da********@flamingthunder.comwrote:

>Catch doesn't return just error types or numbers, it can return any
object returned by the statements that are being caught; catch doesn't
care what type they are. For example:

Writeline catch(set x to "hello world".).

will write "hello world".

I really don't get this. Surely the point about an error being thrown to a
catch statement is that the error path is separate from the normal
execution path? What you are doing here is ensuring that unexpected errors
have no chance at all of propagating up to the top level: they are
invariably going to get caught by some other handler that was installed
just because someone was too lazy to write a set statement followed by a
writeline.

It also looks like an overloading of catch, semantically similar to the C:

int retcode;
if( retcode = doSomethingThatReturns0or1() ) printf("Hello world");

Again, I don't think you want to start overloading your
exception-handling mechanism. If you want a set expression to be
equal to the l-value at the end, that's fine, but there's no reason
that catch should evaluate to an object or an integral- or real-valued
exception in error cases, or of the last statement of the block if
there's no error. (Evaluating a block to be equal to its last
statement is okay, I guess; I know at least that there's a call in
Scheme that lets you do a more imperative programming style in the
functional language--whether that's a good thing is probably a holy
war.) I just think if you're shooting for an easily understandable
language, overloading error handling requires more thought on the
programmer's part, not less, because they have to reason about all
outcomes.

[Duncan Booth]

"Dan Upton" <up***@virginia.eduwrote:

On Thu, May 29, 2008 at 3:36 AM, Duncan Booth
<du**********@invalid.invalidwrote:

>Dave Parker <da********@flamingthunder.comwrote:

>>Catch doesn't return just error types or numbers, it can return any
object returned by the statements that are being caught; catch
doesn't care what type they are. For example:

Writeline catch(set x to "hello world".).

will write "hello world".

I really don't get this. Surely the point about an error being thrown
to a catch statement is that the error path is separate from the
normal execution path? What you are doing here is ensuring that
unexpected errors have no chance at all of propagating up to the top
level: they are invariably going to get caught by some other handler
that was installed just because someone was too lazy to write a set
statement followed by a writeline.

It also looks like an overloading of catch, semantically similar to
the C:

int retcode;
if( retcode = doSomethingThatReturns0or1() ) printf("Hello world");

Again, I don't think you want to start overloading your
exception-handling mechanism. If you want a set expression to be
equal to the l-value at the end, that's fine, but there's no reason
that catch should evaluate to an object or an integral- or real-valued
exception in error cases, or of the last statement of the block if
there's no error. (Evaluating a block to be equal to its last
statement is okay, I guess; I know at least that there's a call in
Scheme that lets you do a more imperative programming style in the
functional language--whether that's a good thing is probably a holy
war.) I just think if you're shooting for an easily understandable
language, overloading error handling requires more thought on the
programmer's part, not less, because they have to reason about all
outcomes.

I like BCPL's way of handling block expressions: VALOF is followed by a
block of statements and within that block RESULTIS gives the result.
This lets you exit the block early (just like a return statement does),
but without returning from the current procedure (unless of course the
entire body of the procedure is a VALOF block). Naturally the result has
to be explicitly specified (otherwise the value is undefined).

Maybe FT should do something similar:

Writeline value of (set x to "hello world". Result is x.).

and catch can then stick to catching errors.

--
Duncan Booth http://kupuguy.blogspot.com

[D'Arcy J.M. Cain]

I guess I am still new to this group and don't understand its charter.
I wasn't aware that it was a Flaming Blunder group. Can someone please
point me to a newsgroup or mailing list dedicated to the Python
programming language?

--
D'Arcy J.M. Cain <da***@druid.net | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
[phone] (DoD#0082) (eNTP) | what's for dinner.

[Dan Upton]

On Thu, May 29, 2008 at 5:57 PM, D'Arcy J.M. Cain <da***@druid.netwrote:

I guess I am still new to this group and don't understand its charter.
I wasn't aware that it was a Flaming Blunder group. Can someone please
point me to a newsgroup or mailing list dedicated to the Python
programming language?

Yeah, but if you look past the "FT is better than Python" propaganda,
there's some interesting discussion of language design.

[Dave Parker]

Dan Upton wrote:

I just think if you're shooting for an easily understandable
language, overloading error handling requires more thought on the
programmer's part, not less, because they have to reason about all
outcomes

Duncan Booth wrote:

Maybe FT should do something similar:
Writeline value of (set x to "hello world". Result is x.).

I like the "value of" syntax. You guys have convinced me to
reconsider overloading the error handling. Thank you both.

[alex23]

On May 30, 8:02 am, "Dan Upton" <[e-mail]:

Yeah, but if you look past the "FT is better than Python" propaganda,
there's some interesting discussion of language design.

Which is more appropriate on a group focused on such a topic.

[Marc 'BlackJack' Rintsch]

On Thu, 29 May 2008 17:57:45 -0400, D'Arcy J.M. Cain wrote:

I guess I am still new to this group and don't understand its charter.
I wasn't aware that it was a Flaming Blunder group. Can someone please
point me to a newsgroup or mailing list dedicated to the Python
programming language?

By discussing language design of FT compared to other languages you can
learn about Python. We all know that Python is brilliant -- here's the
opportunity to think about why it is. :-)

And it's basically only this very long thread, so it's easy to filter and
ignore in a decent news reader.

Ciao,
Marc 'BlackJack' Rintsch

[Duncan Booth]

"D'Arcy J.M. Cain" <da***@druid.netwrote:

I guess I am still new to this group and don't understand its charter.
I wasn't aware that it was a Flaming Blunder group. Can someone please
point me to a newsgroup or mailing list dedicated to the Python
programming language?

A minor point of netiquette: it's fine to reply by email to a message if
you want to make a point off group, but if you are following up to the
newsgroup/mailing list please don't CC the original sender: they will see
the message in any case on the newsgroup and getting it twice is just
likely to annoy.

I don't understand your problem: it's just a single thread so killfile or
skip it.

--
Duncan Booth http://kupuguy.blogspot.com

[Torsten Bronger]

Hallöchen!

Duncan Booth writes:

[...]

I don't understand your problem: it's just a single thread so
killfile or skip it.

Although I agree with you that there is no problem, *this* is not a
good justification for this thread. One should stay on topic in
*every* thread.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[Grant Edwards]

On 2008-05-30, Torsten Bronger <br*****@physik.rwth-aachen.dewrote:

Hall?chen!

Duncan Booth writes:

>[...]

I don't understand your problem: it's just a single thread so
killfile or skip it.

Although I agree with you that there is no problem, *this* is not a
good justification for this thread. One should stay on topic in
*every* thread.

I've noticed that a lot of things that should be, aren't.

The percentage of off-topic threads in c.l.p is extraordinarily
low by normal Usenet standards. One oughtn't complain about it
lest one jinx things and reduce c.l.p to the state of the rest
of Usenet.

I wouldn't even consider the thread all that OT, but maybe
that's just me.

--
Grant Edwards grante Yow! ! Everybody out of
at the GENETIC POOL!
visi.com

[Torsten Bronger]

Hallöchen!

Grant Edwards writes:

On 2008-05-30, Torsten Bronger <br*****@physik.rwth-aachen.dewrote:

>Duncan Booth writes:

>>[...]

I don't understand your problem: it's just a single thread so
killfile or skip it.

Although I agree with you that there is no problem, *this* is not
a good justification for this thread. One should stay on topic
in *every* thread.

[...]

I wouldn't even consider the thread all that OT, but maybe that's
just me.

Me too, and therefore I see no problem. But one shouldn't break the
rules, relying on all others sticking to them.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)

[John Salerno]

"Dave Parker" <da********@flamingthunder.comwrote in message
news:de**********************************@s21g2000 prm.googlegroups.com...

Kind of like how this year's program won't work on next year's
Python? Except Flaming Thunder is faster. ;)

To be fair (and accurate), Python 3.0 has been in development for a long
time without being marketed for production use. Furthermore, there is no
reason to think 3.0 will take over "next year." It's already been stated
that it may be years before it does, and meanwhile 2.x will continue to be
developed.

Also, and this is purely my novice opinion, it seems like the
incompatibilites are mainly going to come from program written in older
versions of Python. The big, noticeable changes in 3.0 hardly seem to affect
anything you'll write in recent versions of Python (and that 2to3 won't fix
otherwise).

[John Salerno]

"Dave Parker" <da********@flamingthunder.comwrote in message
news:a9**********************************@w8g2000p rd.googlegroups.com...
On May 20, 7:05 pm, Collin <[e-mail]:

---
For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".
---

Aw, come on. I'm a novice programmer but even after reading the most basic
of introductions to a programming language I can tell that x is being
assigned one value, then another.

It doesn't seem fair to take statements like the above out of the context of
a program and then ask teachers and students about it. This statement:

2 + 2 = 4

means something in the context of an elementary math class, but is clearly
not an assignment statement in Python. But I've never encountered anyone who
was confused by this distinction, as long as you know where this line
belongs.

[Dan Upton]

On Thu, Jun 5, 2008 at 9:43 AM, John Salerno <jo******@nospamgmail.comwrote:

"Dave Parker" <da********@flamingthunder.comwrote in message
news:a9**********************************@w8g2000p rd.googlegroups.com...
On May 20, 7:05 pm, Collin <[e-mail]:

---
For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".
---

Aw, come on. I'm a novice programmer but even after reading the most basic
of introductions to a programming language I can tell that x is being
assigned one value, then another.

It doesn't seem fair to take statements like the above out of the context of
a program and then ask teachers and students about it. This statement:

2 + 2 = 4

means something in the context of an elementary math class, but is clearly
not an assignment statement in Python. But I've never encountered anyone who
was confused by this distinction, as long as you know where this line
belongs.

Yeah, that's sort of like I mentioned earlier in the thread about
there being a time dependence between the two. Not only that, but I
just realized that Dave has trotted out several times the notion of
representing (and solving) a quadratic equation in FT. Well, let's
see... (x-9)**2 - 1 = (too lazy to do the expansion to write in ax**2
+ bx + c format) = 0... solve solve solve... wait, x = 8 and x = 10!
But how can that be, Dave? You and your elementary kids just told me
I can't have two values for x...

;)

[Dave Parker]

On Jun 5, 7:57 am, "Dan Upton" <[e-mail]:

>... wait, x = 8 and x = 10!
But how can that be, Dave? You and your elementary kids just told me
I can't have two values for x...

x = 8 OR x = 10. ;)

By the way, realtime fullscreen 3D graphics are now up and running
under Windows. Check out the News and Docs at http://www.flamingthunder.com/

On Jun 5, 7:57 am, "Dan Upton" <[e-mail]:

On Thu, Jun 5, 2008 at 9:43 AM, John Salerno <[e-mail]:

"Dave Parker" <[e-mail] in message
news:a9**********************************@w8g2000p rd.googlegroups.com...
On May 20, 7:05 pm, Collin <[e-mail]:

---
For example, consider the two statements:

* * x = 8
* * x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".
---

Aw, come on. I'm a novice programmer but even after reading the most basic
of introductions to a programming language I can tell that x is being
assigned one value, then another.

It doesn't seem fair to take statements like the above out of the context of
a program and then ask teachers and students about it. This statement:

2 + 2 = 4

means something in the context of an elementary math class, but is clearly
not an assignment statement in Python. But I've never encountered anyonewho
was confused by this distinction, as long as you know where this line
belongs.

Yeah, that's sort of like I mentioned earlier in the thread about
there being a time dependence between the two. *Not only that, but I
just realized that Dave has trotted out several times the notion of
representing (and solving) a quadratic equation in FT. *Well, let's
see... (x-9)**2 - 1 = (too lazy to do the expansion to write in ax**2
+ bx + c format) = 0... solve solve solve... wait, x = 8 and x = 10!
But how can that be, Dave? *You and your elementary kids just told me
I can't have two values for x...

;)- Hide quoted text -

- Show quoted text -

[Sam Denton]

John Salerno wrote:

"Dave Parker" <da********@flamingthunder.comwrote in message
news:a9**********************************@w8g2000p rd.googlegroups.com...
On May 20, 7:05 pm, Collin <[e-mail]:

---
For example, consider the two statements:

x = 8
x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".
---

Aw, come on. I'm a novice programmer but even after reading the most basic
of introductions to a programming language I can tell that x is being
assigned one value, then another.

I've long believed that '=' should be banned from programming languages.
Use '==' for equality tests, and ':=' for assignments.

[Dave Parker]

On Jun 7, 10:24 am, Sam Denton <[e-mail]:

I've long believed that '=' should be banned from programming languages..
Use '==' for equality tests, and ':=' for assignments.

That's an interesting suggestion that I don't recall hearing anyone
else ever mention.

On Jun 7, 10:24*am, Sam Denton <[e-mail]:

John Salerno wrote:

"Dave Parker" <[e-mail] in message
news:a9**********************************@w8g2000p rd.googlegroups.com...
On May 20, 7:05 pm, Collin <[e-mail]:

---
For example, consider the two statements:

* * *x = 8
* * *x = 10

The reaction from most math teachers (and kids) was "one of those is
wrong because x can't equal 2 different things at the same time".
---

Aw, come on. I'm a novice programmer but even after reading the most basic
of introductions to a programming language I can tell that x is being
assigned one value, then another.

I've long believed that '=' should be banned from programming languages..
* Use '==' for equality tests, and ':=' for assignments.- Hide quoted text -

- Show quoted text -