1. find_from and match_from
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 13, 2007
- 718 views
- Last edited Apr 14, 2007
I've committed find_from and match_from to the svn repository (including changes to the docs). Matt
2. Re: find_from and match_from
- Posted by Robert Craig <rds at RapidEuphoria.com> Apr 13, 2007
- 672 views
- Last edited Apr 14, 2007
Matt Lewis wrote: > I've committed find_from and match_from to the svn repository (including > changes to the docs). Great. I'll update my svn files and do some testing. I'll also add an item to relnotes.htx about this. I should also look at the source file diffs on SourceForge. There are several places where a small change needs to be made when a new built-in is added. It's not as automated as it should be. I'll check if you missed anything. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
3. Re: find_from and match_from
- Posted by Robert Craig <rds at RapidEuphoria.com> Apr 14, 2007
- 679 views
Robert Craig wrote: > Matt Lewis wrote: > > I've committed find_from and match_from to the svn repository (including > > changes to the docs). OK, I updated my svn files, and found a few minor omissions/glitches, corrected them, and checked them in. I also updated the Translator to support find_from and match_from (very similar to find and match). find_from and match_from seem to work now, (interpreter with C-backend or execute.e, and translator) but I haven't had time to test things thoroughly. It didn't look like you got to the point of actually testing, so you should give it a try now. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
4. Re: find_from and match_from
- Posted by Juergen Luethje <j.lue at gmx.de> Apr 14, 2007
- 685 views
Robert Craig wrote: > Robert Craig wrote: >> Matt Lewis wrote: >>> I've committed find_from and match_from to the svn repository (including >>> changes to the docs). > > OK, I updated my svn files, and found a few minor > omissions/glitches, corrected them, and checked them in. > I also updated the Translator to support find_from and > match_from (very similar to find and match). > > find_from and match_from seem to work now, > (interpreter with C-backend or execute.e, and translator) > but I haven't had time to test things thoroughly. > It didn't look like you got to the point of actually testing, > so you should give it a try now. I'm looking forward to have these functions available in Euphoria. Many thanks to both of you! Regards, Juergen
5. Re: find_from and match_from
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 14, 2007
- 673 views
Robert Craig wrote: > > Robert Craig wrote: > > Matt Lewis wrote: > > > I've committed find_from and match_from to the svn repository (including > > > changes to the docs). > > OK, I updated my svn files, and found a few minor > omissions/glitches, corrected them, and checked them in. > I also updated the Translator to support find_from and > match_from (very similar to find and match). > > find_from and match_from seem to work now, > (interpreter with C-backend or execute.e, and translator) > but I haven't had time to test things thoroughly. > It didn't look like you got to the point of actually testing, > so you should give it a try now. Yeah, didn't really test, other than to see if it compiled. I just made a couple of other changes: * Added find_from and e_match_from euphoria.h * Fixed makefile.wat to properly build the library. Matt
6. find_from and match_from
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 20, 2007
- 668 views
I've put a feature request on sourceforge for find_from and match_from: http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785 Text: "Add two built-in functions, find_from and match_from, which work similar to find and match, but add a third parameter, which specifies the place in the sequence to begin looking. If found or matched, the index of the find or match is returned, or zero, if not found or matched to the end of the sequence. This has already been implemented in ooeu (http://sf.net/projects/ooeu), so this is a matter of determining if we want this in Euphoria, not the feasibility or requesting resources for development." Since this is already developed (though not documented)in ooeu, we basically need to decide if this should go into euphoria or not. Matt
7. Re: find_from and match_from
- Posted by Igor Kachan <kinz at peterlink.ru> Mar 20, 2007
- 676 views
Matt Lewis wrote: > I've put a feature request on sourceforge for find_from and match_from: > <a > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a> > > Text: > "Add two built-in functions, find_from and match_from, which work similar to > find and match, but add a third parameter, which specifies the place in the > sequence to begin looking. > > If found or matched, the index of the find or match is returned, or zero, > if not found or matched to the end of the sequence. > > This has already been implemented in ooeu (<a > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>), so > this is a matter of determining if we want this in Euphoria, not the > feasibility or requesting resources for development." > > > Since this is already developed (though not documented)in ooeu, we basically > > need to decide if this should go into euphoria or not. > > Matt Hi Matt, It seems to be very simple to implement this feature just in some library and do not touch 4 different versions of interpreters, translators, binders with their docs etc etc :
-- not tested global function find_from_to(integer N, integer L, object a, sequence b) L = find(a, b[N..L]) if L then return L-1+N else return L end function global function match_from_to(integer N, integer L, sequence a, sequence b) L = match(a,b[N..L]) if L then return L-1+N else return L end function
Any one can redefine the standard find() and match() as these above function just now (ok, after testing and correction) and use them. You do know I'm very and too conservative and lazy guy, so just my $0.02 Regards, Igor Kachan kinz at peterlink.ru
8. Re: find_from and match_from
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Mar 20, 2007
- 682 views
Igor Kachan wrote: > > Matt Lewis wrote: > > > I've put a feature request on sourceforge for find_from and match_from: > > <a > > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a> > > > > Text: > > "Add two built-in functions, find_from and match_from, which work similar to > > find and match, but add a third parameter, which specifies the place in the > > sequence to begin looking. > > > > If found or matched, the index of the find or match is returned, or zero, > > if not found or matched to the end of the sequence. > > > > This has already been implemented in ooeu (<a > > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>), > so</font></i> > > this is a matter of determining if we want this in Euphoria, not the > > feasibility or requesting resources for development." > > > > > > Since this is already developed (though not documented)in ooeu, we basically > > > > need to decide if this should go into euphoria or not. > > > > Matt > > Hi Matt, > > It seems to be very simple to implement this feature > just in some library and do not touch 4 different > versions of interpreters, translators, binders > with their docs etc etc : > > }}} <eucode> > -- not tested > global function find_from_to(integer N, integer L, object a, sequence b) > L = find(a, b[N..L]) > if L then return L-1+N > else return L > end function > > global function match_from_to(integer N, integer L, sequence a, sequence b) > L = match(a,b[N..L]) > if L then return L-1+N > else return L > end function > </eucode> {{{ > > Any one can redefine the standard find() and match() as these > above function just now (ok, after testing and correction) > and use them. > > You do know I'm very and too conservative and lazy guy, > so just my $0.02 > > Regards, > Igor Kachan > kinz at peterlink.ru Very easy and VERY SLOW, because you create a slice just to specify a start and end point, and destroy it on return. Do this a few hundred times in a loop... So the idea is indeed to "touch 4 different > versions of interpreters, translators, binders > with their docs etc etc" so that you can more sensibly just change the bounds of the for loop used internally to find something in a sequence, and set them to N and L, not just 1 and length(s). Hence, find_from() and friends will be faster than find() if N is large, instead of being slower as your code is. CChris
9. Re: find_from and match_from
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 20, 2007
- 699 views
Igor Kachan wrote: > > > It seems to be very simple to implement this feature > just in some library and do not touch 4 different > versions of interpreters, translators, binders > with their docs etc etc : > <snip> Yes, and I've done this myself. It's just really slow (as CChris pointed out already). These are meant to keep the speed of the native functions, but with a very useful addition, especially tasks like string handling. Matt
10. Re: find_from and match_from
- Posted by Juergen Luethje <j.lue at gmx.de> Mar 20, 2007
- 688 views
Matt Lewis wrote: > I've put a feature request on sourceforge for find_from and match_from: > <a > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a> > > Text: > "Add two built-in functions, find_from and match_from, which work similar to > find and match, but add a third parameter, which specifies the place in the > sequence to begin looking. > > If found or matched, the index of the find or match is returned, or zero, > if not found or matched to the end of the sequence. > > This has already been implemented in ooeu (<a > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>), so > this is a matter of determining if we want this in Euphoria, not the > feasibility or requesting resources for development." > > > Since this is already developed (though not documented)in ooeu, we basically > need to decide if this should go into euphoria or not. > > Matt Yes, it should. support += my_vote -- Regards, Juergen
11. Re: find_from and match_from
- Posted by c.k.lester <euphoric at cklester.com> Mar 20, 2007
- 672 views
Matt Lewis wrote: > Igor Kachan wrote: > > It seems to be very simple to implement this feature > > just in some library and do not touch 4 different > > versions of interpreters, translators, binders > > with their docs etc etc : > Yes, and I've done this myself. It's just really slow (as CChris pointed > out already). These are meant to keep the speed of the native functions, > but with a very useful addition, especially tasks like string handling. Aye.
12. Re: find_from and match_from
- Posted by CChris <christian.cuvier at agriculture.gouv.fr> Mar 20, 2007
- 702 views
Juergen Luethje wrote: > > Matt Lewis wrote: > > > I've put a feature request on sourceforge for find_from and match_from: > > <a > > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a> > > > > Text: > > "Add two built-in functions, find_from and match_from, which work similar to > > find and match, but add a third parameter, which specifies the place in the > > sequence to begin looking. > > > > If found or matched, the index of the find or match is returned, or zero, > > if not found or matched to the end of the sequence. > > > > This has already been implemented in ooeu (<a > > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>), > so</font></i> > > this is a matter of determining if we want this in Euphoria, not the > > feasibility or requesting resources for development." > > > > > > Since this is already developed (though not documented)in ooeu, we basically > > need to decide if this should go into euphoria or not. > > > > Matt > > > Yes, it should. > support += my_vote -- > > Regards, > Juergen I support it too. CChris
13. Re: find_from and match_from
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 20, 2007
- 685 views
Matt Lewis wrote: > I've put a feature request on sourceforge for find_from and match_from: > <a > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a> > > Text: > "Add two built-in functions, find_from and match_from, which work similar to > find and match, but add a third parameter, which specifies the place in the > sequence to begin looking. > > If found or matched, the index of the find or match is returned, or zero, > if not found or matched to the end of the sequence. > > This has already been implemented in ooeu (<a > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>), so > this is a matter of determining if we want this in Euphoria, not the > feasibility or requesting resources for development." > > > Since this is already developed (though not documented)in ooeu, we basically > > need to decide if this should go into euphoria or not. I have no objections to this. If you decide to go ahead, please also update the library manual (euphoria\htx subdirectory), keywords.e, etc. Both the code and the documentation can use the current match() and find() as models to base things on. I can take care of relnotes.htm. I see you already added C.K.'s include path request. That's fine. Thanks. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
14. Re: find_from and match_from
- Posted by Igor Kachan <kinz at peterlink.ru> Mar 20, 2007
- 713 views
CChris wrote: > > Igor Kachan wrote: > > > > Matt Lewis wrote: > > > > > I've put a feature request on sourceforge for find_from and match_from: > > > <a > > > href="http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785">http://sourceforge.net/tracker/index.php?func=detail&aid=1684321&group_id=182827&atid=902785</a> > > > > > > Text: > > > "Add two built-in functions, find_from and match_from, which work similar > > > to > > > find and match, but add a third parameter, which specifies the place in > > > the > > > sequence to begin looking. > > > > > > If found or matched, the index of the find or match is returned, or zero, > > > if not found or matched to the end of the sequence. > > > > > > This has already been implemented in ooeu (<a > > > href="http://sf.net/projects/ooeu">http://sf.net/projects/ooeu</a>), > > so</font></i> > > > this is a matter of determining if we want this in Euphoria, not the > > > feasibility or requesting resources for development." > > > > > > > > > Since this is already developed (though not documented)in ooeu, we > > > basically > > > > > > need to decide if this should go into euphoria or not. > > > > > > Matt > > > > Hi Matt, > > > > It seems to be very simple to implement this feature > > just in some library and do not touch 4 different > > versions of interpreters, translators, binders > > with their docs etc etc : > > > > }}} <eucode> > > -- not tested > > global function find_from_to(integer N, integer L, object a, sequence b) > > L = find(a, b[N..L]) > > if L then return L-1+N > > else return L > > end function > > > > global function match_from_to(integer N, integer L, sequence a, sequence b) > > L = match(a,b[N..L]) > > if L then return L-1+N > > else return L > > end function > > </eucode> {{{ > > > > Any one can redefine the standard find() and match() as these > > above function just now (ok, after testing and correction) > > and use them. > > > > You do know I'm very and too conservative and lazy guy, > > so just my $0.02 > > > > Regards, > > Igor Kachan > > kinz at peterlink.ru > > Very easy and VERY SLOW, because you create a slice just to specify a start > and end point, and destroy it on return. Do this a few hundred times in a > loop... > > So the idea is indeed to "touch 4 different > > versions of interpreters, translators, binders > > with their docs etc etc" > so that you can more sensibly just change the > bounds of the for loop used internally to find something in a sequence, > and set them to N and L, not just 1 and length(s). Hence, find_from() and > friends will be faster than find() if N is large, instead of being slower as > your code is. It all depends on ...
function find_from_to(integer N, integer L, object a, sequence b) L=find(a,b[N .. L]) if L then return L-1+N else return L end if end function sequence p,q,z p=repeat(10000,9) q=repeat({}, 10000) for i=1 to length(q) do q[i] = rand(p) end for z=rand(p) atom T, ok T=time() for i=1 to 3000 do ok = find(z, q) end for T=time()-T ? T T=time() for i=1 to 3000 do ok = find_from_to(1,10000,z,q) end for T=time()-T ? T T=time() for i=1 to 3000 do ok = find_from_to(100,1000,z,q) end for T=time()-T ? T
On my 1.8GHz box I got, for example: 2.41 -- pure find() -- full range 12.25 -- find_from_to() -- full range 0.16 -- find_from_to() -- some suspicious range Try and try please to be very sure. Good Luck! Regards, Igor Kachan kinz at peterlink.ru
15. Re: find_from and match_from
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 21, 2007
- 700 views
Robert Craig wrote: > the current match() and find() Robert, I vaguely remember someone saying that a slice doesn't create a new sequence until such time as the slice is actually written to. Is that true? -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
16. Re: find_from and match_from
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 21, 2007
- 698 views
Derek Parnell wrote: > > Robert Craig wrote: > > the current match() and find() > > Robert, I vaguely remember someone saying that a slice doesn't create a new > sequence until such time as the slice is actually written to. Is that true? Not true. I disassembled Igor's example:
function find_from_to(integer N, integer L, object a, sequence b) L=find(a,b[N .. L]) if L then return L-1+N else return L end if end function
Notice line 7, where the slice is created an assigned to the temp. An additional slow down occurs here through the arithmetic to convert from the slice to the sequence as a whole. SubProgram [find_from_to:00116] 1: 096 117 # INTEGER_CHECK: [N:117] 3: 096 118 # INTEGER_CHECK: [L:118] 5: 097 120 # SEQUENCE_CHECK: [b:120] 7: 046 120 117 118 121 # RHS_SLICE: [b:120] [N:117]..[L:118] => [_temp_:121] 12: 077 119 121 118 # FIND: [a:119], [_temp_:121] => [L:118] 16: 020 118 32 # IF: [L:118] = 0 goto 0032 19: 010 118 122 121 # MINUS: [L:118], [LIT 1:122] => [_temp_:121] 23: 011 121 117 121 # PLUS: [_temp_:121], [N:117] => [_temp_:121] 27: 028 116 121 # RETURNF: [_temp_:121] 30: 023 35 # ELSE goto 0035 32: 028 116 118 # RETURNF: [L:118] 35: 043 # BADRETURNF: End SubProgram [find_from_to:00116] Matt
17. Re: find_from and match_from
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 21, 2007
- 674 views
Matt Lewis wrote: > > Derek Parnell wrote: > > > > Robert Craig wrote: > > > the current match() and find() > > > > Robert, I vaguely remember someone saying that a slice doesn't create a new > > sequence until such time as the slice is actually written to. Is that true? > > Not true. I disassembled Igor's example: > }}} <eucode> > function find_from_to(integer N, integer L, object a, sequence b) > L=find(a,b[N .. L]) > if L then > return L-1+N > else > return L > end if > end function > </eucode> {{{ > > Notice line 7, where the slice is created an assigned to the temp. > An additional slow down occurs here through the arithmetic to convert > from the slice to the sequence as a whole. > > SubProgram [find_from_to:00116] > 1: 096 117 # INTEGER_CHECK: [N:117] > 3: 096 118 # INTEGER_CHECK: [L:118] > 5: 097 120 # SEQUENCE_CHECK: [b:120] > 7: 046 120 117 118 121 # RHS_SLICE: [b:120] [N:117]..[L:118] > => [_temp_:121] > 12: 077 119 121 118 # FIND: [a:119], [_temp_:121] => > [L:118] > 16: 020 118 32 # IF: [L:118] = 0 goto 0032 > 19: 010 118 122 121 # MINUS: [L:118], [LIT 1:122] => > [_temp_:121] > 23: 011 121 117 121 # PLUS: [_temp_:121], [N:117] => > [_temp_:121] > 27: 028 116 121 # RETURNF: [_temp_:121] > 30: 023 35 # ELSE goto 0035 > 32: 028 116 118 # RETURNF: [L:118] > 35: 043 # BADRETURNF: > End SubProgram [find_from_to:00116] This is not conclusive. Although the IL says to create a slice and assign it to the temp, does the opcode RHS_SLICE actually allocate RAM for the subsequence and copy data to the new RAM, or does it just create a reference to the existing RAM? As the function never assigns to the slice, a reference is all it really needs. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
18. Re: find_from and match_from
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 21, 2007
- 674 views
Derek Parnell wrote: > > This is not conclusive. Although the IL says to create a slice and assign it > to the temp, does the opcode RHS_SLICE actually allocate RAM for the > subsequence > and copy data to the new RAM, or does it just create a reference to the > existing > RAM? As the function never assigns to the slice, a reference is all it really > needs. Nevermind. I just looked at the back end source code for RHS_Slice() and it does actually allocate RAM etc... Pity, it doesn't always have to. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
19. Re: find_from and match_from
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 21, 2007
- 695 views
Derek Parnell wrote: > Robert, I vaguely remember someone saying that a slice doesn't create a new > sequence until such time as the slice is actually written to. Is that true? That used to always be true about 10 years ago, using a more complicated internal representation of sequences than we have now. I eventually realized that the older representation, while saving time on slices (provided no copy on write is later required), cost time and space on other very common operations, so it wasn't worth it overall, and I changed to the current system. However, even today, there are cases where a slice does not result in a new sequence being written. e.g. x = x[a..b] will usually result in a simple update to the header of sequence x, to show that it starts later, or ends earlier (or both) in memory. Though if x becomes greatly smaller, (I think down to 1/8 or less of it's original size) then a decision might be made to reallocate x to a smaller block of memory. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
20. Re: find_from and match_from
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 21, 2007
- 677 views
- Last edited Mar 22, 2007
Robert Craig wrote: nt system. > > However, even today, there are cases where a slice does > not result in a new sequence being written. e.g. > > x = x[a..b] > > will usually result in a simple update to the header > of sequence x, to show that it starts later, or ends > earlier (or both) in memory. Ok. So something like this might be a tad faster ...
function find_from_to(integer N, integer L, object a, sequence b) b = b[N .. L] L=find(a,b) if L then L += N-1 end if return L end function
-- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
21. Re: find_from and match_from
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 21, 2007
- 685 views
- Last edited Mar 22, 2007
Derek Parnell wrote: > Robert Craig wrote: > > > > However, even today, there are cases where a slice does > > not result in a new sequence being written. e.g. > > > > x = x[a..b] > > > > will usually result in a simple update to the header > > of sequence x, to show that it starts later, or ends > > earlier (or both) in memory. > > Ok. So something like this might be a tad faster ... > > }}} <eucode> > function find_from_to(integer N, integer L, object a, sequence b) > b = b[N .. L] > L=find(a,b) > if L then > L += N-1 > end if > return L > end function > </eucode> {{{ The optimization only works when there is a single reference count on the sequence being sliced. In the above case, the sequence referred to by b will have two references on it, one from b, and one from the caller's variable that is being passed in, so it will still be necessary to copy the elements N..L and create a new sequence. Here's an example of something that *would* be optimized: x = gets(f) if sequence(x) then x = x[1..$-1] -- drop new-line character end if Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
22. Re: find_from and match_from
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 22, 2007
- 674 views
My tuppenceworth: I will vote for this on two independent conditions: 1) Keep one opcode, just make it have 3 params, and put a 1 in there as and when needed (details aside, see PS). 2) At least consider optional parameters, ie in hll it would be eg:
function find(object x, sequence s, integer i=1) ... end function
The "=1" makes it possible to code find(x,s) *or* find(x,s,i). Optional parameters would have to be on the RHS. There are (at least) two ways to do this: a) find(x,s) automagically passes the 1 as well. b) find(x,s) assumes i is already set to 1 (ie less il, see PPPS). I suspect that option b) is problematical for recursive routines. Regards, Pete PS: OK,OK. I lied. This gets my vote anyway. I just wanted an excuse to prattle on about optional parameters. If you managed 2) but not 1), I would be stunned. Obviously a new opcode would share maybe 98% of code so I actually care not about 1), I was just, erm, setting up the field for optional parameters. PPS: This is the same stuff as http://euwiki.ayo.biz/Find_from_and_match_from , yes? Didn't spot a link in this thread yet. PPPS: One thing I figured out early doors when coding Positive was: if you cannot do such things with builtins, how in **** you gona do it with user code? Where it will actually be more useful.
23. Re: find_from and match_from
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 22, 2007
- 677 views
Pete Lomax wrote: > > My tuppenceworth: > I will vote for this on two independent conditions: > > 1) Keep one opcode, just make it have 3 params, and put a 1 in there as and > when needed (details aside, see PS). This is how it should have been done from the outset. > 2) At least consider optional parameters, ie in hll it would be eg: > }}} <eucode> > function find(object x, sequence s, integer i=1) > ... > end function > </eucode> {{{ > The "=1" makes it possible to code find(x,s) *or* find(x,s,i). This would be a great idea too. However, the simplest will be to add new opcodes. I would use this feature frequently as I currently use slower methods now. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
24. Re: find_from and match_from
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 22, 2007
- 681 views
Pete Lomax wrote: > > My tuppenceworth: > I will vote for this on two independent conditions: > > 1) Keep one opcode, just make it have 3 params, and put a 1 in there as and > when needed (details aside, see PS). > > 2) At least consider optional parameters, ie in hll it would be eg: <snip> Both interesting. I think you'd have to somehow make the third optional, or else we've probably broken 90% of the code out there. > PS: OK,OK. I lied. This gets my vote anyway. I just wanted an excuse to > prattle > on about optional parameters. If you managed 2) but not 1), I would be > stunned. > Obviously a new opcode would share maybe 98% of code so I actually care not > about 1), I was just, erm, setting up the field for optional parameters. > PPS: This is the same stuff as http://euwiki.ayo.biz/Find_from_and_match_from > , yes? Didn't spot a link in this thread yet. Yes, forgot I'd put that up. > PPPS: One thing I figured out early doors when coding Positive was: if you > cannot > do such things with builtins, how in **** you gona do it with user code? Where > it will actually be more useful. I have thought about how to do it with a built in. Specifically, I was thinking of making a call_func/proc that didn't take a sequence, but the arguments directly. Basically, put in a negative number for the number of arguments, whose absolute value is the minimum required number of arguments. Of course, we'd have to establish a syntax for user code to access arguments beyond the expected, or else also define the maximum number of arguments as well.