Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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