I like what we currently have. It isn't that much more verbose than C#. In a way, it seems easier to spot out lambdas in a codebase when you see 'fun'.
59 votesplanned · Adminfsharporg-lang (F# Software Foundation Language Group, F# Software Foundation) responded
Approved in principle, per my comment below.
Link to RFC to follow
Don Syme, F# Language and Core Library Evolution
This is tricky. If Option<'T> can be made into a struct, then discriminated unions should be made into structs.
Really good post about it. Thanks for the link.
It definitely feels like a hack if you try to make it behave exactly like Haskell.
I wouldn't say it's currently a hack; it's just how it's done. But, I think something like this would have potential if we can figure out what the actual benefits are and how do to design it in a way without confusing anyone.
More info: http://www.infoq.com/interviews/F-Sharp-Don-Syme
Number 6 shows Don talking about type classes.
10 votesstarted · Adminfsharporg-lang (F# Software Foundation Language Group, F# Software Foundation) responded
I’m marking this as “approved” for F# 4.0+.
A pull request for this feature has been submitted here:
Don, F# Language Design
Yea, it was only recently did I found out that nativeptr<'T> is really just a nativeint. Thanks for giving more info on it.
You make a good point on the type safety, but as we are already in an unsafe context and potentially messing with unmanaged memory, a NativePtr.cast would only benefit handling memory. Is there a better way of going about it? I would interested in an alternative.
Definitely agree with this! I've had to create my own naive versions of some of these. https://github.com/TIHan/FQuake3/blob/4d5a5702a6ae06cd8e4b57431e656ab4dfd39ac4/src/FSharp/Engine/NativeInterop.fs#L73
With your listings, maybe another one that casts a nativeptr to another nativeptr type would be super useful as well, though may not be related to your intrinsics. Perhaps, NativePtr.cast ?
That stinks you were in the hospital Bryan! I hope you are feeling better!
If macros were going to be implemented, a compiler directive or switch would be the least of all evils. That is my opinion and I could live with it.
This feature currently has the most votes, so it is clear that a lot of people want this for a good reason.
I want to be convinced that macros would really benefit F#; because I really fear this feature a lot. I'm looking for the bigger picture here, but so far all I see is syntactic sugar. I read there is the framework side, but I don't have a clear understanding of the problems devs are facing when developing a framework.
Could anyone show some example problems that macros would truly help resolve? Syntactic sugar is not one of them.
If F# has proper macros, this means you would be able to create another language inside F#. Do we really want that?
"Implement F# features outside the compiler so that even idiomatic F# code can be back-ported to OCaml."
Why would you want to use macros as a means of back-porting? Arn't there better ways that don't infect the language itself?
"Macros are used to customise syntax. For example, you might want to replace the pattern "| Add(f, g) -> d f + d g" with "| f+g -> d f + d g"."
Couldn't we find a way to extend the F# language that makes something like this possible without relying on macros?
"Let the community take more of a role in prototyping new F# language features with macros instead of forcing them to hack their own private compiler branch and thereby losing all portability."
A true prototype of a language feature is to have a modified version of the compiler. That is the proper way. Using macros for a prototype do not tell you what is involved in actually implementing a language feature.
"If we can allow macros to be imported based on a containing namespace / module, various DSL contexts could be opened separately, without clashing"
How is this a use case for a need to use macros?
"I can't begin to describe how much I dislike GUI development just because you have to manually raise events and legit repeat yourself again and again and again, which just results in filthy messy code."
You can create abstractions already, or even use type providers to generate all the mess so you don't have to.
"for instance, I highly dislike having to re-type this again and again:
So we can use macros for anyone to call what this behavior does anything they want? I agree that I dislike typing that again and again; but, I feel like we could figure out a simple language feature that could solve this in an idiomatic way.
For games, inlining functions help a lot especially for linear algebra math operations. It's much more idiomatic to use inlined functions than macros for performance. It's not always true, however, that inlining a function will give you better performance, in fact, it can give you worse depending on the function if it's long + complex. A macro would be no better here.
I'm doing this myself now and it works just as good as any macro would; however, there are a few outstanding issues with struct param types with inlined functions, but I have a slightly edited compiler that fixes that.
I guess that is pretty much what I would want.
Though, I am wondering how multiple constructors would work though in regards to using the record syntax.
If it can be extended or tweaked a little, this would be useful for structs as well. I'm currently having to do this: https://github.com/TIHan/FQuake3/blob/f6ad8a5809db7d57961a55ffd93e1ba0de85dde7/lib/FQuake3.Utils/src/FQuake3.Utils/math.fs#L117 to get a similar effect. Though, there are more than one possible constructors, which may throw a wrench in this...
63 votesplanned · Adminfsharporg-lang (F# Software Foundation Language Group, F# Software Foundation) responded
Approved in principle subject to RFC and well-tested implementation being submitted as PR.