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

Functions, /local and refinements

 [1/15] from: lmecir::mbox::vol::cz at: 15-May-2004 15:08


Hi, I found:
>> f: func ["aa" /local x /a aa] [] >> help f
USAGE: F DESCRIPTION: aa F is a function value.
>> g: func ["aa" /a aa /local x] [] >> help g
USAGE: G /a aa DESCRIPTION: aa G is a function value. REFINEMENTS: /a aa -- (Type: any) Is there really such a big difference between F and G? -L

 [2/15] from: g:santilli:tiscalinet:it at: 15-May-2004 15:33


Hi Ladislav, On Saturday, May 15, 2004, 3:08:40 PM, you wrote: LM> Hi, I found:
>>> f: func ["aa" /local x /a aa] [] >>> help f
LM> USAGE: LM> F LM> DESCRIPTION: LM> aa LM> F is a function value.
>>> g: func ["aa" /a aa /local x] [] >>> help g
LM> USAGE: LM> G /a aa LM> DESCRIPTION: LM> aa LM> G is a function value. LM> REFINEMENTS: LM> /a LM> aa -- (Type: any) LM> Is there really such a big difference between F and G? Of course not, but HELP is just following the convention of /local terminating the argument list... Changing it so that it can find refinements after /local would be no harm, though; however I don't think we should encourage people writing functions that way. ;-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [3/15] from: antonr:lexicon at: 16-May-2004 0:27


You mean, you think refinements, even if specified after /local, should still become the function's refinements ? Anton.

 [4/15] from: lmecir:mbox:vol:cz at: 15-May-2004 16:48


Anton Rolls napsal(a):
>You mean, you think refinements, even if specified after /local, >should still become the function's refinements ? > >Anton. >
I think they do. -L

 [5/15] from: greggirwin:mindspring at: 15-May-2004 10:52


Ladislav et al
>>You mean, you think refinements, even if specified after /local, >>should still become the function's refinements ? >>
LM> I think they do. Wow. I didn't know that. My gut reaction is to agree with Gabriele about what standard style we should use but, if this is legal, it means HELP isn't interpreting things the same way the interpreter does, which should be addressed. i.e. HELP should be fixed. It also might make it easier to dynamically generate added refinements for pre-defined functions. Have to think about it, and we should see if RT will give us a definitive set of rules (or at least tell us if what we discover empirically is valid :). Nice find. -- Gregg

 [6/15] from: lmecir:mbox:vol:cz at: 15-May-2004 20:00


Gregg Irwin napsal(a):
>Ladislav et al >>>You mean, you think refinements, even if specified after /local,
<<quoted lines omitted: 7>>
>means HELP isn't interpreting things the same way the interpreter >does, which should be addressed. i.e. HELP should be fixed.
....snip...
>-- Gregg >
I found it out comparing the behaviour of my Func-like functions with the original and don't know whether I should correct them, but it looks like Carl did it on purpose. -L

 [7/15] from: g:santilli:tiscalinet:it at: 15-May-2004 20:44


Hi Gregg, On Saturday, May 15, 2004, 6:52:46 PM, you wrote: GI> Wow. I didn't know that. My gut reaction is to agree with Gabriele GI> about what standard style we should use but, if this is legal, it GI> means HELP isn't interpreting things the same way the interpreter GI> does, which should be addressed. i.e. HELP should be fixed. The interpreter has never been doing things in any particular way. That is, /LOCAL is just a refinement, like /ALL would, or /WITH, etc. Carl just decided, as a convention, to use the refinement named /LOCAL to define local words; so HELP is just following this convention. As I said, it would make no harm to change HELP, but I'm not really sure it would be worth it...
>> f: func [/local a] [print a] >> f
none
>> f/local 1
1 Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [8/15] from: rotenca:telvia:it at: 15-May-2004 21:04


Hi Gregg,
> means HELP isn't interpreting things the same way the interpreter > does, which should be addressed. i.e. HELP should be fixed.
/local for local var is only a convention set by RT, but indeed there is no difference at all between /local and any other refinements: f: has [a b] [print [local a b]] f/local 1 2 so one could use any refinements for local vars, only help do not know it. --- Ciao Romano

 [9/15] from: greggirwin:mindspring at: 15-May-2004 13:31


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? -- Gregg

 [10/15] from: g:santilli:tiscalinet:it at: 15-May-2004 22:40


Hi Gregg, On Saturday, May 15, 2004, 9:31:51 PM, you wrote: GI> Of course that makes perfect sense, but shouldn't HELP still GI> understand that refinements coming after /local are part of the GI> interface and display them? It surely could; I think it's just that HELP was written with the convention in mind; indeed, there's an: if :item = /local [break] which assumes that /local ends the list of arguments. I think one could replace that with something like: if :item = /local [args: any [find next args refinement! tail args]] (I'm not saying the above would really work, just giving an idea). However, as I said I wouldn't encourage using other refinements after /local; also, maybe we could take this as a feature and use it to create "hidden" refinements that are only used internally and are not really part of the interface... Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [11/15] 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.
<<quoted lines omitted: 6>>
>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

 [12/15] from: moliad:aei:ca at: 15-May-2004 21:40


> 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?
I think it should. when duplicating an arg block which has a local in it, it can be a pain to have to make sure that you INSERT new args before /local (placing the local refinement to it) instead of just appending to it... intermediate users could be duped... -MAx

 [13/15] from: moliad:aei:ca at: 15-May-2004 22:08


> As for refinements put after /local, I can see an advantage to > the current behavior: Undocumented interfaces. It is sometimes
private refinements... I admit its a good idea... sort of goes against what I just said, I guess... what I'd like are private members and methods. As a way to protect copyrighted code... doing a mold on a private item of an object would ignore those items or encrypt them with a key. Then a make object, would need that key to remold the object as it was... Otherwise it stays hidden. I guess it is doable by patching code, but it would be a nice feature by default. I'm sure many of you would like to hide the code from your clients, especially when doing approvals... allowing seamless privacy in selected object components can make this less of a job, especially if you want to keep some level of external control in the code (i.e. text-based code)... -MAx

 [14/15] from: moliad:aei:ca at: 15-May-2004 21:38


> /local for local var is only a convention set by RT, but indeed there is no > difference at all between /local and any other refinements:
that's what I thought... of course some functions add it ('function 'has) when creating the internal func call.
> f: has [a b] [print [local a b]] > f/local 1 2 > > so one could use any refinements for local vars, only help do not know it.
we actualy often do without noticing it... like when we reuse a refinement word that is not set by the user... -MAx

 [15/15] from: greggirwin:mindspring at: 15-May-2004 22:49


Good thoughts, all, on this subject! It seemed like an easy thing to address but, once again, REBOL's flexibility (and our potential creativity) make it a topic deserving deeper consideration. I like the idea of not changing things. :) I like consistency. I like the idea of hidden interfaces. And I really like that you all make me think about this stuff! :) So, my stance is now: don't change anything without further thought. -- Gregg

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted