[chuck-users] cast dur to time?

mike clemow gelfmuse at gmail.com
Mon Jan 7 18:12:35 EST 2008

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.


On Jan 7, 2008 5:33 PM, Kassen <signal.automatique at gmail.com> wrote:

> On 07/01/2008, pibsid at suomi24.fi <pibsid at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080107/214d7a88/attachment.htm 

More information about the chuck-users mailing list