Dear list (and language designers in particular), this is legal; now + 2::second => time later; so, we know that time and duration are quite similar things (we already knew that ourselves but now we know ChucK agrees). However, this isn't legal; 2::second $ time => time later; I tried this, intending "later" to refer to the moment 2 seconds after the VM sprang to life. Are there good reasons not to allow the casting from time to dur and dur to time? Yours, Kas.
Kassen,
That actually doesn't make sense to me. 2::second has no reference point to
when it started or when it ends. It's just 2 seconds of duration. So, for
me, this:
2::second $ time => time later;
seems so implicit that it's ambiguous. I would, however, agree that there
ought to be a (dare I say) keyword for the time at which the VM started so
that you could basically do the same thing that you did in the first line.
vmstart + 2::second => time afterVmStarted;
Of course, you could just approximate this functionality by having this line
run the moment the vm starts:
now => time vmstart;
Then, you'd be able to the do everything relative to that time. At least,
that's how I would solve it.
-Mike
On Jan 7, 2008 10:11 AM, Kassen
Dear list (and language designers in particular),
this is legal; now + 2::second => time later;
so, we know that time and duration are quite similar things (we already knew that ourselves but now we know ChucK agrees).
However, this isn't legal;
2::second $ time => time later;
I tried this, intending "later" to refer to the moment 2 seconds after the VM sprang to life.
Are there good reasons not to allow the casting from time to dur and dur to time?
Yours, 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
On 07/01/2008, mike clemow
Kassen,
That actually doesn't make sense to me. 2::second has no reference point to when it started or when it ends. It's just 2 seconds of duration. So, for me, this:
2::second $ time => time later;
seems so implicit that it's ambiguous.
I see where you are coming from, but "now" really is a duration already, in
a way.
<<
the time at which the VM started so that you could basically do the same thing that you did in the first line.
vmstart + 2::second => time afterVmStarted;
A keyword for this may not be enough. The following is a attempt to create my own "birth" keyword expressing this. I can't get it smaller then this and I would say this is quite perverse in a way; //strongly typed meets strongly timed :¬p //at least it runs and works.... now - ((now /samp)::samp) => time birth; I'd say this means casting can make sense but I'm open to ideas. Of course, you could just approximate this functionality by having this line
run the moment the vm starts:
now => time vmstart;
Then, you'd be able to the do everything relative to that time. At least, that's how I would solve it.
Maybe you'll like my attempt above too.... well, I think it works.... Kas.
On Jan 7, 2008 1:50 PM, Kassen
<snip> <<
>>; is quite legal and will return a float expressing the amount of minutes the VM has been alive. I see "now" and other times as a duration with the start of the VM as it's start. So; we can divide "now" by a duration and get a float but a float times a duration will always be a "duration" and not a "time", so far, in practice.
Oh, but that's far weirder! I would not have expected that to be legal. So "now" is a strange animal indeed, having traits of both time and duration... Actually, it looks like any time type divided by a duration returns a float. hrm... I wouldn't have guessed.
A keyword for this may not be enough. The following is a attempt to create my own "birth" keyword expressing this. I can't get it smaller then this and I would say this is quite perverse in a way;
//strongly typed meets strongly timed :¬p //at least it runs and works.... now - ((now /samp)::samp) => time birth;
I'd say this means casting can make sense but I'm open to ideas.
I still don't like the idea that a time can be cast as a duration-from-vm-start, however, a "birth" keyword makes sense. Consider this: 2::second => now; // is kind of like "for the next two seconds" or "two seconds from now", etc. if we had some idiom for "since"... like: since(now, birth) => dur aliveTime; // which you could build... or: 2::second + birth => time twoSecAfterBirth; You're right, that would make timing relative to the VM starting up much simpler. your way is clever: //strongly typed meets strongly timed :¬p //at least it runs and works.... now - ((now /samp)::samp) => time birth; But I feel like you shouldn't have to do that. I see how you could easily abstract this using functions, but a keyword for the time that the VM started seems like it would be easier, more global, etc. at least, this returns a -1: now - ((now /samp)::samp) => time birth; <<<(birth - 2::second) /2::second>>>; I was worried... :) -mike
Of course, you could just approximate this functionality by having this
line run the moment the vm starts:
now => time vmstart;
Then, you'd be able to the do everything relative to that time. At least, that's how I would solve it.
Maybe you'll like my attempt above too.... well, I think it works....
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
On 07/01/2008, mike clemow
Oh, but that's far weirder! I would not have expected that to be legal. So "now" is a strange animal indeed, having traits of both time and duration...
Actually, it looks like any time type divided by a duration returns a float. hrm... I wouldn't have guessed.
Yes, and it gets curiouser and curiouser. Any time (including now) divided by a duration returns a float yet a time divided by a float returns a "complaint". I'm not certified mathematician but this seems wrong-ish to me. I mean; if X/Y = Z then (and only then) X/Z = Y or we lose reflexivity in multiplication. In a way that's what we do if we need to devide now by a duration, then multiply the result by one in order to "cast time to duration". I agree that what I suggested *is* rather implicit but I'd also say that cast is a explicit way to do this. I don't think I'd call it more implicit then the (potential) data-loss in casting from a float to a int. I still don't like the idea that a time can be cast as a
duration-from-vm-start, however, a "birth" keyword makes sense. Consider this:
2::second => now; // is kind of like "for the next two seconds" or "two seconds from now", etc.
<snip> I agree, but consider Ge said "2::second => now" is shorthand for "2::second +=> now", I agree with this though I too use the shorthand. your way is clever:
//strongly typed meets strongly timed :¬p //at least it runs and works.... now - ((now /samp)::samp) => time birth;
But I feel like you shouldn't have to do that.
Thank you and here we agree completely (as opposed to 90% elsewhere :¬) ). I would say that this trick is downright abusive and I'd argue that it involves a implicit, hidden, cast. I see how you could easily abstract this using functions, but a keyword
for the time that the VM started seems like it would be easier, more global, etc.
at least, this returns a -1:
now - ((now /samp)::samp) => time birth; <<<(birth - 2::second) /2::second>>>;
I was worried... :)
:¬) the sky isn't falling but considering some of my mathematical games above I think "time" isn't as developed as a datatype as duration is. I would -at this stage- probably recommend developing it further with a more clear relationship between time and duration. From there on keywords and/or casting might make more sense. At that stage either or both might turn out to be needed or make sense. To put it in different words; I see issues here but I realise proposing a cast option was a hasty call to make. At least it made for a good start of a debate and I'm still not convinced yet it's a bad idea per-sé. Yours, Kas.
Kassen wrote:
I see where you are coming from, but "now" really is a duration already, in a way.
<<
>>; is quite legal and will return a float expressing the amount of minutes the VM has been alive. I see "now" and other times as a duration with the start of the VM as it's start. So; we can divide "now" by a duration and get a float but a float times a duration will always be a "duration" and not a "time", so far, in practice.
Seems to me that now / minute => float; should be an error. now is an instant, not a duration. I feel the concepts should be kept separate. michael
On 07/01/2008, Michael Heuer
Seems to me that now / minute => float; should be an error.
now is an instant, not a duration. I feel the concepts should be kept separate.
I thought about this now. There's some merit to it, after all you are very right that instances and durations are separate things and for a moment I considered that yours might be a more logical way out then mine but in a way ChucK derives a lot of power from using these loosely. now - (now % T) => now; ...like in the OTF examples is a good example of that, here "now" acts very much like the duration since the VM's birth and not like a instant. Taking a modulo of a instant makes no sense at all while taking one of a duration does. I'm a bit lost here now (no pun intended but it's funny) perhaps Ge will have some insights to share about the underlying plan. Yours, Kas.
participants (4)
-
Kassen -
Michael Heuer -
mike clemow -
Scott Wheeler