Ok, I'm new to programming but I'm finding Fan's decisions elegant so far. Still there are things that could be upgraded. Lot of the things you discussed like multiple operators (addX, addC...) and I won't discuss them.

• Why are decimal considered default? When I type 1.0 I expect it to be Float. So why does it default to Decimal instead? I mean I'm more likely to use Float than Decimal since Decimal is missing a lot of API and has a much lower use case than Float.
• Speaking of which why aren't there random functions for Float or Decimal. Decimal I can understand but it seems weird being unable to generate a random float (while being able to generate a random Int).
• I was kinda disappointed that := operator was left as declaration only. I think it adds noise this way than just using := or = for both declaration and assignment respectively.
• Seeing project Coin for Java do you intend to implement multiple Exception dispatch.

So instead of

try
{
    ...something 
{
catch (CancelledErr ex)
{
    ex.trace
}
catch (CastErr ex)
{
    ex.trace
}

You could write

try
{
    ...something 
{
catch (CancelledErr | CastErr ex)
{
    ex.trace
}

It is just something that removes a lot of boiler plate code without adding much noise.

That's all. But if other people have some suggestions feel free to post them here.

Either way Andy, Brian and others keep the awesome work.

Hey Daniel - thanks for the support! I actually dig the multiple Exception handling. VB has this, and this is essentially how I already implement Fan exceptions in .NET using filters. I think this would be a good feature to add.

Why are decimal considered default? When I type 1.0 I expect it to be Float. So why does it default to Decimal instead? I mean I'm more likely to use Float than Decimal since Decimal is missing a lot of API and has a much lower use case than Float.

I think in normal usage, Decimal is what you want. If its simply an issue of APIs I'm sure we can add to Decimal - were there things you were looking for in particular?

Speaking of which why aren't there random functions for Float or Decimal. Decimal I can understand but it seems weird being unable to generate a random float (while being able to generate a random Int).

Seems like an easy thing to add.

I was kinda disappointed that := operator was left as declaration only. I think it adds noise this way than just using := or = for both declaration and assignment respectively.

This was one of the first things we added, and I think this is a great feature. It clearly distinguishes where a variable is declared. Plus it allows us to use type inference in declarations.

In my day-to-day Java enterprise programming job, I hardly ever use float or double even if the non-literal BigDecimal is such a pain in the $#"%.

So I like the fact that Fan uses decimal per default and forces the developer to explicitly declare his favor of speed (base2/float) over accuracy (base10/decimal). I do believe modern CPU's have bridged the gab somewhat in performance since the IEEE-754 standard of 1985.

catch (CancelledErr | CastErr ex)

What is the type of ex? Adding union types to the language just to make some rare special cases of exception handling a bit simpler seems a bit of an overkill. So sys::Err?

At runtime you'd get the type that was thrown - for the compiler, yeah you'd have to drop down to sys::Err, and use casts or dynamic invoke. Though since 99% of the time you're only calling Err methods, that seems fine.

I think in normal usage, Decimal is what you want. If its simply an issue of APIs I'm sure we can add to Decimal - were there things you were looking for in particular?

What I'd like to see would probably be sqrt and sin/cos/tan/atan as well as random functions.

I was developing a small Complex number test class just to discover halfway through I had no option of generating random Float/Decimals. I'm a novice so admittedly this is kinda of big issue for me (though I guess I could just google the algorithm) still I don't see a reason why anyone would need to duplicate the effort by building his own Random class just so he could test his class.

There certainly ought to be a random for Float at least; probably it should match the "standard" [0,1) at 64-bit precision.

For Decimal I think it's less clear: Decimal is intended to be an exact representation of an arbitrary-precision number, so I'm not clear on how random (or functions like sqrt that pretend to return irrationals/transcendentals) ought to be implemented.

@DanielFath: Float is what you (probably) should be using for that; I kind of agree that literals being Float by default would make sense, but when you're doing things that require exact precision it goes the other way.

If it's just for a quick test you could have done something like Int.random / (Float)Int.maxVal. But I agree that the library should be extended.

Hi Daniel,

Thanks for your feedback.

Why are decimal considered default?

Best to refer to the original discussion #201. Basic gist is that Decimal is likely used more often for business/IT applications. I use Float almost exclusively since my domain is sensor data stuff, and it really hasn't bothered me much.

Speaking of which why aren't there random functions for Float or Decimal. Decimal I can understand but it seems weird being unable to generate a random float

Good idea. I added Float.random changeset

I agree with Kevin that Decimal.random probably doesn't make sense.

I was kinda disappointed that := operator was left as declaration only. I think it adds noise this way than just using := or = for both declaration and assignment respectively.

It is to avoid declaring a new variable just because you made a typo in your identifier name. That problem has bitten me enough in Python that I think it is well worth the extra character. Of course just a matter of taste.

Seeing project Coin for Java do you intend to implement multiple Exception dispatch.

Maybe, but not for 1.0. If you are coming from Java world, you will find that you use catch much less often in Fan because exceptions aren't checked. In fact, I am not sure I've ever had a case where I'd even use that feature in Fan if it was available.

Thanks for the replies guys. It did shed some light on my problems.

Speaking of my Complex example, is it possible for Complex (if it is const) to inherit Num class? From what I've seen it has a private constructor so I can't access it in my Complex.make. Is this intentional? If so why? Wouldn't Complex and other numerical construct have an incentive to extend this value.

I like defValue but personally I think you could add a oneValue. defValue is great since it is neutral to adding (a.add(defValue)==a). In same context a oneValue would be neutral to multiplication as in (a.mult(oneValue)==a). It is not essential but it would be a nice addition.

Speaking of my Complex example, is it possible for Complex (if it is const) to inherit Num class?

I definitely think it should, but I was trying to keep that hidden for now as we figure out platform porting issues (for example how it should all work in JavaScript). So I'll probably keep it that way for short term, and look at fixing it once we've got 1.0 all wrapped up.

I like defValue but personally I think you could add a oneValue.

I really just added defVal as part of a convention for how things like sys::Type.make work so that you can use Type.make with classes like Bool, Str, etc. Since we support float and decimal literals directly, I am not Decimal.oneVal makes sense over 1d?

Sorry for such a late reply. I kinda forgot about it.

If I remember my algebra correctly whenever you have defined + over a group you have an element 0 which is neutral to adding (a+0=a). Similarly whenever you have 1 and multiplication in a group it will by default be neutral to multiplication (a*1=1).

What I'm actually proposing is to make type system more mathematical by adding to oneVal to Num. Also Bool could use minus, plus, multi and negate in addition to oneVal as well.

I often remember using plus and multiplication when dealing with with bits or booleans. (A+B = A or B, A*B = A and B, -A = not A, A-B = A plus - B)

What I'm actually proposing is to make type system more mathematical by adding to oneVal to Num.

I think the problem is that Num is abstract. Fantom doesn't really support a true numeric tower such as Lisp languages, so its about mathematical as Java.

Also Bool could use minus, plus, multi and negate in addition to oneVal as well.

Although it might be ok for math, it seems a little obscure for programming. I think the tradeoff comes down to this: it is probably a lot more useful for an operator like + on Bools to give you a compile time error, rather than try to figure out how to use all the operators for common types like Bool.

You can't define a neutral element per type as it depends on the operation (as you write yourself). You could define one per operation: 0 for addition of real numbers, 1 for multiplication of real numbers, true for logical and, false for logical or, the identity function for function composition, the zero matrix for addition of matrices, the identity matrix for matrix multiplication, ... . And while you are at it you could define an absorbing element for some operations like 0 for multiplication, false for logical and, ... . And I'm sure you find other such things in abstract algebra but I'm not sure we need that in Fantom.

And you don't make Fantom more mathematical by using + for and and - for or and not. In math you use ∧, ∨ and ¬ respectively. It's electrical engineering which uses + for and, etc. But electrical engineers do several things different from mathematicians, e.g. they use j instead of i for the imaginary unit. But I don't think Fantom is especially suited for electrical engineering.