[REBOL] Re: Functions, /local and refinements
From: brian:hawley at: 15-May-2004 17:20
Hi Gregg,
At 01:31 PM 5/15/04 -0600, you wrote:
>Hi Gabriele,
>
>GS> The interpreter has never been doing things in any particular way.
>GS> That is, /LOCAL is just a refinement, like /ALL would, or /WITH,
>GS> etc. Carl just decided, as a convention, to use the refinement
>GS> named /LOCAL to define local words; so HELP is just following this
>GS> convention. As I said, it would make no harm to change HELP, but
>GS> I'm not really sure it would be worth it...
>
>Of course that makes perfect sense, but shouldn't HELP still
>understand that refinements coming after /local are part of the
>interface and display them?
On the contrary, I think that the current behavior should stand.
The current convention is a simple shortcut that allows us to
pretend that we have local variables as a separate semantic
concept without actually having to implement that concept in the
interpreter. There are lots of things in REBOL that are done in
this way - REBOL only allows safe programming, it doesn't enforce
it much at all.
As for refinements put after /local, I can see an advantage to
the current behavior: Undocumented interfaces. It is sometimes
advantageous to have some implementation details of a function
implemented as optional parameters, but not have these be a part
of the official interface of the function. These refinements
could then be called by related functions (peers) or self-calls
under controlled circumstances, without putting checks in the
code to handle uncontrolled calls from random client code.
For example, I once wrote a script inclusion manager as a script
that defined a single function. The scripts already included by
this function were listed in a persistent block embedded in the
code of the function. When the script of my inclusion manager
was reloaded it checked to see if it was already loaded into
memory and called its old self with a refinement to retrieve the
existing list of scripts, so it wouldn't lose its data. Now that
refinement was really an implementation artifact that was only
meant to be called under those circumstances. It would have been
quite appropriate for me to declare that refinement after /local
to take it out of the public interface - in fact, I could have
reduced the memory requirement of the function by returning the
actual data block instead of a deep copy for safety.
I'm sure that others could come up with their own ways to exploit
the current help conventions as well. And really, if you want to
take a look at undocumented interfaces and other implementation
details you can use the source function.
Brian Hawley
