Re: Pass by Reference

new topic     » goto parent     » topic index » view thread      » older message » newer message
dcuny said...

What I'm asking for is a level of compile-time safety. Obviously, there's no way to know the number of parameters that are being passed back with a sequence until runtime.
The distinction I'm trying to make is that a function has the option of passing back multiple values. You'd only do this for the purpose of additional compile-time safety.

... I think this must have got lost in all the shouting:

petelomax said...
dcuny said...

The second can only be determined to be wrong at runtime, and will result in a crash.

It would probably not be difficult to collect min/max/unknown lengths of returned sequences, so as long as you don't build return values using append() etc, it should be just as easy to check (at parse time).

I took a couple of minutes to check, and in my own particular parlance:

  • DoRoutineDef() has to initialise a few new static vars/flags
  • DoReturn() has to check opstack for opMkSq,N or an all-literal-const-sequence and set those flags/lengths accordingly
  • DoRoutineDef() has to save those vars/flags permanently in the symtab, and post-validate any prior fwd calls
  • MultipleAssignment() checks opstack for a return var, and either
    • logs the forward call for DoRoutineDef() to later process, or
    • validates things there and then

As I see it, the only sticky points are
firstly that one = f() is just a plain (sequence) assignment and gets no validation whatsoever, but anything with the {one,...} = f() syntax gets checked, and
secondly that any return not of the return {...} syntax precludes any and all checks on calls-with-multiple-assignment to that particular routine.
Third and last, {} = f() does not trigger a mismatch, as it is an explicit discard.

Pete

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu