Comments on: Ease of FatRat construction

By: colomon

colomon — Wed, 19 Oct 2011 16:16:48 +0000

As far as I know, this certainly could be implemented by a macro once that functionality is available. It might even work now in Rakudo, though it would be useless there at the moment as Rakudo does not support FatRat yet.

By: SMR

SMR — Wed, 19 Oct 2011 16:11:34 +0000

A postfix F feels too much like the postfix for a float literal in other languages (like Java). How about R instead?

Regarding colomon’s comment, can a syntactic/literal postfix contain, say, a dot? Would “.R” be easy to use? Or would just make parsing insane? .3333.R ?

By: heir

heir — Tue, 18 Oct 2011 21:21:38 +0000

So… if not a postfix operator, why not a macro?

By: colomon

colomon — Tue, 18 Oct 2011 19:35:55 +0000

Choosing FatRat always needs to be explicit, IMO. That’s because once you’ve got one FatRat, every downstream result of math operations is also a FatRat, and suddenly the implicit FatRat means you’ve accidentally made all your math operations become hogs in time and space.

By: Moritz

Moritz — Tue, 18 Oct 2011 19:30:54 +0000

I’d propose to make Rat literals automatically chose FatRat if they would otherwise lose precision.

You could write the constructor as

LFT.new(|{ q => 1, r => 0, s => 0, t => 0}».FatRat});

Maybe some other literal form would be nice too, but I always felt that the type postfixes for number literals in C/C++ are the wrong approach (though I can’t really explain why).