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.
> 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 prote
> 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
> /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/lo
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
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
con
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
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
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
Gregg Irwin napsal(a):
>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
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
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
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
You mean, you think refinements, even if specified after /local,
should still become the function's refinements ?
Anton.
> 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 /loc
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>
14 matches
Mail list logo
