1. What's new in 2.5?
Yes, the structure is brand new. But what about functionality?
The only item I heard about is the cleanup handler. Nice improvement, even
though optional resume will be still missing :(
I had posted a wish list a couple years ago, most of which doesn't appear to
make its way in. The most important for my programming are:
- local include (make an identifier visible to the including file only)
- Allow PBR in routines, using some easy to spot syntax so that the
possibility for a var to be modified is not unpredictable;
- Negative index tin strings;
- call functions as procedure when they modify their first arg, so that
someMeaningfulLongName=append(someMeaningfulLongName,something)
may become
someMeaningfulLongName=append(_,something)
or
someMeaningfulLongName.append(something)
or
append(someMeaningfulLongName,something)
- Something I had not mentioned before: assume i+3 falls of the valid indexes
of sequence s. The current behaviour is that
if s[i+3]<3 then...
crashes as the bound check fails. But no logical condition holds true when
some of its args doesn't exist. As a result, it would be much simpler to code
if any such test quietly returned false.
Thus, we'd have, whenever x doesn't exist: x<y = x=y = x>y = 0. Not a problem,
as x doesn't exist...
CChris
PS: Rob, did you get my modified get.e file I sent you from an alternate
address?
2. Re: What's new in 2.5?
Christian Cuvier wrote:
<snip>
> - Something I had not mentioned before: assume i+3 falls of the valid indexes
> of sequence s. The current behaviour is that
>
> if s[i+3]<3 then...
>
> crashes as the bound check fails. But no logical condition holds true when
> some of its args doesn't exist.
I disagree. If A is true, then logically speaking (A or B) is also true
in any case, even if B doesn't exist. This consideration also applies to
real Euphoria code, in case that short-circuiting takes place.
> As a result, it would be much simpler to code
> if any such test quietly returned false.
I think that this would considerably increase the number of bugs in
Euphoria programs, because bound checking helps a lot in debugging.
<snip>
Regards,
Juergen
3. Re: What's new in 2.5?
- Posted by Derek Parnell <ddparnell at bigpond.com>
Sep 06, 2004
-
Last edited Sep 07, 2004
Christian Cuvier wrote:
>
> Yes, the structure is brand new. But what about functionality?
>
> The only item I heard about is the cleanup handler. Nice improvement, even
> though optional resume will be still missing :(
>
> I had posted a wish list a couple years ago, most of which doesn't appear to
> make its way in. The most important for my programming are:
> - local include (make an identifier visible to the including file only)
This is already in the language. Any non-global identifier declared
in an include file, and not inside a routine, is visible to the
routines in that include file and nowhere else.
> - Allow PBR in routines, using some easy to spot syntax so that the
> possibility for a var to be modified is not unpredictable;
This is very unlikely to happen. RDS is philosophically opposed to PBR.
> - Negative index tin strings;
We have been promised the '$' symbol that when used within [] represents
the length of the sequence.
a = b[$] -- get the last element
c = b[$-1 .. $] -- get the last two elements.
> - call functions as procedure when they modify their first arg, so that
>
> someMeaningfulLongName=append(someMeaningfulLongName,something)
>
> may become
>
> someMeaningfulLongName=append(_,something)
> or
> someMeaningfulLongName.append(something)
> or
> append(someMeaningfulLongName,something)
This would be nice syntactic sugar as it is such a common idiom in Eu.
> - Something I had not mentioned before: assume i+3 falls of the valid indexes
> of sequence s. The current behaviour is that
>
> if s[i+3]<3 then...
>
> crashes as the bound check fails. But no logical condition holds true when
> some of its args doesn't exist. As a result, it would be much simpler to code
> if any such test quietly returned false.
>
> Thus, we'd have, whenever x doesn't exist: x<y = x=y = x>y = 0. Not a problem,
>
> as x doesn't exist...
A guaranteed source of bugs, for sure.
One could however use a function to check index validity before using.
Like ...
if valid(s,i+3) and s[i+3]<3 then..
if valid(s,{b,c}) then
a = s[b..c]
end if
where 'valid' is defined as ...
function valid(sequence s, object x)
if integer(x) then
return x >= 1 and x <= length(s)
end if
if length(x) = 0 then
return 1
end if
if x[1] >= 1 and x[1] <= length(s) and valid(s, x[2..$]) then
return 1
else
return 0
end if
end function
--
Derek Parnell
Melbourne, Australia
4. Re: What's new in 2.5?
>>- local include (make an identifier visible to the including file only)
>
>
> This is already in the language. Any non-global identifier declared
> in an include file, and not inside a routine, is visible to the
> routines in that include file and nowhere else.
>
>
Ok, let me restate it. What is missing is a way for the including file, and no
one else but the included file,
to see globals in the included file, so as not to pollute the "universal"
namespace, generating name clashes.
There are several approaches to solve this:
-define a "nonlocal" (or whatever) keyword to qualify variables that are to be
seen from the current file and any directly including file only;
-define "scopes" as namespaces with no communication with the 'default)
namespace. Currently "include ... as" creates two identifiers (myid and
name:myid).
-define an "import ... as" statement so as the imported file's globals are
visible from the importing file onl.
-and probably more.
At least, all these can't break any existing code. I'd be satisfied with any
of the above.
>
>
>>> - Something I had not mentioned before: assume i+3 falls of the valid
>>> indexes
>>> of sequence s. The current behaviour is that
>>>
>>> if s[i+3]<3 then...
>>>
>>> crashes as the bound check fails. But no logical condition holds true when
>>> some of its args doesn't exist. As a result, it would be much simpler to
>>> code
>>> if any such test quietly returned false.
>>>
>>> Thus, we'd have, whenever x doesn't exist: x<y = x=y = x>y = 0. Not a
>>> problem,
>>> as x doesn't exist...
>
>
> A guaranteed source of bugs, for sure.
>
> One could however use a function to check index validity before using.
> Like ...
>
> if valid(s,i+3) and s[i+3]<3 then..
>
> if valid(s,{b,c}) then
> a = s[b..c]
> end if
>
> where 'valid' is defined as ...
>
> function valid(sequence s, object x)
> if integer(x) then
> return x >= 1 and x <= length(s)
> end if
> if length(x) = 0 then
> return 1
> end if
> if x[1] >= 1 and x[1] <= length(s) and valid(s, x[2..$]) then
> return 1
> else
> return 0
> end if
> end function
>
> -- Derek Parnell Melbourne, Australia
Oh sure, and that's what one has to do. That's a major source of errors
designing the function or just forgetting the preliminary test, plus the
coding overhead.
As an answer to the "this will hide bugs" issue, there might be the addition
of a new keyword, say "ifx". "(els)ifx" is to behave just like "if", except
that it returns false when some conditional expression fails to evaluate.
This way, the of statement is not modified,, andthe benefits of useless data
validation may be bypassed. I say "useless" since the coder has to supply a
check that the interpreter will carry out anyway. Unless it cleverly optimizes
away, of course :).
Further, any undefined index real bug will show up anyway, most likelly in the
same conditional block, when attempting to read or write from a nonexistant
element, which must remain an error condition in a nonconditional statement.
This challenges the very idea that the proposed change will hide bugs.
CChris
5. Re: What's new in 2.5?
Christian Cuvier wrote:
<big snip>
> As an answer to the "this will hide bugs" issue, there might be the addition
> of a new keyword, say "ifx". "(els)ifx" is to behave just like "if", except
> that it returns false when some conditional expression fails to evaluate.
> This way, the of statement is not modified,, andthe benefits of useless data
> validation may be bypassed. I say "useless" since the coder has to supply a
> check that the interpreter will carry out anyway. Unless it cleverly optimizes
> away, of course :).
>
> Further, any undefined index real bug will show up anyway, most likelly in the
> same conditional block, when attempting to read or write from a nonexistant
> element, which must remain an error condition in a nonconditional statement.
When a subscript error will show up anyway, what would then be the
advantage of your proposal? Sorry, it seems that I don't get the point ..
> This challenges the very idea that the proposed change will hide bugs.
> CChris
Regards,
Juergen
6. Re: What's new in 2.5?
----- Original Message -----
From: "Christian Cuvier" <Christian.CUVIER at agriculture.gouv.fr>
To: <EUforum at topica.com>
Sent: Tuesday, September 07, 2004 5:24 AM
Subject: Re: What's new in 2.5?
>
>
> >>- local include (make an identifier visible to the including file only)
> >
> >
> > This is already in the language. Any non-global identifier declared
> > in an include file, and not inside a routine, is visible to the
> > routines in that include file and nowhere else.
> >
> >
> Ok, let me restate it. What is missing is a way for the including file,
and no
> one else but the included file,
> to see globals in the included file, so as not to pollute the "universal"
> namespace, generating name clashes.
>
> There are several approaches to solve this:
> -define a "nonlocal" (or whatever) keyword to qualify variables that are
to be
> seen from the current file and any directly including file only;
> -define "scopes" as namespaces with no communication with the 'default)
> namespace. Currently "include ... as" creates two identifiers (myid and
> name:myid).
> -define an "import ... as" statement so as the imported file's globals are
> visible from the importing file onl.
> -and probably more.
>
> At least, all these can't break any existing code. I'd be satisfied with
any
> of the above.
> >
> >
> >>> - Something I had not mentioned before: assume i+3 falls of the valid
indexes
> >>> of sequence s. The current behaviour is that
> >>>
> >>> if s[i+3]<3 then...
> >>>
> >>> crashes as the bound check fails. But no logical condition holds true
when
> >>> some of its args doesn't exist. As a result, it would be much simpler
to code
> >>> if any such test quietly returned false.
> >>>
> >>> Thus, we'd have, whenever x doesn't exist: x<y = x=y = x>y = 0. Not a
problem,
> >>> as x doesn't exist...
> >
> >
> > A guaranteed source of bugs, for sure.
> >
> > One could however use a function to check index validity before using.
> > Like ...
> >
> > if valid(s,i+3) and s[i+3]<3 then..
> >
> > if valid(s,{b,c}) then
> > a = s[b..c]
> > end if
> >
> > where 'valid' is defined as ...
> >
> > function valid(sequence s, object x)
> > if integer(x) then
> > return x >= 1 and x <= length(s)
> > end if
> > if length(x) = 0 then
> > return 1
> > end if
> > if x[1] >= 1 and x[1] <= length(s) and valid(s, x[2..$]) then
> > return 1
> > else
> > return 0
> > end if
> > end function
> >
> > -- Derek Parnell Melbourne, Australia
>
> Oh sure, and that's what one has to do. That's a major source of errors
> designing the function or just forgetting the preliminary test, plus the
> coding overhead.
> As an answer to the "this will hide bugs" issue, there might be the
addition
> of a new keyword, say "ifx". "(els)ifx" is to behave just like "if",
except
> that it returns false when some conditional expression fails to evaluate.
> This way, the of statement is not modified,, andthe benefits of useless
data
> validation may be bypassed. I say "useless" since the coder has to supply
a
> check that the interpreter will carry out anyway. Unless it cleverly
optimizes
> away, of course :).
>
> Further, any undefined index real bug will show up anyway, most likelly in
the
> same conditional block, when attempting to read or write from a
nonexistant
> element, which must remain an error condition in a nonconditional
statement.
> This challenges the very idea that the proposed change will hide bugs.
> CChris
>
>From what I've read.
This if exist() type of thing is more than laziness. You are promoting a
bad
coding style. eh, so I created a vairable I don't need or use. No big
deal.
Just ignore me, I'm stupid. So you want the computer to be smarter than
you because you simply want to be lazy and not pay ANY attention to the
mess you leave behind. Sure, just cleanup behind me EVERY time you run.
yeah, that sounds real mature.
Maybe I'm just not understanding your suggestion.
unkmar
7. Re: What's new in 2.5?
Christian Cuvier wrote:
>
> >>- local include (make an identifier visible to the including file only)
> >
> >
> > This is already in the language. Any non-global identifier declared
> > in an include file, and not inside a routine, is visible to the
> > routines in that include file and nowhere else.
> >
> >
> Ok, let me restate it. What is missing is a way for the including file, and no
>
> one else but the included file,
> to see globals in the included file, so as not to pollute the "universal"
> namespace, generating name clashes.
Oh okay, I get you now. You would like to define an identifier in a file
such that when that file is included, only the including file and the
included file could see the identifier.
I can see how this would be useful for breaking up an otherwise
monolithic library (eg. win32lib). It would mean that if
someone included "win32lib.ew" they wouldn't see those special
identifiers that were defined inside the files that win32lib itself
includes. Very nice.
> There are several approaches to solve this:
> -define a "nonlocal" (or whatever) keyword to qualify variables that are to be
>
> seen from the current file and any directly including file only;
> -define "scopes" as namespaces with no communication with the 'default)
> namespace. Currently "include ... as" creates two identifiers (myid and
> name:myid).
> -define an "import ... as" statement so as the imported file's globals are
> visible from the importing file onl.
> -and probably more.
Yes there are...
- In the file to be included declare the identifier with 'export' rather
than 'global'. eg.
export sequence w32KnownControls
> At least, all these can't break any existing code. I'd be satisfied with any
> of the above.
> >>> - Something I had not mentioned before: assume i+3 falls of the valid
> >>> indexes
> >>> of sequence s. The current behaviour is that
> >>>
> >>> if s[i+3]<3 then...
> >>>
> >>> crashes as the bound check fails. But no logical condition holds true when
> >>>
> >>> some of its args doesn't exist. As a result, it would be much simpler to
> >>> code
> >>> if any such test quietly returned false.
> >>>
> >>> Thus, we'd have, whenever x doesn't exist: x<y = x=y = x>y = 0. Not a
> >>> problem,
>
> >>> as x doesn't exist...
> >
> >
> > A guaranteed source of bugs, for sure.
> >
[snip]
> Oh sure, and that's what one has to do.
> That's a major source of errors
> designing the function or just forgetting the preliminary test, plus the
> coding overhead.
"major"? Are you sure of that?
> As an answer to the "this will hide bugs" issue,
I said "source of bugs" not "this will hide bugs". But anyway, go on ..
>there might be the addition
> of a new keyword, say "ifx". "(els)ifx" is to behave just like "if", except
> that it returns false when some conditional expression fails to evaluate.
> This way, the of statement is not modified,, andthe benefits of useless data
> validation may be bypassed. I say "useless" since the coder has to supply a
> check that the interpreter will carry out anyway. Unless it cleverly optimizes
>
> away, of course :).
This seems to assume that the coder is not so concerned with what exactly
is wrong, just that something is wrong. Something like ...
ifx s[i+3] then
Abort("Something is wrong with the line above")
else
a = s[i+3]
end if
> Further, any undefined index real bug will show up anyway, most likelly in the
>
> same conditional block, when attempting to read or write from a nonexistant
> element, which must remain an error condition in a nonconditional statement.
> This challenges the very idea that the proposed change will hide bugs.
It does? Is this below a bug or not?
sequence y y = "derek"
ifx not(y = "frank") then
ProcA(y)
end if
In your scheme, ProcA would always be called regardless of what value 'y'
holds.
--
Derek Parnell
Melbourne, Australia
8. Re: What's new in 2.5?
>
>>As an answer to the "this will hide bugs" issue, there might be the addition
>>of a new keyword, say "ifx". "(els)ifx" is to behave just like "if", except
>>that it returns false when some conditional expression fails to evaluate.
>>This way, the of statement is not modified,, andthe benefits of useless data
>>validation may be bypassed. I say "useless" since the coder has to supply a
>>check that the interpreter will carry out anyway. Unless it cleverly
>>optimizes
>>away, of course :).
>>
>>Further, any undefined index real bug will show up anyway, most likelly in
>>the
>>same conditional block, when attempting to read or write from a nonexistant
>>element, which must remain an error condition in a nonconditional statement.
>
>
> When a subscript error will show up anyway, what would then be the
> advantage of your proposal? Sorry, it seems that I don't get the point ..
>
Overlooking the fact that something could not evaluate either is or is not the
proper solution to any given programming problem.
The current operation of the if statement forces you to add extra tests
whatever the answer. As these tests are performed by the interpreter anyway,
this is a waste of time and CPU, plus the errors involved in writing the
tests. In the ifx scheme, you could keep using it anyway.
With the proposed ifx, the alternative is more palatable:
- If failure to evaluate translating as false is correct, you won't have to
code a test the interpreter performs anyway: clearer code, less bugs, a few
cycles less.
- If it is not, then the issue raised in the snip was that it would allow some
bugs to go unnoticed. Sure, the failure to evaluate will not crash the ifx
statement, but it will crash another one nearby.
Bottom line: you don't lose coding security, and you spare some coding,
getting clearer code. That was the point.
Btw, this scheme extends beyond out of range indexes. "ifx sqrt(x)=y then..."
would just be a false conditional if x=-1.
CChris
>
>>This challenges the very idea that the proposed change will hide bugs.
>>CChris
>
>
> Regards,
> Juergen
>
9. Re: Re: What's new in 2.5?
[yet more snippage]
>>That's a major source of errors
>>> designing the function or just forgetting the preliminary test, plus the
>>> coding overhead.
>
>
> "major"? Are you sure of that?
>
AFAIC yes. Note that I didn't say THE major cause.
> This seems to assume that the coder is not so concerned with what exactly
> is wrong, just that something is wrong. Something like ...
>
> ifx s[i+3] then
> Abort("Something is wrong with the line above")
> else
> a = s[i+3]
> end if
There's a lot of situations where you are only concerned by: does this
statement make sense and hold? The latter depends on a yes answer to the
first. The if/while statement forces you to separate the two (getting three
states: makes no sense, true, false), while this is less often than not
necessary.
In most of the case I think of, the Abort(...) line would be an exit statement
of sorts.
>
>
>>> Further, any undefined index real bug will show up anyway, most likelly in
>>> the
>>> same conditional block, when attempting to read or write from a nonexistant
>>> element, which must remain an error condition in a nonconditional statement.
>>>
>>> This challenges the very idea that the proposed change will hide bugs.
>
>
> It does? Is this below a bug or not?
>
>
> sequence y y = "derek"
> ifx not(y = "frank") then
> ProcA(y)
> end if
>
> In your scheme, ProcA would always be called regardless of what value 'y'
> holds.
>
>
> -- Derek Parnell Melbourne, Australia
Wrong. y="frank" does have a {0,0,0,0,1} value. not will turn this into
{1,1,1,1,0}. The problem is, that value isn't either atomic true or false, and
the statement must error out.
Compare with:
sequence y y = "derekp"
ifx not(y = "frank") then
ProcA(y)
end if
There, the = logical test fails to evaluate because of the length mismatch,
and the whole conditional is false, regardless of any other stuff appearing
between "ifx" and "then". ProcA() is not executed either.
Note that this scenario falls a bit outside of the intended use, which is to
recover when statements that may not fail do. Because of the residual crash
case, the construct would be less valuable here.
I regularly wind out writing:
if equal(seq[i..j],sth) then...
but j may fall off bounds, and the statement is obviously not true. Out of
frustration, I now peruse
function Equal(sequence s,integer i,integer j,sequence x)
integer l l=length(x)
if i<1 or j<1 or j+l>length(s) then return 0
else return equal(s[i..j],x)
end if
end function
No crash now, but does double duty with the interpreter. And I have to never
forget to use it rather than simpler code that will likely fail.
See how "ifx s[i..j]=x then..." would help?
CChris
10. Re: Re: What's new in 2.5?
Christian Cuvier wrote:
> I regularly wind out writing:
> if equal(seq[i..j],sth) then...
> but j may fall off bounds, and the statement is obviously not true. Out of
> frustration, I now peruse
>
> }}}
<eucode>
> function Equal(sequence s,integer i,integer j,sequence x)
> integer l l=length(x)
> if i<1 or j<1 or j+l>length(s) then return 0
> else return equal(s[i..j],x)
> end if
> end function
> </eucode>
{{{
>
> No crash now, but does double duty with the interpreter. And I have to never
> forget to use it rather than simpler code that will likely fail.
> See how "ifx s[i..j]=x then..." would help?
This gives me an idea for a new feature for Euphoria 2.6 (adding it to 2.5 would
probably require too much time to implement and test right now):
a soft-slice operator: it works just like the normal slice operator, but doesn't
throw an error. Instead, it tries to return a slice that is as close as possible.
Example:
sequence s1, s2
s1 = "This is a very long string."
s2 = s1[11...1000] -- soft slice
-- s2 should now be: "very long string"
That would solve your Equal-problem.
--
tommy online: http://users.telenet.be/tommycarlier
Euphoria Message Board: http://uboard.proboards32.com
11. Re: What's new in 2.5?
>Christian Cuvier wrote:
>> Ok, let me restate it. What is missing is a way for the including file, and
>> no
>> one else but the included file,
>> to see globals in the included file, so as not to pollute the "universal"
>> namespace, generating name clashes.
How about:
include file as namespace
...
hide(namespace)
The reason I suggest this is that RDS Eu (and Posetf when I get round
to it) must know which part of the global symbol table to scan when it
finds a "namespace:<whatever>" reference, so it should be relatively
easy to do. The globals will still exist (for debugging/ex.err) but
will be skipped during parsing, avoiding name clashes.
Regards
Pete
PS I may have previously implied that named scopes might apply to
local identifiers. They don't. Namespaces only ever apply to the
global symbol table.
12. Re: What's new in 2.5?
Christian Cuvier wrote:
> With the proposed ifx, the alternative is more palatable:
> - If failure to evaluate translating as false is correct, you won't have to
> code a test the interpreter performs anyway: clearer code, less bugs, a few
> cycles less.
>
> - If it is not, then the issue raised in the snip was that it would allow some
>
> bugs to go unnoticed. Sure, the failure to evaluate will not crash the ifx
> statement, but it will crash another one nearby.
>
> Bottom line: you don't lose coding security, and you spare some coding,
> getting clearer code. That was the point.
>
> Btw, this scheme extends beyond out of range indexes. "ifx sqrt(x)=y then..."
> would just be a false conditional if x=-1.
Perhaps I don't understand this, but aren't you talking about something
which should really be handled with a try...catch type of construct?
In your example
if s[i+3] < 3 then
you say that, given a sequence with 3 items, reading beyond the end
of the sequence should return false.
My exmaple:
s = {TRUE, FALSE, TRUE}
if s[4] then ....
Returning either FALSE or TRUE for s[4] would be a very big mistake,
with possible major repercussions.
Irv
13. Re: What's new in 2.5?
On 8 Sep 2004 11:52:07 +0200, Christian Cuvier
<Christian.CUVIER at agriculture.gouv.fr> wrote:
>Btw, this scheme extends beyond out of range indexes. "ifx sqrt(x)=y then..."
>would just be a false conditional if x=-1.
This is exception handling under a different name. Instead of:
ifx sqrt(x)=y then
<code>
end ifx
you want:
try
if sqrt(x)=y then
<code>
end if
catch
<do nothin>
end try
I think your best bet is to wait for 2.5 and see if you can add this
handling yourself. Of course you might want to use ifx as a shorthand
notation, but once you allow this on an if statement, you will want
the same handling on while loops, for loops, assignments, procedure
calls, function calls, ......
Regards,
Pete
14. Re: Re: What's new in 2.5?
>>Btw, this scheme extends beyond out of range indexes. "ifx sqrt(x)=y then..."
>>> would just be a false conditional if x=-1.
>
>
> Perhaps I don't understand this, but aren't you talking about something
> which should really be handled with a try...catch type of construct?
Answer is: that's cleaner if the catch handler may resume program execution
after taking corrective action (this may or may not apply, and includes
clearing an exception flag or skipping an unsafe code block). The exact answer
strongly depends on the particular program layout.
The idea is: nil and false are definitely distinct logical concepts. However,
they share the property that none is true. Having the option to use this would
clarify coding.
Second idea: the runtime engine performs some checks of its own. Instead of
performing them a second time, just tell the interpreter how you want it to
react. I wouldn't advise making such a strategy a with+option: it must be a
case by case coder decision. And sometimes it may prove a very big mistake
indeed.
CChris
15. Re: What's new in 2.5?
> On 8 Sep 2004 11:52:07 +0200, Christian Cuvier
> <Christian.CUVIER at agriculture.gouv.fr> wrote:
>
>
>>>Btw, this scheme extends beyond out of range indexes. "ifx sqrt(x)=y then..."
>>>
>>>would just be a false conditional if x=-1.
>
>
> This is exception handling under a different name. Instead of:
>
> ifx sqrt(x)=y then
> <code>
> end ifx
>
> you want:
>
> try
> if sqrt(x)=y then
> <code>
> end if
> catch
> <do nothin>
> end try
>
> I think your best bet is to wait for 2.5 and see if you can add this
> handling yourself. Of course you might want to use ifx as a shorthand
> notation, but once you allow this on an if statement, you will want
> the same handling on while loops,
whilex is a needed addition indeed.
> for loops,
hmmm... I'd rather oush for a wfor; then wforx might be more relevant.
> assignments,
if rhs doesn't exist, don't assign. Sounds neat, but there are people out
there woh don't like this.
> procedure
> calls, function calls, ......
>
I can remember your reluctant view of preventive action being taken by having
a hook monitor the arglist. This would help implementing default routine
params, for instance. Corrective action is seldom better than prevention.
> Regards,
> Pete
Bottom line: you are right, as long as the handler can resume program
execution. And I'm afraid I read posts in the opposite direction by RC.
CChris
16. Re: What's new in 2.5?
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Sep 08, 2004
-
Last edited Sep 09, 2004
On 8 Sep 2004 17:59:51 +0200, Christian Cuvier
<Christian.CUVIER at agriculture.gouv.fr> wrote:
<snip>
>I can remember your reluctant view of preventive action being taken by having
>a hook monitor the arglist.
And I still believe that. The proposal that exception handling is in
general a good programming practice (although common) is usually based
on a misunderstanding. If exceptions occur more than once in about 600
times, then it will always be much slower; or of course if the code
saving is less than the frame costs, which are often fairly high.
There are a few cases where it is better, for example rather than
check for an unassigned variable on *every* statement, trap the
exception attempting to (eg) read/write address #FFFFFFFC.
There is also a case for using a badly written 3rd party library and
needing to recover from the exceptions it should not throw.
And, of course, you couldn't really write a machine-level debugger
without them, least not one you could attach while the program was
already running.
But in *general*, always prevent errors, not cure them, as you said.
>This would help implementing default routine params, for instance.
You lost me. Care to elaborate?
>
>Bottom line: you are right, as long as the handler can resume program
>execution. And I'm afraid I read posts in the opposite direction by RC.
I've already publicly said RC should concentrate on a simple final
exception handler to allow some degree of cleanup before the program
terminates (not that I've tried the win32lib thing), before launching
into full-blown structured exception handling, which is complicated.
Regards,
Pete
17. Re: What's new in 2.5?
>>This would help implementing default routine params, for instance.
>
> You lost me. Care to elaborate?
>
A routine whose arglist might need runtime adjustment would be monitored, and
somme action taken if needed, like:
- if an atom x appears where a sequence is expected,, replace by whatever is
appropriate, often {x}
- if some parm(s) are missing, give them some predefined values.
etc
Of course, the gook has to be programmed, just like a hook handler in Wondows.
And it might be shared by various routines, and a routine may not have the
same handler alwaus, etc.
>
>>>
>>>Bottom line: you are right, as long as the handler can resume program
>>>execution. And I'm afraid I read posts in the opposite direction by RC.
>
> I've already publicly said RC should concentrate on a simple final
> exception handler to allow some degree of cleanup before the program
> terminates (not that I've tried the win32lib thing), before launching
> into full-blown structured exception handling, which is complicated.
>
> Regards,
> Pete
The 2.5 final cleanup handler IS needed and solves some real problems, but not
the ones I'm most concerned with.
CChris
