forum-msg-id-134760-edit

Original date:2020-02-10 08:44:39 Edited by: petelomax Subject: 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 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.]

Not Categorized, Please Help

Search



Quick Links

User menu

Not signed in.

Misc Menu