1. This does not jive

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

new topic     » topic index » view message » categorize

2. Re: This does not jive

Hi

You've only passed one item, a sequence.

Chris

new topic     » goto parent     » topic index » view message » categorize

3. Re: This does not jive

DonCole said...

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: This does not jive

mattlewis said...

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: This does not jive

DonCole said...
mattlewis said...

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: This does not jive

said...

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

new topic     » goto parent     » topic index » view message » categorize

7. Re: This does not jive

DonCole said...
said...

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.

DonCole said...
 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

new topic     » goto parent     » topic index » view message » categorize

8. Re: This does not jive

mattlewis said...
DonCole said...
 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

new topic     » goto parent     » topic index » view message » categorize

9. Re: This does not jive

ArthurCrump said...

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

new topic     » goto parent     » topic index » view message » categorize

10. Re: This does not jive

ArthurCrump said...
mattlewis said...
DonCole said...
 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.

new topic     » goto parent     » topic index » view message » categorize

11. Re: This does not jive

ne1uno said...

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

new topic     » goto parent     » topic index » view message » categorize

12. Re: This does not jive

How about

{+ and +} for expanding i.e. breaking up a sequence and
{- and -} for assemble together.

new topic     » goto parent     » topic index » view message » categorize

13. Re: This does not jive

EUWX said...

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.

new topic     » goto parent     » topic index » view message » categorize

14. Re: This does not jive

DonCole said...

... 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) 
new topic     » goto parent     » topic index » view message » categorize

15. Re: This does not jive

DerekParnell said...
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.

new topic     » goto parent     » topic index » view message » categorize

16. Re: This does not jive

EUWX said...

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. smile

Matt

new topic     » goto parent     » topic index » view message » categorize

17. Re: This does not jive

EUWX said...
    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.

new topic     » goto parent     » topic index » view message » categorize

18. Re: This does not jive

EUWX said...

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.

new topic     » goto parent     » topic index » view message » categorize

19. Re: This does not jive

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu