1. circuits
If the 300-statements limit cannot be relieved a bit (by giving
the error message and location, like e.g. "Runtime error 200 at
XXXX:XXXX", but of course the XXXX:XXXX must be relatable to
the program, see below for example), that's alright.
It simply means that I must register somehow...
Anyone having a good project idea that:
- is not too complicated,
- is not using GUI (Windows, mouse, graphics),
- is doable using Euphoria, and
- will have lots of registered Euphorians vote for?
The rest, I will just tell you why I complained in the first place:
At 03:54 AM 6/26/98 +0200, Ralf Nieuwenhuijsen wrote:
>[Topic: Should there be a 300-statements limit?]
Well, the really annoying part is even the error message is not
provided. I can live with a "Syntax error in test.ex:25" or
"Division by zero in test.ex:154" without dumps of variables,
stacks etc, but at least give me an error message and where
it occured... The following message does not help at all. An
error message will help though not much.
puts(2,
"An error was detected during execution of your program.\n" &
"\n" &
"Your program exceeds 300 statements in size, so this Public " &
"Domain Edition\n" &
"of Euphoria cannot provide run-time error diagnostics. If you " &
"purchase\n" &
"the Complete Edition of Euphoria you will get full diagnostic " &
"support for\n" &
"any size of program. See register.doc or visit " &
"http://members.aol.com/FilesEu/\n" &
"\n" &
"Meanwhile, you can locate your problem using print statements " &
"and the\n" &
"Euphoria trace facility.\n")
Yes there should be a 300-statements limit, otherwise, quoting
Ralf's words, "will it bring food on his table?". But please
don't be so evil as to not provide the error message and where
it occured.
>>>> Robert Craig: Please define statement count.
Well, I meant, are "include", "end ...", "else" etc counted?
>[Topic: Does statement count matter?]
>
>In this topic, you think statement count matters for two reasons (please
>correct me if I'm wrong):
>1) Your a poor boy and can't afford to register Euphoria and thus have to
>stay below the 300 statements limit.
>2) It's speedier.
Heh, option one is true. I don't understand why it would be any
speedier, though. Explain?
>My counter-arguments:
>1) The number of spare time you seem to ...
'seem' -- that is not an argument.
>[A longer version would be:]
>
> Example: a and b and c and d
> Will be: a and (b and ( c and d ) )
Actually I prefer the more intuitive
((a and b) and c) and d
yes, left to right.
>[Do we need/want short-circuit?]
>
>Your arguments:
>1) We can then have faster programs.
>2) Besides basic, Euphoria is the only language not doing short-circuit.
>3) It gets clumbsy handling this by the multiple if-trick.
>
>1) "If a then if b then if c then .... end if end if end if" is just as fast
>internally. (see the topic about 'does statement count matter'), however (a
>!= 0) * (b != 0) replaces internally a comparisement with an
>multiplication. So, actually fully optimized programs will run *slower* with
>short-cirquitting.
Then you can implement it as how internally it is handled.
Later you provided this example:
>while 1 do
> if shift_hold () and getc(0) = 27 then -- shift+escape
> abort(1)
> end if
>end while
If you want to achieve the same inefficient result with the short-
circuit operators withOUT math operators you would do this:
object a, b
while 1 do
a = shift_hold()
b = getc(0) = 27
if a and b then
abort(1)
end if
end while
But if I were you I would test shift_hold() when getc(0) *returns*
the Esc key. Since shift_hold() must be a peek to #417, the if
should be:
if getc(0) = 27 and shift_hold() then -- works w/ short circuit!
There, pretty straightforward. On the other hand there is no clean
way to do short-circuiting with non-short-circuiting operators.
Example, after reversal of order of function calls:
object a, b
while 1 do
a = getc(0) = 27
b = 0
if a then -- takes an extra if for every operand!
b = shift_hold()
end if
if a and b then
abort(1)
end if
end while
>And so you did brake my argument. I was wrong, you need to repeat it or use
>a function.
>Yes, but itsn't it cleaner that way ?
>Better readable ? Safer ?
The complete evaluation is not clean, since you have to repeat
elsif/else, or examine what the (remotely placed) function/procedure
does.
The short circuit is better readable to most any non-Euphoria
programmers, and it is not that hard to learn, it is a useful thing.
The short circuit is safer, since then you can do
if sequence(x) and length(x) >= 2 and integer(x[2]) and
x[2] = 'x' then
without worrying about forgetting to end a nested
if sequence(x) then if length(x) >= 2 then if integer(x[2])
then if x[2] = 'x' then
...
end if end if end if
-- warning: still inside one if!!
All examples you have provided, Ralf, use 'and'. I must admit
it is a lot easier to implement 'and' than 'or'.
Logic errors tend to show up with this method of nesting if.
As for "proper indentation", I mean how the compiler (interpreter
in this case) sees it. Lots of C/C++ programmers have failed to
get a program working, because they used these unappreciated style:
a = 2 * 3+4; // they expect a = 14, but they get a = 10
if (this)
if (that)
printf("yes and yes\n");
else
printf("no and no\n"); // whoops, wrong logic
While not as common, your style:
if (this) if (that) // what if this is combined?
printf("yes and yes\n");
else
printf("no and no\n"); // hmm, the same as the above
is not very different. It simply gives you more headache
debugging your program.
C has no end if, but you can force creation of a block with {}.
Perl constructs (if, unless, while, until, for, foreach) all
force the statements to be in blocks, even if there is only
one statement, except if the condition is placed at the end of
the command, e.g.
close(f) if (f != -1); # this does not apply in Perl...
a = b / c unless (!c); # '!c' means 'not c', or 'c == 0'
Rob Craig has forced all constructs (if, while, for) to be in
blocks which must have end ifs, end whiles, and end fors, but
as Ralf has shown, it does not help *that* much.
>> No, you may not make functions or types to accomplish a single if
>> (because they ALSO COUNT AGAINST YOUR STATEMENT COUNT).
>
>Its not a simple if. Its you to think that an if- statement in meant to be
>used for such strange behaviour in that way. Read Monty's mail.
It is not a simple if, yes, but it is a sinGle if.
>There are, btw, a few simple ways around that 300-statement limit actually.
Tell me... 
>1) To make sure the old existing euphoria code works.
>2) The fact that programs will break shows the need for them. Either
>simulated by a '*' or '+' trick or not.
Weak reasons, the old code can be adjusted, while if this is delayed
more hacks (yes hacks) will have been implemented.
Overcoming this is very simple, use a new operator, do not substitute
the old one. For example we have scand and scor, and also and and or,
they may not be combined in an expression so they must be parenthesized
correctly.
>[About the clumbsyness of if a then if b then .. end if end if]
>
>Off course not. By using [if a then if b then ... end if end if] I distict
>the mechanism from:
>
>Therefor I can see in a sec it is a short-circuit and not a normal
>short-circuit.
What is the difference bwtween "a short-circuit" and "a normal
short-circuit"?
The nested if trick, that will have to have all elsifs/elses
repeated, will often give you logic errors. Well I use that
trick in almost every batch file I had...
Say, that trick does not work with 'or's...
>[Again about the clumbsyness]
>> and is that innermost else being executed for failures on outside ifs?
>
>It shouldn't be that way.
Right, so it has to be repeated again and again.
>I mean, do you ever draw an algorithm on paper?
>How do you draw short-circuited ifs ?
>Yep, it isn't a thing that should happen, nor something we expect to happen.
I never saw a need to draw a flowchart. However I would still use
/ \
/ \ +------+
/ a() and \_________\| do |
\ b() ? / /| THEN |
\ / YES +------+
\ / |
| |
V NO |
+---------+ |
| do ELSE | |
+---------+ |
| |
V |
+--------------+ |
| after END IF |<-------+
+--------------+
and understand it clearly that b() would NOT be called if a() is false.
If I want both to be called I use the above method, A = a(), B = b(),
*then* I test if "A and B". I rarely want both to be called, however.
>> My point is, why make it necessary to make functions? You'll soon run
>> out of names and begin naming them shroudedly... just like Assembly,
>
>This is the namespace problem. Ever heard of seperate include files ?
>Ever heard of routine iD's ?
Sure. Ever heard of "eh -- this 'if' checks what this function returns,
which *.e in the world is that function defined in ...", two hours of
almost-silence with only the typing sound, and "ah-ha! well this function
should work. Now if it fails it goes to this else, or that else, oh boy
I'm lucky they all call the same procedure. Now I'll just have to find
which *.e has got that procedure..."?
You don't want the conditions and/or the operations to be far away from
the code. That is why Rob strictly avoided implementing goto.
>It doesn't brake my argument. You should give an programming example that
>would really be simplified with the use of short-circuit.
if sequence(x) and length(x) >= 2 and atom(x[1]) and atom(x[2]) and
x[2] != 0 and integer(x[1] / x[2]) and x[1] / x[2] >= 1 and x[1] /
x[2] <= length(x) and atom(x[1] / x[2]) and x[x[1] / x[2]] < 0 then
-- x[x[1]/x[2]] is a negative atom
if f != -1 and getc(f) = -1 then
-- eof! maybe a zero-byte file?
>Simple. It is not algoritmic behaviour.
>Try to draw it on a paper, and compare it to the structure of the if a then
>if b then if c then .. end if end if end if.
>See ? Howcome we even get to the idea of short-circuit. Its not part of a
>normal program flow and never was.
>And even if you have to use functions. Its so much more clear, usefull and
>safer.
Functions are naturally placed elsewhere (you cannot have functions
inside functions!), and it would take time to find it. Imagine a
printed program and you must look for the function with your eyes.
Drawing if a then if b then ... will soon take out your ink and take
much paper and will have to repeat the elsif and else parts.
Yes it is an algorithmic behavior. It is also more efficient to have
it check only as few operands as possible.
A random example, "if you did something wrong and someone else noticed,
you will be reported to the police", is it necessary to check whether
"someone else noticed" if "you did nothing wrong"?
Finally, programming is not drawing.
>You are neglecting information if that is allowed.
Nope, it simply makes it harder to neglect information. At times,
there are information that should be neglected.
>It is like a function you can use as a procedure. Bad style, very bad.
Logical and should be legal. It has lots of uses. For example, you
can skip a line with: gets(f) --> no need to assign to object junk.
>Robert gets to decide. Robert needs to make a living.
>So if I add 1 and 1 together (don't short-circuit on me now) I figured if
>you would promise to register Euphoria for every registration it already
>has, you can make up your own language!!! And because its such a usefull one
>(lets call it 'cerlopia' ) you can make very useful short-circuiting
>programs and you will make a lot of money. In the end you may even make a
>profit. Try to get the money for the registrations from the bank!
I don't understand what you mean "register Euphoria for every
registration".
>[He still has no idea what an if-statement is about]
>> Give me an example WHY you need to do "normal" iffing.
>
>while 1 do
> if shift_hold () and getc(0) = 27 then -- shift+escape
> abort(1)
> end if
>end while
>
>It will mess up your stack!
>However, the weird behaviour caused this is causing will hardly be related
>to this.
>I mean, what is great about Euphoria is that you actually find the error.
There is a logic error, since this is what happened:
you hold shift
a = 1 if shift is held, else 0 --> shift is held, a = 1
b = getc(0) = 27 --> this will WAIT FOR A CHARACTER
-- (better use wait_key, no line-buffering)
then you release shift
then you press Esc
then getc(0) returns 27
b = 1 --> true
now test if a and b then ...
You are not pressing shift+esc, it's you pressed shift and you are
pressing esc. Different. Yet your "then" still works...
You don't seem to have debugged your code thoroughly...
>Use them instead of Euphoria.
>Go complain by them they need to be more like Euphoria for say eh.. (what of
>Euphoria do you like ?)
Flexible sequences. It would really be very powerful if it had not
needed to take 4 bytes per integer.
>You don't count. You're having trouble every thing.
Hmmm, alright. I don't count.
>> Given the option, and not the experience, I would still vote for SC.
>
>You don't register. So you don't vote.
Another weak argument. I said "(if I had been) given the option".
>This is a discussion. I like, I hate, I feel, etc. are not arguments. That
>is as relevant as your the name of little creature living on the hill in
>this dream I had 5 years ago.
Fine.
>> Actually if you're discussing "you'll never need", you DON'T need
>> =, !=, <=, <, or >, because with >= you can test:
>> but you have all six of them! Isn't that strange??? :->>>
>
>No, actually it isn't.
>Adding things that make it more complex is a *bad* idea.
>Adding things that make it more logical and natural is a *good* idea.
>
>'<=' is very clean
And short circuit is very clean. You just think of ideas to make them
seem dirty.
Really, you'll never need "or" either, for "a or b" = "not ((not a) and
(not b))". You don't need plus ("a + b" = "a - (-b)" = "a - (0 - b)")
or multiply ("a * b" = "a / (1 / b)"). etc.
Short circuits are just as nice as '<='.
>Like I said before, how do you draw such an algorithm in the first place ?
>In other words, how do you come to need sc ?
You (seem to) have no programming experience outside Euphoria.
You don't know how powerful it would be to allow sc.
Worse, you don't want to know.
Right?
>So, next time, don't try to win a discussion on syntax, grammer or spelling
>errors. Or with useless comparisations with other languages. It puts you on
Alright! You win Ralf. Again. As it has always been. Congratulations!
Guess why I lost this flame war. Lack of experience. 
I'm too polite to be a Dutch.
2. Re: circuits
Andy:
Euphoria price of $53 for the dual edition, is in my country the same as the
price of a light dinner for two persons, or half the price of a technical
book.
Compare it to the price of a C or Pascal compiler, or a Basic interpreter...
This issue of convincing Robert to get rid of the 300 statement limit for
not registered users is turning *very* boring for the rest of us.
Since Robert is not going to be convinced, and the rest of us are going to
be bored,
Why don't stop this useless quest?.
Thanks.
Jesus.
>----Mensaje original-----
>De: Euphoria Programming for MS-DOS
>[mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]En nombre de Andy Kurnia
>Enviado el: viernes 26 de junio de 1998 8:47
>Para: EUPHORIA at LISTSERV.MUOHIO.EDU
>Asunto: circuits
>
>
> If the 300-statements limit cannot be relieved a bit (by giving
> the error message and location, like e.g. "Runtime error 200 at
> XXXX:XXXX", but of course the XXXX:XXXX must be relatable to
> the program, see below for example), that's alright.
