Time is relative. So, if we have a "now" that refers the instant "now" is parsed by the compiler, it seems to suggest, as Kassen is suggesting, that we ought also to have a "birth" keyword that refers to the VM's zeroth instant, or origin time. I suppose it also follows that we could have a kind of "me.birth" attribute in reference to the time (relative to the VM starting) that the current shred (i.e. me) was sporked. I say "relative to the VM starting" to avoid the idea of shred-local timelines. One time to rule them all... ;) Still, this would be sugar. I really like the argument that if (time / duration = float) is legal, then (time / float = duration) should also be legal, however, it also follows that (time = duration * float), which I don't like. (2::second * 4) ought to return 8::second. So, I think that we're dealing with concepts here that don't fit squarely into the model of mathematics. After all, we don't multiply strings and floats, do we? I'm all for a more rigorous understanding of these types, though. This is all very confusing. -Mike On Jan 7, 2008 5:33 PM, Kassen wrote:

On 07/01/2008, pibsid@suomi24.fi wrote: <snip>

That should be enough.

Yes, what we have is "enough" in a way, we can do all that was suggested might need to be done (including referring to the birth of the VM hours after it started) but in order to do it we need to take some routes I find counter-intuitive on a syntax level.

Requesting time casting sounds to me of requesting different kinds of time

...

like VM time, shred time, real time, tea time and what not... :) There should only be one time. VM time. I think of it like a kind of a big bang time... everything else is relative. (Did someone say Einstein?)

Yes, there is only one timeline, no issues there. We have "time" which is a data type that refers to moments and there is "duration" which refers to lengths of time. This is fine as well.

What isn't so fine, IMHO, is that durations and moments are linked in ways that aren't as coherent everywhere as (I feel) they might be. After all; the basic unit of both is essentially the same (floating point numbers of samples).

Nobody is -so far- requesting multiple kinds of time, this is a potential issue on a syntax level, as far as I'm concerned, not a proposal to totally overhaul how we deal with time.

The main issue I have is that we can only define objects of type "time" in terms of "now" and there is no other way to define such objects which can lead to roundabout constructs, for example if we want to refer to the birth of a running VM.

This is mainly a theoretical issue, as far as I can see for now, but a interesting one that I feel deserves a look. I'm not sure if and when this will actually affect something practical.

Hope that clarifies my thoughts, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://semiotech.org http://blog.deadlylittlepills.com http://www.murderkills.com http://shadowofaculture.blogspot.com