Mailing list home
  Find posts   Help

Latest messageRecent messages

Other threads:
 Prev: Re: ANN: Rugby again, whiping out SOAP
 Next: Re: System/Words

 Random thread

Indexes:
 By topic
 By date
 By author
 By subject
Join the Mailing List....
AccessibilityAbout / FAQ
Member's loungeContact/FeedbackOther REBOL links
Membership:
member name

password

Remember?

Not a member? Please join
8-Sep 23:17 UTC
[0.118] 17.21k
Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

highfun.r

 [1/16] from: lmecir:mbox:vol:cz at: 7-Sep-2001 14:10


The latest version reflects Larry's results on speed of closures. http://www.sweb.cz/LMecir/highfun.r Regards Ladislav

 [2/16] from: lmecir:mbox:vol:cz at: 23-Sep-2001 20:27


Hi Rebols, just posted a new version of http://www.sweb.cz/LMecir/highfun.r available at my Rebsite too. This version accepts the Holger's suggestion to not use any FUNC-made function's context words after the return. Moreover, I repaired some minor glitches (And probably made new ones, as mr. Murphy states?) and used Parse to improve the readability and speed where possible. Regards Ladislav

 [3/16] from: lmecir:mbox:vol:cz at: 19-Nov-2001 12:54


Hi all, a new version of http://www.sweb.cz/LMecir/highfun.r is available. It contains a new LOCALS? function and a generalized version of the APPLY function. (To Gregg: could you test it, please?) Cheers Ladislav

 [4/16] from: greggirwin:mindspring at: 19-Nov-2001 11:34


Hi Ladislav, << a new version of http://www.sweb.cz/LMecir/highfun.r is available. It contains a new LOCALS? function and a generalized version of the APPLY function. (To Gregg: could you test it, please?) >> Just took a quick run at LOCALS? and wanted to confirm the results. It is expected to return all parameters, refinements, and local words as words because of how you're using it in APPLY, correct?
>> locals? func [a b /local c d] []
== [a b local c d]
>> locals? func [a b /r /local c d] []
== [a b r local c d] --Gregg

 [5/16] from: lmecir:mbox:vol:cz at: 19-Nov-2001 21:09


Hi Gregg, yes, LOCALS? returns a block containing all words that can be found in the local context of the function. Because refinements can be used as local words too, they are included. What I mainly wanted was you to try if the new /N refinement of APPLY works as you expect it to. I suppose you did. Thanks for helping. << a new version of http://www.sweb.cz/LMecir/highfun.r is available. It contains a new LOCALS? function and a generalized version of the APPLY function. (To Gregg: could you test it, please?) >> Just took a quick run at LOCALS? and wanted to confirm the results. It is expected to return all parameters, refinements, and local words as words because of how you're using it in APPLY, correct?
>> locals? func [a b /local c d] []
== [a b local c d]
>> locals? func [a b /r /local c d] []
== [a b r local c d] --Gregg

 [6/16] from: greggirwin:mindspring at: 19-Nov-2001 14:58


Hi Ladislav, << What I mainly wanted was you to try if the new /N refinement of APPLY works as you expect it to. I suppose you did. >> I tried it with basic named arguments and it worked fine. I played a little bit and couldn't figure out if I could, or how, to use both /r and /n together. For example, given the folowing function: test-fn: func [a b /ref-c c /ref-d d] [ print ["A:" a] print ["B:" b] if ref-c [ print ["/C:" c] ] if ref-d [ print ["/D:" d] ] ] Could I specify both /ref-c and /ref-d, but then supply *their* arguments as named arguments or do named arguments apply only to standard function parameters. --Gregg

 [7/16] from: lmecir:mbox:vol:cz at: 20-Nov-2001 0:18


Thanks for feedback, I included your example to highfun.r << What I mainly wanted was you to try if the new /N refinement of APPLY works as you expect it to. I suppose you did. >> <<Gregg>> I tried it with basic named arguments and it worked fine. I played a little bit and couldn't figure out if I could, or how, to use both /r and /n together. For example, given the folowing function: test-fn: func [a b /ref-c c /ref-d d] [ print ["A:" a] print ["B:" b] if ref-c [ print ["/C:" c] ] if ref-d [ print ["/D:" d] ] ] Could I specify both /ref-c and /ref-d, but then supply *their* arguments as named arguments or do named arguments apply only to standard function parameters. --Gregg

 [8/16] from: lmecir:mbox:vol:cz at: 20-Nov-2001 0:43


Hi, I don't know what happened to the site, here is the example: test-fn: func [a b /ref-c c /ref-d d] [ print ["A:" a] print ["B:" b] if ref-c [ print ["C:" c] ] if ref-d [ print ["D:" d] ] ] apply/r/n :test-fn [ref-d ref-c] [d: 1 c: 2 b: 3 a: 4]

 [9/16] from: greggirwin:mindspring at: 19-Nov-2001 21:14


