First class routine_ids, aka call such (integers) directly.

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

Something which will be available in the next release, whenever that may be.
Made routine_ids first class, ie [also] callable directly. Eg:

procedure show(string s) ?s end procedure 
constant r_show = routine_id("show") 
-- show("40")   (normal non-routine_id call [still valid!]) 
call_proc(r_show,{"41"})                -- old style [""!] 
r_show("42")                            -- ***new*** 
function f(integer i) return i end function 
constant r_f = routine_id("f") 
--?f(40)        (normal non-routine_id call [still valid!]) 
?call_func(r_f,{41})                    -- old style [""!] 
?r_f(42)                                -- ***new*** 

Any integer (or anything the compiler knows is one) followed by '(' is treated as a call_func() or a call_proc(), depending on the context, and obviously as above the normal/old styles remain perfectly valid and fully supported.

However I decided against supporting this sort of thing (at least not before someone comes up with a compelling reason to):

--sequence rids = {r_show} 

Instead you have to code integer rid=r_f(r_f) then ?rid(43), etc.
(Some wag might say that makes them second class, but it is not like you could ever do anything like that with the original "show" identifier.)
Note that i(5) where i is not a routine_id will fail just as badly and in exactly the same way as call_func/proc(i,{5}) always has.
Likewise the additional compile-time validation of argument types is not performed/deferred until run-time, in exactly the same way as it always was for explicit/old-style call_func/proc() calls.
These changes were made to complement the (proposed/incomplete) syntax enhancements for the new struct/class handling, specifically class methods.

I was rather pleased with that, not too difficult a change.

In related news, the design of structs has finally really started to take off in the past two or three weeks, and just today I got some code to actually work, albeit in the form of rather ugly hll calls rather than any nice new syntax, not that I should be proud of taking 5 months(!) to (only) get this far...

After a fair bit more polishing and testing, the next step is to get the compiler to map the new syntax (not quite yet set in stone) to the above mentioned rather ugly hll calls, seamlessly.

I have identified four basic types of struct:

  • one based on sequence-semantics
  • one based on reference-semantics (as are next two)
  • one fully dynamic [least likely to work in v1]
  • one for interfacing to C

They will(/should!) all have reasonably similar syntax handling, just different innards.
(I know I could probably have delivered one quarter of that in one quarter of the time, but the next step
would have probably been severely hampered, both practically/backward compatibility, and intellectually.)

I really should hold off on any further wild claims until I know the things actually work.

Maybe structs.e might be easier to write if only I could use some kind of structs to write it with...

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


Quick Links

User menu

Not signed in.

Misc Menu