> Hi Gabriele,
>
> I'm a bit late on this one, but here goes ...
>
> Those were the words of [EMAIL PROTECTED]:
> <...>
> > Or, context should be made a little more flexible, with the
> > ability to add and remove words. Words would no more be added
to
> > system/words; UNSET would remove a word from its context;
words
> > not present in any context would simply be left "unbound"
(causing
> > the error "Word has no value" instead of the current "Word is
not
> > defined in this context"); when setting an unbound word, it
would
> > be added to system/words. A refinement could then be added to
SET
> > to make it possible to add a word to a specific context, so we
> > would gain the ability to easily extend objects, too.
> <...>
>
> This would really be great.
I am afraid, that it would be too complicated. See:
a: 1
b: make object! [
c: 2
d: 3
e: func [f] [
reduce [a c d f]
]
]
b/e 4
What should happen after you enlarge the object context to contain
'a?
>
> > l> *Armed errors:*
> >
> > [...]
> >
> > l> Well, that is one side of reasoning. The other one is,
that
> > l> our code should be able to process values. As long as
errors
> > l> are armed, they are only "second class" values that cannot
be
> > l> handled with normal code without too much complication.
OTOH,
> > l> disarmed Error can be handled with usual code. If we
introduce
> > l> "second class" values, we may introduce complications too.
I
> > l> am pretty sure, that even the Rebol interpreter could be
> > l> simpler and faster without the "second class" values.
> >
> > Changing the way ERROR!s work would cause more compatibility
> > issues, tough; I'd like to hear from other subscribers what
they
> > think about this...
>
> I can't say much about the interpreter here, but _I_ think an
> error is an error, and as such not subject to normal processing.
> I want an error to bang as soon as possible, and if I think I
> know how to handle a specific error, I can always use try [].
> Maybe a disarmed-error! type would be useful at times, though.
>
> Well, that's my opinion after all,
>
>
> regards,
>
> Ingo
>
My reason for suggesting disarmed errors was as follows:
if the error occurs, it surely is fired and everything goes as
expected. But there is a legal way how to obtain an error value:
e: make error! {some error}
f: try some-code
After any of these expressions occurs, you get an error as a
normally computed Rebol value. How would you expect the following
code to behave?
apply1 :make reduce [error! {some error}]
Should it return the computed value, or fire in the middle of
computing, that is, do you prefer:
apply1: func [
{Apply a function to its arguments}
f [any-function!]
blkargs [block!] {Argument values}
/local length statement result
] [
statement: make block! (length: length? blkargs) * 3 + 3
insert statement [set/any 'result f]
repeat i length [
append statement [pick blkargs]
append statement i
]
do statement
get/any 'result
]
>> error? e: apply1 :make reduce [error! {some error}]
** User Error: some error.
** Where: set/any 'result f pick blkargs
or the second one:
apply: func [
{Apply a function to its arguments}
f [any-function!]
blkargs [block!] {Argument values}
/local length statement result
] [
statement: make block! (length: length? blkargs) * 3 + 4
insert statement [error? set/any 'result f]
repeat i length [
append statement [pick blkargs]
append statement i
]
do statement
return get/any 'result
]
>> error? e: apply :make reduce [error! {some error}]
== true
I prefer the second case. Surely, you can write every piece of
your code to take care of such special cases, but you only get
something you could have got for free.
