1. 300 statements
- Posted by Andy Kurnia <akur at BSDI.COM> Apr 27, 1998
- 513 views
At Sun, 26 Apr 1998 02:36:52 -0400, Irv Mullins <irv at ELLIJAY.COM> wrote: >At 12:50 AM 4/26/98 -0500, Kasey wrote: >>is stored in the vaiable (plus dim.eis less than 20 lines against my >>300 total > >You can do it in 18 or less with pure Euphoria (including the >EOF checking) It works fine, and needs no includes: [snip] %EUDIR%\README.DOC: > For programs up to 300 statements in size you will enjoy the full support of > Euphoria's excellent debugging facilities. Blank-lines and comments are not > counted, and the standard include files are free (if not bound or "shrouded"). > You can put many statements on one line, or you can split a statement across > many lines -- it won't affect your statement count. The limit is 300 *statements*, not lines. The question is, what constitutes a statement? I would guess the following code has 22 statements, not 18: (1) atom (2) sequence (3) question = (4) answer = (5) object (6) fn = (7) if (8) abort (9) end if (10) while (11) input = (12) if (13) exit (14) end if (15) question = (16) input = (17) if (18) exit (19) end if (20) answer = (21) end while (22) close Is it true? Or not? >----------------------- code begins ------------------------------- >atom fn -- handle for file >sequence question, answer -- storage for q's and a's > question = {} -- must be empty when you start > answer = {} -- ditto > >object input -- must be declared as object, not sequence > >fn = open("QUESTION.TXT","r") -- open the question file as (fn) >if fn = -1 then abort(1) end if > > while 1 do -- do forever > > -- get a question: > input = gets(fn) -- read a line from your file > if atom(input) then exit -- EOF encountered, so forever is over > end if > question = append(question,input) -- tack on to question list > > -- now get the answer: > input = gets(fn) -- get next line > if atom(input) then exit -- EOF > end if > answer = append(answer,input) -- tack on to answer list > > end while >close(fn) Regarding this statement count / limit: 1. I'd like to see RDS implementing an option to only count the number of statements. It'd then be easy to know if I'm 4 statements away from being unable to get debug informations. 2. It'd also be nice to have 'who can code something in the least number of statements' contest. 3. 300 is annoying. 1000'd make more people register. (They'd get more to try.) 4. I'd propose the end ... statements (end t, end f, end p; end f, end w, end i; etc) not counted, as well as include. (The statements inside already count.) Example: include get.e -- this does not count if get_key() = -1 then exit end if -- 2 statements not 3 But are they already excluded? RDS has never explicitly mentioned which statements are counted and which are not. Add \DOC\STMTCNT.DOC please?? 5. Enabling object x = 5, y = "test", z = {3, "xyz"} would save many statement counts. Right now it's only available if I'm declaring constants, i.e. variables that won't change. 6. Having iifs (immediate ifs, just like C's ?: operator) would be nice. Coding function iif(integer c, object t, object f) if c then return t end if -- not "else return f end if" with an extra "else" return f end function costs 6 statements and will force calculation of both t and f, but if I want to code "iif(y, x / y, 0)" I'd just get a div-by-0 message if y is 0, this is different from C's ?: where the unneeded value is not evaluated at all. Also having short-circuit boolean evaluation is handy to save many statement counts, rather than having nested ifs: if length(x) >= 4 then if not compare(lower(x[length(x) - 2..length(x)]), ".txt") then -- do something end if end if If one still wants to have a completely-evaluated boolean expression he'd just use math equations like: if (a != 0) * (b != 0) then -- this is a and b, both are evaluated if (a != 0) + (b != 0) then -- this is a or b, both are evaluated if (a != 0) - (b != 0) then -- this is a xor b, must evaluate both if (a != 0) != (b != 0) then -- also a xor b if (a != 0) = (b != 0) then -- this is a eqv b (QB), noted a <=> b if (a != 0) <= (b != 0) then -- this is a imp b (QB), noted a => b if a = 0 then -- this is not a Well, maybe this post is irrelevant to most Euphorians who have enough money and already register, but someone's got to say it...
2. Re: 300 statements
- Posted by Irv Mullins <irv at ELLIJAY.COM> Apr 27, 1998
- 503 views
At 05:54 PM 4/27/98 +0700, Andy Kurnia wrote: >Regarding this statement count / limit: > 2. It'd also be nice to have 'who can code something > in the least number of statements' contest. Actually, a nice idea. Sometimes people can find a *very much better* way to do something. Tricks are ok if: 1. you understand how they work, and 2. they aren't "fragile" - meaning they only work if you feed them certain carefully selected values. >Well, maybe this post is irrelevant to most Euphorians who have >enough money and already register, but someone's got to say it... I don't have enough money. Does anyone have enough money? (Sit down, Bill Gate$!) But I did send RDS some money to register Euphoria. Skip lunch for a week, if necessary. You won't die. If RDS goes on to other, better paying, work, Euphoria will. Irv
3. Re: 300 statements
- Posted by Daniel Berstein <daber at PAIR.COM> Apr 28, 1998
- 501 views
- Last edited Apr 29, 1998
> 1. I'd like to see RDS implementing an option to only count the number of > statements. It'd then be easy to know if I'm 4 statements away from > being unable to get debug informations. It would be nice, and easy to implement... but not necesary, I think. > 3. 300 is annoying. 1000'd make more people register. (They'd get more to > try.) You're lucky now, before the limit was 50 statements! Regards, Daniel Berstein.
4. Re: 300 statements
- Posted by Falkon <Falkn13 at IBM.NET> Apr 28, 1998
- 503 views
From: Andy Kurnia >I would guess the following code has 22 statements, not 18: > (1) atom (2) sequence (3) question = (4) answer = (5) object (6) fn = > (7) if (8) abort (9) end if (10) while (11) input = (12) if (13) exit > (14) end if (15) question = (16) input = (17) if (18) exit (19) end if > (20) answer = (21) end while (22) close >Is it true? Or not? My guess is that the if...then..endif construct counts as one statement and the same for the while...end while. That would make it 18. But statements inside the constructs other than the base would be separate. That is "if x then y" is one statement, but "if x then y else z" is two. That's just my guess about the way a computer would see 'em though. It seems that the first case would just be a plain conditional jump but the second would require two steps, pick a jump address based on the condition, then jump to it. >1. I'd like to see RDS implementing an option to only count the number of > statements. It'd then be easy to know if I'm 4 statements away from > being unable to get debug informations. Write a routine that scans the file and counts the statements, edit your editor to run the routine from a menu. I think RDS can find plenty of more important things to implement if they want. Not that I'm saying EU needs a lot, just that many people have made suggestions and RDS no doubt has their own ideas and I think any of those would be higher priority than messing with the shareware limit. >3. 300 is annoying. 1000'd make more people register. (They'd get more to > try.) Eh...download another shareware language. Pick one. Any one. Compare methods. Most either include no documentation (or only minimal), cripple their compiler/editor so that you can't load/save/ or run any code, disable main parts of the language, leave out a necessary runtime, or give you a logic bomb that detonates after a certain amount of time or uses as their demo. Any/all of this as well as placing limits on the length of code you can experiment with or amount of memory you can use in your experiments. RDS, on the other hand, gives you everything fully documented and functionally unlimited as well as tons of examples. The only limit is how much you can debug. That does give you more to try. And it gets my registration fee. >Having iifs (immediate ifs, just like C's ?: operator) [and] having short-circuit boolean >evaluation is handy to save many statement counts, rather than having nested ifs This would help optimization...at the cost of confusion. Might end up with compiler directives for 'C-like evaluation syntax', 'Pascal syntax', 'ANSI-style', '16-bit', 'UNIX style' and everything else that's confusing about other languages. I wouldn't complain about short-circuiting in and of itself, (especially for those nested ifs), but I'd just as soon spend a couple extra minutes writing a couple extra lines than to spend a couple hours trying to figure out which way to write the lines with which combination of directives for best effect. Falkon