On 07/01/2008, mike clemow <gelfmuse@gmail.com> wrote:

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.