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

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):

--?r_f(r_f)(43) 
--r_f(r_show)(44) 
--sequence rids = {r_show} 
--rids[1](45) 

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 message » categorize

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

petelomax said...

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

This is a great enhancement!

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

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

great

richard

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

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

I think one of the reasons this isn't done is certain syntax error expressions will have unexpected results.

-- suppose r_routine is a routine that points to bzero from C and happens to be 2. 
 
? 2*(1+2) -- The user gets 6 
 
? 2(1+2) -- The user forgot the '*', and gets a machine error trying to write to address 3, for some unknown amount. 
new topic     » goto parent     » topic index » view message » categorize

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

SDPringle said...

I think one of the reasons this isn't done is certain syntax error expressions will have unexpected results.

-- suppose r_routine is a routine that points to bzero from C and happens to be 2. 
 
? 2*(1+2) -- The user gets 6 
 
? 2(1+2) -- The user forgot the '*', and gets a machine error trying to write to address 3, for some unknown amount. 

You are kind of right, however it turns out to be fairly reasonable, the following is actual behaviour (as of Feb 10 2020):

procedure p(object x) 
    ?{"p",x} 
end procedure 
constant r = routine_id("p") -- [3] 
?r  -- 1164 
 
--2(1+2) 
--^ unrecognised -- [1] 
--1164(1+2) 
--^ unrecognised -- [1] 
 
--integer i = 2     -- invalid routine_id(2) -- [2] 
integer i = 1164    -- {"p",3} 
i(1+2) 
r(1+2)  -- (presumably what you intended to write) 

[1] The compiler is smart enough to know a literal integer when it sees one and reject it as a syntax error.
[2] It turns out the probability of "invalid routine_id" is almost guaranteed to be better than 75%.
[3] if you comment out the definition of r (and both uses), the compiler optimises p() away since it thinks nothing calls it, and you get:

C:\Program Files (x86)\Phix\builtins\VM\pcallfunc.e::cc_retaddr 
type check failure, ???(symtab[322][S_name]=0) is {213,243,20,2,1167,116.. 
... called from C:\Program Files (x86)\Phix\test.exw:14 
So yes, it can get a bit indecipherable, but still manages to point right at the i(1+2) source code line.
[I think I have plenty more important things to do right now than try and improve that particular error.]

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

Search



Quick Links

User menu

Not signed in.

Misc Menu