Hi Ladislav, Thanks for the example! I'm not sure if it's working right though. It doesn't look like the refinement arguments are being handled correctly. The final example is correct, the first two are not, unless I'm missing something.
>> apply/r/n :test-fn [ref-d ref-c] [d: 1 c: 2 b: 3 a: 4]
A: 4 B: 3 C: 1 D: 2
>> apply/r/n :test-fn [ref-d ref-c] [c: 2 d: 1 b: 3 a: 4]
A: 4 B: 3 C: 1 D: 2
>> apply/r/n :test-fn [ref-c ref-d] [c: 1 d: 2 b: 3 a: 4]
A: 4 B: 3 C: 1 D: 2 --Gregg

 [10/16] from: lmecir:mbox:vol:cz at: 20-Nov-2001 9:30


Hi Gregg, I corrected the behaviour, could you check it once again? Thanks Ladislav <<Gregg>> Hi Ladislav, Thanks for the example! I'm not sure if it's working right though. It doesn't look like the refinement arguments are being handled correctly. The final example is correct, the first two are not, unless I'm missing something. apply/r/n :test-fn [ref-d ref-c] [d: 1 c: 2 b: 3 a: 4] A: 4 B: 3 C: 1 D: 2
>> apply/r/n :test-fn [ref-d ref-c] [c: 2 d: 1 b: 3 a: 4]
A: 4 B: 3 C: 1 D: 2
>> apply/r/n :test-fn [ref-c ref-d] [c: 1 d: 2 b: 3 a: 4]
A: 4 B: 3 C: 1 D: 2 --Gregg

 [11/16] from: greggirwin:mindspring at: 20-Nov-2001 10:53


Hi Ladislav, << I corrected the behaviour, could you check it once again? >> Looks good for well formed code! I managed to get some invalid results by feeding it values that were mis-matched with the refinements passed.
>> apply/r/n :test-fn [ref-c ref-d] [d: 2 b: 3 a: 4]
** Script Error: f is missing its d argument ** Near: local-return f/ref-c/ref-d action [4] action
>> apply/r/n :test-fn [ref-c] [d: 2 b: 3 a: 4]
A: 4 B: 3 C: 2
>> apply/r/n :test-fn [ref-d] [c: 1 d: 2 b: 3 a: 4]
A: 4 B: 3 D: 1 Thanks! --Gregg

 [12/16] from: lmecir:mbox:vol:cz at: 20-Nov-2001 21:18


Well, now the question is, whether we prefer the speed or the safety... which one is your favourite? Thanks Ladislav <<Gregg>> Looks good for well formed code! I managed to get some invalid results by feeding it values that were mis-matched with the refinements passed.
>> apply/r/n :test-fn [ref-c ref-d] [d: 2 b: 3 a: 4]
** Script Error: f is missing its d argument ** Near: local-return f/ref-c/ref-d action [4] action
>> apply/r/n :test-fn [ref-c] [d: 2 b: 3 a: 4]
A: 4 B: 3 C: 2
>> apply/r/n :test-fn [ref-d] [c: 1 d: 2 b: 3 a: 4]
A: 4 B: 3 D: 1 Thanks! --Gregg

 [13/16] from: lmecir:mbox:vol:cz at: 20-Nov-2001 23:49


Hi myself, <<Ladislav>> Well, now the question is, whether we prefer the speed or the safety... which one is your favourite? <</Ladislav>> Instead of trying to justify the bug I should have repaired it. That's why I've done so. Cheers Ladislav

 [14/16] from: greggirwin:mindspring at: 20-Nov-2001 17:33


<< Well, now the question is, whether we prefer the speed or the safety... which one is your favourite? >> Well, if it isn't right, it doesn't matter how fast it runs. :) If the speed hit is significant, just put in a note about that (and maybe keep the faster implementation around for risk-takers). When people need performance, they can always go a more direct route IMO. --Gregg

 [15/16] from: lmecir:mbox:vol:cz at: 21-Nov-2001 22:54


Hi all, I had to repair the Refined function, it still contained a bug. Sorry for any inconveniences. Cheers Ladislav

 [16/16] from: lmecir:mbox:vol:cz at: 4-Nov-2001 0:22


Hi all, just posted the newest version of %highfun.r to my site (Reb: Ladislav, http://www.sweb.cz/LMecir). I decided to generalize APPLY (works with refinements now), have changed its spec and allowed it to take ANY value as its first argument. At the same time I decided to leave off DO-PATH, because APPLY has got all the functionality that might be needed. Any suggestions/corrections/feedback welcome. Ladislav