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.