Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Native Number Support and Improvements #562

Open
praeclarum opened this issue Apr 20, 2017 · 9 comments

Comments

@praeclarum
Copy link

commented Apr 20, 2017

I propose we include support for the CLR's new native numbers and C# binding.

I propose:

  1. Ensuring that explicit conversion from all of F#'s primitive types is supported
  2. Support arithmetic operators
  3. Support generic numeric functions (max, sqrt, etc.)
  4. Perhaps, a new manifest constant suffix to designate native. (Or is this already taken up by IntPtr?)

The existing way of approaching this problem in F# is:

  1. Xamarin has introduced their own native types (nint, nuint, nfloat) in the System namespace which are usable but inelegant from F# since they rely heavily on implicit conversions and some constructors are private/internal.

  2. F# has native int but it is incompatible with Xamarin's current work and the CLR's future work.

Pros and Cons

The advantages of making this adjustment to F# are that F# can be used for mobile development.

The disadvantage of making this adjustment to F# is it introduces yet another numeric type, one that can be potentially confused with existing support for System.IntPtr.

Extra informtion

Estimated cost (XS, S, M, L, XL, XXL): S/M (depends on how good we make it)

If you browse Xamarin F# code for native int use, you will see the current state of the art. I think we can do better!

Here is an example of some code using it that isn't too bad: https://gist.github.com/praeclarum/c9e2d1a0f1089cb4025a

But things get much nastier if we want to support arithmetic with some constants or other variables.

let x = 42.0
let y = 3.14
let point = CGPoint (nfloat x, nfloat y) + CGPoint (nfloat 0.0, nfloat 1.0)
let angle = atan2 (float point.Y) (float point.X) |> nfloat

As you can see, F# code ends up being littered with types everywhere. In C#, this would be:

var x = 42;
var y = 3.14;
var point = new CGPoint (x, y) + new CGPoint (0, 1);
var angle = Math.Atan2 (point.Y / point.X);

Things basically go bad when you start mixing your model data (real data that is platform independent) with the data that native platforms plan to display (which is usually native sized). Problems compound when you start using native data structures (CGPoint) and try to do math with them.

Affadavit (must be submitted)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I would be willing to help implement and/or test this
  • I or my company would be willing to help crowdfund F# Software Foundation members to work on this
@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Apr 20, 2017

Thanks, I added a link to this to the CoreFX doc here: dotnet/corefxlab#1488

This can be considered approved-in-principle. You can go ahead and add an RFC for this if you like (it would be a while before I get any time to look at this)

@cloudRoutine

This comment has been minimized.

Copy link
Collaborator

commented Apr 20, 2017

@praeclarum you can define a new literal for a prototype of this using custom numeric types

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Apr 25, 2017

It seems the C#/.NET teams will be taking an erase-to-IntPtr-plus-metadata-annotations approach to this, see dotnet/corefxlab#1471 (comment)

If so this means there is very little work needed for F# here, just deciding on how export happens

If anyone spots a change in plan from this please let me know on this thread.

@enricosada

This comment has been minimized.

Copy link

commented Jun 30, 2017

can we add a modifier too? like for decimal?

so like:

> 10.0m ;;
val it : decimal = 10.0M

> 10.0n ;;
val it : nfloat = 10.0N
> 10n ;;
val it : nint = 10N

this avoid at least for constants

let x = 42.0
let y = 3.14
let point = CGPoint (nfloat x, nfloat y) + CGPoint (0.0n, 1.0n)
let angle = atan2 (float point.Y) (float point.X) |> nfloat
@realvictorprm

This comment has been minimized.

Copy link
Member

commented Sep 22, 2017

@dsyme what's the status of this? Can we at least apply what @enricosada suggested?

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Sep 25, 2017

@realvictorprm Yes, we could apply this, but I'd need to understand the exact final status of the CLR feature

@cartermp

This comment has been minimized.

Copy link
Member

commented Sep 25, 2017

cc @KrzysztofCwalina for more information about this:

Yes, we could apply this, but I'd need to understand the exact final status of the CLR feature

@dsyme

This comment has been minimized.

Copy link
Collaborator

commented Nov 16, 2017

@cartermp

This comment has been minimized.

Copy link
Member

commented Nov 16, 2017

Yeah, I think they're just all-in on getting nullable reference types working 😄

@dsyme dsyme added the needs rfc label Dec 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.