GHC 9.12 and cabal 3.14 release announcement

[Kleidukos]

No description provided.

[geekosaur]

Suggested change

	* SIMD! In the x86: Most floating-point operations and some integer vector operations are supported 128-bit vectors **without LLVM**. [Get in touch](https://matrix.to/#/#ghc:matrix.org) to help with this effort
	* SIMD! On x86, most floating-point operations and some integer vector operations are supported for 128-bit vectors **without requiring LLVM**. [Get in touch](https://matrix.to/#/#ghc:matrix.org) to help with this effort

[Bodigrim]

The crux of the effort was to support vector operations in the native code generator (NCG) instead of LLVM only. Whether NCG actually compiles them to SIMD instructions on x86_64 / NEON on aarch64 / etc. is somewhat secondary (also obviously very important in practice).

I'd say "Vectorised operations are now supported by GHC native code generator and no longer require a separate compilation with LLVM".

[geekosaur]

Right, that was what I was attempting to say.

[Kleidukos]

Does the suggestion still stand? I'm not sure I understand the distinction you're making @Bodigrim, since in my understanding (and I could be very well wrong), vector operations are ultimately tied to SIMD. And the release notes item says:

SIMD support has been added to the X86 native code generator. For the time being, only 128 bit wide vectors are supported, with most floating-point operations implemented, together with a few integer vector operations. Other operations still require the LLVM backend. Contributors welcome!

[geekosaur]

Suggested change

	* As a result, friendship with the `stdcall` calling convention for FFI is ended. Now `ccall` is your best friend.
	* As a result, friendship with the `stdcall` calling convention for FFI has ended. Now `ccall` is your best friend.

[geekosaur]

Hm, actually don't we want to recommend CApiFFI and capi, come to think of it? It goes back to 7.6.1, and I would argue that it's nearly mandatory since ghc switched to generating asm rather than C.

[Bodigrim]

It's not like you can replace stdcall with ccall and keep compiling on 32-bit Windows: the support for Win32 ended, thus stdcall serves no purpose any longer.

[geekosaur]

True, but that also rules out the recommendation for ccall. In any case, I think the deprecation period for 32-bit Windows ending makes that moot: if you want to continue using it you must use an older ghc, which will still support stdcall.

[geekosaur]

TBH I never understood why Microsoft chose to use the Pascal calling convention when nobody to speak of was using a Pascal compiler to write programs for Windows. Yes, strictly speaking it has some advantages, but they're outweighed by the added complexity of needing to switch calling conventions for system APIs.

[Kleidukos]

@bgamari @AndreasPK what's the recommended phrasing here? Should we steer users away from ccall and directly to capi, or is ccall a good intermediate step when they migrate away from stdcall?

[ysangkok]

Shouldn't it be either Cabal or cabal-install? Seems odd to choose lower case.

[ysangkok]

What does this actually mean that 'a deprecation period' has ended? It's not crystal clear whether it means the deprecation was cancelled, the module was removed in 9.14, the module was previously removed before 9.14 or whether it will now get removed, after 9.14 was released. The valediction 'Goodbye' is cute but unnecessary, it would be better to just plainly state that the module is not available in 9.14.

I think it would be better to avoid colloquial or memey language like e.g. the 'friendship has ended, now best friend' meme. It's culture specific and unnecessary, hasn't traditionally been used (at least not according to releases) and I don't understand why now is the time to start using memes.