1. A Concensus for New Features in Euphoria
With all the talk, I think we may have a concensus (crossing my fingers)
for *modest* changes or additions to Euphoria.
1. a thing like trace() or profile() that tells you how many statements
one has.
2. a boolean function that checks if a variable is defined or not
3. If the program is under 300 lines in the PD version, or over in any
version, a command like trace() or profile() that dumps as if an error ha=
s
occurred. I can just picture myself one day creating an error just to ge=
t
a dump.
Bob? Your thoughts on these *modest* additions? Replies welcome.
--Alan
=
2. Re: A Concensus for New Features in Euphoria
Alan Tu writes:
> With all the talk, I think we may have a concensus
> (crossing my fingers) for *modest* changes or additions
> to Euphoria.
>1. a thing like trace() or profile() that tells you how many statements
> one has.
Roughly speaking, the number of statements is equal to the
number of lines of text in all source files, minus:
* the standard includes in euphoria\include - they're free
* blank lines
* comment-only lines
This assumes that the program has been formatted normally,
the way most of the demo programs are, without putting
multiple statements on one line. Formatting has no effect
on statement count - it's really the keywords that are counted,
not the lines of text.
I will not add a function to the language to report statement-count.
Someone could write a statement-counting program.
I do not intend to do it.
> 2. a boolean function that checks if a variable is defined or not
This is possible, but I don't see a big need for it.
> 3. If the program is under 300 lines in the PD version, or over in any
> version, a command like trace() or profile() that dumps as if an error >
has occurred. I can just picture myself one day creating an error
> just to get a dump.
procedure dump()
? 1/0
end procedure
Regarding short-circuit evaluation:
I think the subject has been beaten to death on this
list in the past week. I don't really need any more
feedback unless someone can think of a totally new angle
to the problem. I am still leaning strongly towards doing it.
I am more concerned right now with details, like how to
define it in the most clear, consistent way,
given that Euphoria AND/OR expressions can produce sequences
as results, not just atoms (like C and other languages).
I will also do a more careful (automatic) scan through user-contributed
programs to get a better idea of how many will break (less than 1%
I expect). In bin\search.ex you can type in search strings like:
if*and*(*)*then
to find "if" conditions that have a function call after an "and".
The same could be done for "or" ,"while", "elsif".
Fixing the code would be easy.
There would be a warning in any case where "breakage" might
occur. I also plan to improve the issue of warnings so they don't
get lost so easily when your program clears the screen (or
whatever).
Regards,
Rob Craig
Rapid Deployment Software
