Re: Switch question - yet again!
- Posted by petelomax Nov 22, 2022
- 8115 views
Features I avoid using include:
- Using object() as a function to determine whether you set your variable or not
Just so you know, that is kinda the way Phix implements optional parameters, if you have:
-- file e06a.e object dflt = "default\n" global procedure pd(object x=dflt) puts(1,x) end procedure
Then Phix effectively implements that as
global procedure pd(object x=<undefined>) if not object(x) then x=dflt end if
I don't know too much about how Euphoria works, except to say that if you also have:
include e06a.e procedure p() object dflt = "p's default\n" pd() end procedure procedure q() pd() end procedure p() q() -- output: Phix/4.1.0 4.0.0 -- default p's default -- default default
Which lightly surprised me, I didn't know there had been a change between 4.0 and 4.1 but the former looks in both [local] scopes. Anyway, no matter.
It's taken literally years to get up to speed on the internals of Euphoria and start adding or fixing things.
I often wonder how long it would take someone to get to grips with the innards of Phix.
- idea: get rid of destructors on integers. The cost is type safety now because all of the io routines would have to accept general atoms for the file handle rather than only integers.
I am considering that too, see below.
Alternatively, you could force (only whenever delete_routine() is involved) say:
--integer fn = delete_routine(open(...)); puts(fn,"hello") ==> sequence fn = delete_routine({open(...)}); puts(fn[1],"hello")
- idea: make switches generate the same code as if x = case1 then ... elsif x = case2 then ... ... end if
Phix generates the same ir for both "switch" and "if" constructs, then (since there is a potential significant speed gain) decides whether to emit a cmp/jmp daisy-chain or a jump table (better for >8, I found).
[Of course it applies all the extra required "is switchable" checks such as all tests on same lhs var, no and/or/</<=/>/>=/!=, etc.]
- idea: get rid of destructors on integers.
- idea: get rid of delete_routine all together. Nobody likes this idea but for completeness I include it here.
Slightly off to one side, I was [yet again] contemplating adding an array type (fixed length, homogenous/all-integers or all-floats).
Part of the reason for doing that was to get rid of reference counts [and shifted memory addresses] on floats [that is, within said, now if I could do it for all floats...]
Three things popped out of that:
- first: of course there wouldn't be any ref counts, delete_routines, etc on any of the individual elements.
- second: I already had the perfect type for that, a (binary) string, just the compiler needs to understand it has a different [local] use.
- third: there really should be a way to add arbitrary attributes to a sequence (and strings, but certainly not atoms).
A delete_routine would actually be better held in such an attribute system, and in fact I could use the existing space for a delete_routine as some kind of [potentially indirected, and
maybe even multiple times] "attribute index", and that way allow the programmer total (or at least a or b style) flexibility over "per sequence" or "per class of sequence" attributes.
The ex.err could end up something like:
main.exw: filepath[attrdx:2] = {"name","path"} builtins/attributes.e: attributes[1] = {...} attributes[2] = {...} -- (this one applies/belongs to filepath)
Anyway, I didn't really finish that design thought, it would certainly need something akin to delete routines to manage it's own cleanup, and I certainly didn't get round to writing any actual code.
