OpenEuphoria

1. feature req: passing sequences

• Posted by katsmeow Feb 14, 2015
• 1545 views

This illustrates the problem in as little code as possible:

object junk = get_position() 
position(junk[1],junk[2]) -- this works 
position(junk)            -- this crashes 

3. Re: feature req: passing sequences

• Posted by mattlewis (admin) Feb 14, 2015
• 1528 views

object junk = get_position() 
position(junk[1],junk[2]) -- this works 
position(junk)            -- this crashes 

I've often wanted this. Obviously, it's how we pass parameters for routine id calls or the variable arguments for printf. The way to do this, I think is some sort of built in operator, let's call it param_unroll for now (it's verbose and kind of ugly, but it's obvious, so good for this discussion).

So:

position( param_unroll( junk )) 

Now, what about more complicated situations?

foo( bar, param_unroll( baz ), bat, param_unroll( blat), junk ) 

This doesn't sound...overly difficult to implement, though probably not exactly simple once we get into the weeds. We'll need to do some temp assignments and turn those into parameters. In the interpreter at least, some additional bounds checking.

I don't think it requires any changes for the backend or even the translator. This is probably a purely front-end change (so, 100% euphoria code). Not that the front end is super simple or anything.

Although...we'll either need to go ahead and use call_func/proc or add some way to add default parameters and parameter error checking into the back end. So...maybe.

Matt

5. Re: feature req: passing sequences

• Posted by petelomax Feb 14, 2015
• 1501 views

foo( bar, param_unroll( baz ), bat, param_unroll( blat), junk ) 

Seems a little overkill to me. Would there be the problem with forcing a single unroll?

foo( param_unroll( bar & baz & bat & blat & junk )) 

That might better allow re-use of some of the existing code in call_func/proc.

position( param_unroll( junk )) 

Just to throw some random ideas about, maybe something a bit more minimalist like

position( @junk ) 

or some other [new] operator to signify desequencing, :{}junk, =:junk, :=:junk, ()junk, []junk, {}junk, to list a few possibilities.

An alternative and probably far better solution might be to make routine_id("") optional on the first parameter of call_func/proc, eg:

call_proc(position,junk) 

with the bonus of seamlessly supporting those builtins for which routine_id does not currently work. Before anyone jumps the gun here, that does not mean you can actually have a routine_id for a builtin (write a tiny wrapper you lazy sod!), nor does it mean it will actually invoke call_proc/func. It would also require the routine identifier to resolve at parse-time, not run-time.

Now that I've said it I rather suspect that is much closer to what the real problem is, and you can probably forget that nonsense above about a new minimalist desequence operator?

Pete

7. Re: feature req: passing sequences

• Posted by ryanj Feb 14, 2015
• 1455 views

I think this is a good example of a routine that should be able to accept a sequence instead of forcing separate parameters. I run in to this problem dealing with rectangles in GUI programming. It seems to me that

position({row, column})

is better implementation than

position(integer row, integer column).

Now that i think about it, it almost seems silly that euphoria routines even have parameters instead of just passing sequences.

9. Re: feature req: passing sequences

• Posted by dcuny Feb 14, 2015
• 1486 views

Except that you lose type safety, which is touted as one of the major features.

Odd how only "library routines" get "bad parameter values" checked.

Passing individual parameters makes it easier for the compiler to catch parameter mismatch errors.

Passing a sequence means that any problem can't be caught until runtime, which isn't optimal. Unless, of course, you've got some sort of type.

Euphoria has user-defined types, but they are also only checked at runtime - a rather odd omission.

Especially with the need to interface with libraries that support classes (such as wxWidgets), I think there's a need for Euphoria to support some sort of class system. However, it's not clear exactly how that would work, since it would need to support inheritance and polymorphism.

I've been intrigued by Typescript, because it solves a similar problem: enforcing types on on a weakly-typed language (JavaScript). The cool thing about TypeScript is that it's implemented using a pre-processor, so it outputs plain vanilla JavaScript.

I suspect that an approach like that might be a good route to take.

Sorry to hijack the thread, you just got me thinking...

- David

11. Re: feature req: passing sequences

• Posted by dcuny Feb 15, 2015
• 1415 views

Sorry, I dropped a clause here:

If Euphoria were to pass all parameters by sequence, then all type checking of parameters within the sequence would be (obviously) deferred until runtime.

I'm loathe to give up compile time type checking, which is why I'd rather have Euphoria explicitly support notation like this:

function foo() 
   return 1, 2, 3 
end function 
 
integer a, b, c 
a, b, c = foo() 

rather than pack the values in to a sequence and send them merrily on their way to be unpacked by the caller:

function foo() 
   return {1, 2, 3} 
end function 
 
integer a, b, c 
{a, b, c} = foo() 

I'm not trying to argue for the comma notation at this point - just the idea that type safety is a good thing, and being able to find errors at compile time is superior to deferring to runtime. After all, the compiler is going to see all the code.

This gets back to TypeScript where the compiler tracks a lot of these details. For example, TypeScript has a interface:

interface Person { 
    firstname: string; 
    lastname: string; 
} 

This is a construct that only exists at compile time. The compiler makes sure that parameters of type Person conform to the interface.

In Euphoria, the concept could be identical. Going back to the original example, you could have something like:

interface Point 
    x integer 
    y integer 
end interface 

The compiler would implement all interface objects as a sequence, so behind the scenes you're still generating "classic" Euphoria code. But you get the safety of ensuring that type that's passed to the routine conforms without the overhead of having to declare a type that can only be tested at runtime.

- David

13. Re: feature req: passing sequences

• Posted by irv Feb 15, 2015
• 1386 views

After calling x = get_position(), x is now a sequence of 2 values. So why doesn't (set) position, which seems to be the reverse operation, not accept x? Instead, it requires the programmer to break up x into 2 pieces; x[1],x[2] More work for the programmer, and just another idiosyncrasy to remember.

Symmetry is attractive both in faces and in programming languages.

15. Re: feature req: passing sequences

• Posted by cargoan Feb 16, 2015
• 1339 views

object junk = get_position() 
position(junk[1],junk[2]) -- this works 
position(junk)            -- this crashes 

with warning save 
without warning &= { override } 
override procedure position(object row, integer column = 1) 
   if sequence(row) then 
      if length(row) > 1 then 
            column = row[2] 
      end if 
      row = row[1] 
   end if 
   eu:position(row, column) 
end procedure 
with warning restore