1. This does not jive
- Posted by DonCole Sep 01, 2012
- 2170 views
I'm using euphoria ver.3 for this.
My code,
sequence rect rect={325,350,366,365} ?{WndMain,1}&rect&{5,5} junk={WndMain,1}&rect&{5,5} printf(1,"length(junk)=%d %s\n",{length(junk)}) drawRoundRect(junk)
I get:
{30,1,325,350,366,365,5,5}
length(junk)=8
(error)
drawRoundRect takes 8 arguments
drawRoundRect(junk)
This simply doesn't make any sense.
Don Cole
2. Re: This does not jive
- Posted by ChrisB (moderator) Sep 01, 2012
- 2155 views
Hi
You've only passed one item, a sequence.
Chris
3. Re: This does not jive
- Posted by mattlewis (admin) Sep 01, 2012
- 2123 views
I'm using euphoria ver.3 for this.
My code,
sequence rect rect={325,350,366,365} ?{WndMain,1}&rect&{5,5} junk={WndMain,1}&rect&{5,5} printf(1,"length(junk)=%d %s\n",{length(junk)}) drawRoundRect(junk)
I get:
{30,1,325,350,366,365,5,5}
length(junk)=8
(error)
drawRoundRect takes 8 arguments
drawRoundRect(junk)
This simply doesn't make any sense.
If you want to combine arguments into a sequence and call the procedure, you'll need to use routine_id() and call_proc().
Matt
4. Re: This does not jive
- Posted by DonCole Sep 02, 2012
- 2055 views
If you want to combine arguments into a sequence and call the procedure, you'll need to use routine_id() and call_proc().
Matt
From win32lib,
-- where is the window located? sequence extent -- get the extent of the window extent = getRect( MyWindow ) -- display the position wPrintf( MyWindow, "MyWindow is located at %d,%d }, extent[1 .. 2] )
Don
5. Re: This does not jive
- Posted by mattlewis (admin) Sep 02, 2012
- 2060 views
If you want to combine arguments into a sequence and call the procedure, you'll need to use routine_id() and call_proc().
Matt
From win32lib,
-- where is the window located? sequence extent -- get the extent of the window extent = getRect( MyWindow ) -- display the position wPrintf( MyWindow, "MyWindow is located at %d,%d }, extent[1 .. 2] )
It's not clear what "does not jive." You didn't really say anything here.
Matt
6. Re: This does not jive
- Posted by DonCole Sep 02, 2012
- 2043 views
Matt
It's not clear what "does not jive." You didn't really say anything here.
By not jive I meant length(junk)=8. drawRoundRect takes 8 arguments is an error.
As you pointed drawRounRect only sees 1 argument.
junk={WndMain,1}&rect&{5,5} drawRectangle(junk[1],junk[2],junk[3],junk[4],junk[5],junk[6],junk[7],junk[8])
This would seem fix the problem but a lot of work.
You are saying I have to use call_proc() and call_func().
Wouldn't drawRectangle(junk[1..8])work?
I haven't had time to test it but will.
Don
7. Re: This does not jive
- Posted by mattlewis (admin) Sep 02, 2012
- 2036 views
Matt
It's not clear what "does not jive." You didn't really say anything here.
By not jive I meant length(junk)=8. drawRoundRect takes 8 arguments is an error.
As you pointed drawRounRect only sees 1 argument.
Yes. You're passing a single sequence. That's 1 argument.
junk={WndMain,1}&rect&{5,5} drawRectangle(junk[1],junk[2],junk[3],junk[4],junk[5],junk[6],junk[7],junk[8])
This would seem fix the problem but a lot of work.
You are saying I have to use call_proc() and call_func().
Wouldn't drawRectangle(junk[1..8])work?
I haven't had time to test it but will.
junk[1..8] is a single sequence with 8 elements. If you pass that as a parameter to a routine, it is a single argument. Yes, you'll need to split it out, separated by commas, if you want the elements to be treated as separate parameters.
call_proc() obviously works differently, since you pass the parameters as a sequence. If what you were trying to do was allowed, there would be no way to ever determine whether the user was passing a sequence as a single parameter or meant to be all of the parameters.
Matt
8. Re: This does not jive
- Posted by ArthurCrump Sep 02, 2012
- 2037 views
junk={WndMain,1}&rect&{5,5} drawRectangle(junk[1],junk[2],junk[3],junk[4],junk[5],junk[6],junk[7],junk[8])
This would seem fix the problem but a lot of work.
You are saying I have to use call_proc() and call_func().
Wouldn't drawRectangle(junk[1..8])work?
I haven't had time to test it but will.
junk[1..8] is a single sequence with 8 elements. If you pass that as a parameter to a routine, it is a single argument. Yes, you'll need to split it out, separated by commas, if you want the elements to be treated as separate parameters.
call_proc() obviously works differently, since you pass the parameters as a sequence. If what you were trying to do was allowed, there would be no way to ever determine whether the user was passing a sequence as a single parameter or meant to be all of the parameters.
Matt
There have been other occasions when a parameter list in a sequence had to be split up in this way. Perhaps a new syntax could indicate that the sequence should be desequenced into the parameters? Thinking rather crudely that the reverse of sequence would be }{ the format:
drawRoundRect( }junk{ )
would have the same effect as:
call_proc(routine_id("drawRoundRect"),junk)
although possibly more efficiently. I am not going to raise a feature ticket because it is just a silly thought and there would probably be a much better syntax anyway.
Arthur
9. Re: This does not jive
- Posted by ghaberek (admin) Sep 02, 2012
- 2008 views
There have been other occasions when a parameter list in a sequence had to be split up in this way. Perhaps a new syntax could indicate that the sequence should be desequenced into the parameters? Thinking rather crudely that the reverse of sequence would be }{ the format:
drawRoundRect( }junk{ )
would have the same effect as:
call_proc(routine_id("drawRoundRect"),junk)
although possibly more efficiently. I am not going to raise a feature ticket because it is just a silly thought and there would probably be a much better syntax anyway.
In the create() function of wxEuphoria, we accept a single object params argument, which allows us to take a truly variable number of parameters. Then it gets broken down using a switch block, as shown below. Truth be told, this actually happens in the C++ code, but the method is the same, and I think it's more in tune with what you're looking for...
public function new_wxExampleCtrl( object params ) -- make sure the params is a sequence -- (if it was an atom, it must be only one parameter) if atom( params ) then params = {params} end if -- setup the default parameters atom parent = 0 integer id = -1 sequence text = "" sequence posn = {-1, -1} sequence size = {-1, -1} atom style = 0 -- using "with fallthru" here allows us to jump to that line and -- then keep falling down to "end switch" so we catch all params switch length( params ) with fallthru do case 8 then style = params[8] case 7 then size = params[6..7] case 6 then -- skip case 5 then posn = params[4..5] case 4 then -- skip case 3 then text = params[3] case 2 then id = params[2] case 1 then parent = params[1] end switch -- create a dummy control atom ctrl = create( wxWindow, {parent, id, text, posn[1], posn[2], size[1], size[2], style} ) -- and return it back return ctrl end function -- for completeness of the example, we would register the new ctrl type like this: public constant wxExampleCtrl = add_create_func({ routine_id("new_wxExampleCtrl") })
Now, if we gain the ability to assign multiple LHS (left-hand side) variables, this would be much easier...
{parent,id,text,x,y,cx,cy,style} = params
-Greg
10. Re: This does not jive
- Posted by ne1uno Sep 02, 2012
- 1975 views
junk={WndMain,1}&rect&{5,5} drawRectangle(junk[1],junk[2],junk[3],junk[4],junk[5],junk[6],junk[7],junk[8])
This would seem fix the problem but a lot of work.
junk[1..8] is a single sequence with 8 elements. If you pass that as a parameter to a routine, it is a single argument. Yes, you'll need to split it out, separated by commas, if you want the elements to be treated as separate parameters.
There have been other occasions when a parameter list in a sequence had to be split up in this way. Perhaps a new syntax could indicate that the sequence should be desequenced into the parameters? Thinking rather crudely that the reverse of sequence would be }{ the format:
drawRoundRect( }junk{ )
would have the same effect as:
call_proc(routine_id("drawRoundRect"),junk)
although possibly more efficiently. I am not going to raise a feature ticket because it is just a silly thought and there would probably be a much better syntax anyway.
flipping the braces is an interesting idea, but probably a nightmare for parsing and syntax syntax coloring. even if solvable by euphoria devs it could prove a nightmare for 3rd party tools.
there was talk a few months ago about using '@' with routine ID. this would mostly be used by a few of the larger library creators. though once in use, more general usage might be found.
a better use of '@' would be for unpacking sequences. Python has a similar syntax using '*' to unpack arrays. maybe '*' would work as well if there would be no conflict with present and future struct syntax.
11. Re: This does not jive
- Posted by ArthurCrump Sep 03, 2012
- 1918 views
flipping the braces is an interesting idea, but probably a nightmare for parsing and syntax syntax coloring. even if solvable by euphoria devs it could prove a nightmare for 3rd party tools.
there was talk a few months ago about using '@' with routine ID. this would mostly be used by a few of the larger library creators. though once in use, more general usage might be found.
a better use of '@' would be for unpacking sequences. Python has a similar syntax using '*' to unpack arrays. maybe '*' would work as well if there would be no conflict with present and future struct syntax.
I agree. Having '{' or any sort of closing symbol at the back was always a rotten idea anyway.
Arthur
12. Re: This does not jive
- Posted by EUWX Sep 03, 2012
- 1911 views
How about
{+ and +} for expanding i.e. breaking up a sequence and
{- and -} for assemble together.
13. Re: This does not jive
- Posted by ne1uno Sep 03, 2012
- 1903 views
How about
{+ and +} for expanding i.e. breaking up a sequence and {- and -} for assemble together.
this seems a little problematic. you will want to allow variables to be unpacked and it won't be clear at the place of use what is happening. besides, +x would be valid syntax already and a little hard to parse. not sure what assemble would do.
sq = {+ 1,2,3 +} foo(sq)
there is another problem with the whole unpacking idea. partially solved in 4.1, one of the best new features, and reason enough to drop 4.0, variable unpacking is already possible
{a,b,v} = foo() {a,b,c} = {1,2,4}
but there is no actual variable sequence to single variable unpacking. you must explicitly hardwire the sequence at the place of use.
this would also have to be extended to allow default values using '?', which currently would be a sytnax error when building a sequence.
using this same syntax, '=' would be enough to disambiguate unpacking.
sq = {1,?,4} {a,b,v} = foo(=sq)
not being able to declare somehow to skip/use default parameters is probably a deal breaker. although, lack of default value syntax is already a problem with routineID. adding unpacking might help solve the default values in routineID problem. someone else will have to say if any of this is feasible at this time.
14. Re: This does not jive
- Posted by DerekParnell (admin) Sep 03, 2012
- 1847 views
... This simply doesn't make any sense.
I'm sure it makes sense to you now, but instead of waiting for the language to change, try this ...
procedure myDrawRoundRect( sequence x) drawRoundRect(x[1], x[2], x[3], x[4], x[5], x[6], x[7], x[8]) end procedure sequence rect rect={325,350,366,365} junk={WndMain,1}&rect&{5,5} MyDrawRoundRect(junk)
15. Re: This does not jive
- Posted by EUWX Sep 04, 2012
- 1788 views
procedure myDrawRoundRect( sequence x) drawRoundRect(x[1], x[2], x[3], x[4], x[5], x[6], x[7], x[8]) end procedure sequence rect rect={325,350,366,365} junk={WndMain,1}&rect&{5,5} MyDrawRoundRect(junk)
DerekParnell: In the above example,
drawRoundRect(split (x))
or
drawRoundRect(split (x , , 8))
should work, should it not?
I am not criticizing you; just trying to get the split function clearly in my mind.
I was not even aware of it till today.
16. Re: This does not jive
- Posted by mattlewis (admin) Sep 04, 2012
- 1790 views
DerekParnell: In the above example,
drawRoundRect(split (x))
or
drawRoundRect(split (x , , 8))
should work, should it not?
I am not criticizing you; just trying to get the split function clearly in my mind.
I was not even aware of it till today.
It depends on what you're passing to split(), of course (and which split() you actually call!). split() is designed to split up a string (the regex version) or a sequence (sequence.e version) based on some delimiter.
With Derek's example, I don't see that you'd want to call split(). Did you have some other scenario in mind?
Perhaps play around with split() and see how it changes the sequence? I recommend using display() from std/console.e for examining this sort of thing easily.
Matt
17. Re: This does not jive
- Posted by euphoric (admin) Sep 04, 2012
- 1768 views
drawRoundRect(split (x))
or
drawRoundRect(split (x , , 8))
should work, should it not?
Split returns ONE sequence, so it would not work with a function that expects multiple, non-defaulted parameters.
18. Re: This does not jive
- Posted by DerekParnell (admin) Sep 04, 2012
- 1789 views
DerekParnell: In the above example,
drawRoundRect(split (x))
or
drawRoundRect(split (x , , 8))
should work, should it not?
No, it wouldn't work. The reason is that the drawRoundRect() routine requires eight integers and the split() function returns one sequence.
Your example is exactly equivalent to ...
sequence y y = split(x, , 8) drawRoundRect(y)
Currently, the language does not handle tuples (a set of arguments) as a datatype and thus there is no easy way to convert a sequence to a tuple. One has to do it manually.
19. Re: This does not jive
- Posted by DonCole Sep 09, 2012
- 1390 views
Hello,
First I want to thank everyone for their advise and comments.
I did say I was using ver. 3.
What I was looking for was,
sequence rect,junk rect={325,350,366,365} junk=getRectangle(rect) drawRoundRect(WndMain,1,junk[1..4],5,5)
it doesn't use call_proc(), which would also work, and drawRoundRect() uses only one reference to junk.
Don Cole