Boris made a timing function called "CLOCK", as a sort of replacement for DELTA-TIME:
clock: function [
"Display execution time of code, returning result of it's evaluation"
code [block!]
/times n [integer! float!] ; float for e.g. `1e6` instead of `1'000'000`
"Repeat N times (default: once); displayed time is per iteration"
/delta "Don't print the result, return time delta per iteration (in msec)"
]
It builds in iteration...which is useful for timing, since you often want to loop over things they time. And at least in theory it should be in the native timing construct--you'd prefer not to have an interpreted call to REPEAT being part of what you count in your time.
(Perhaps the repeat count should just be a required first argument--since CLOCK 1 is so easy to type, why make people fuss over CLOCK/TIMES and then putting the number of times all the way at the end somewhere?)
But... I Think CLOCK should be a Noun
clock.time and clock.date have many advantages over now/time and now/date.
It implies that you could pass a clock around or copy it...which is a good thing. So by default the CLOCK could be UTC (for programming convenience). But you could copy that clock and set your module's meaning of the word CLOCK to speak in terms of local time.
Also it resolves a big annoyance of mine: NOW being a function that has a lot of conflicting refinements. If CLOCK were an object, then .time and .date would be separate methods of that object, so you couldn't say things like clock.time.date.
And then you could capture the current time into a variable as now: clock.time which makes more sense to me than saying "now" is itself a verb. (It then wouldn't stay current as "now" in the sense of "exactly this moment", but in language we're pretty comfortable saying "things are different now than they were in the '80s"...e.g. there can be a prolonged linguistic notion of now. I prefer to use it in this sense.)
As far as functional programming goes: because code doesn't have an intrinsic notion of time, you can show that a piece of code is dependent on a clock by passing one as a parameter.
This would allow you also to have code run simulating at a different time. You could see how a piece of code would perform if it thought it were running at some pathological date, while working alongside other code that was operating with the current notion of time--e.g. to communicate with some webservers to upload results from a test of something like a Y2K problem simulated by other code.
What to Call The Timing Construct?
To think in terms of super-powers, then you need...a dialect !
Perhaps it could be called "CHRONO"?
Maybe CHRONO quotes its argument, and if you give it a GROUP!, it thinks of that as something to time and run just once.
>> chrono (my-function 1 2 3)
0.14 μs
== <result>
But if you pass a BLOCK! it could permit more options, like saying what you wanted the timing in terms of:
chrono [msec (my-function 1 2 3)]
chrono [usec (my-function 1 2 3)]
Or the repeat count (being a parameter to chrono means you're not timing a REPEAT inside your code, ideally).
>> chrono [1e7 (1 + 2)]
0.14 μs [1 + 2]
== 3
I'm busy with other things and so I'm not going to go research all the possible features you might want from a timing dialect--I'm sure there's plenty of prior art in the domain. Just wanted to get it started. Use your imagination. 