Re: Emacs ffi

[Christopher Dimech <dimech@gmx.com>]

> Sent: Sunday, August 18, 2024 at 1:21 AM
> From: "Stefan Kangas" <stefankangas@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Eli Zaretskii" <eliz@gnu.org>
> Cc: acorallo@gnu.org, suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
> Subject: Re: Emacs ffi
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Incorporating a mathematical library into Emacs, based on Calc, is not
> > just feasible but highly beneficial.
>
> I think we all agree that a general purpose mathematical library would
> be interesting.  The point is that the specifics of how it is
> implemented matters.  If you think basing it on Calc is the best way
> forward, then I invite you to get started.  I mean this sincerely.

Others thought that basing it on Calc is a good way forward.  It does
make for a good library having looked into its mathematical capabilities.

E. Berg's initial inclination to create a mathematical library for Emacs
was a commendable idea to expand the capabilities within the editor.
However, he did not want to delve into Calc, but on his own
implementations.

The disappointment to some was grounded in a strong argument from the
core Emacs developers, who emphasized the importance of having a robust,
well-integrated library that could match or exceed the functionality of
the existing Calc package.  The high bar set for quality and integration
within the Emacs ecosystem means that such a project would be a major
undertaking, likely contributing to the reluctance to pursue it.

> Unfortunately, this discussion currently seems to be going in circles.
> Since nothing helps ground a discussion more than working code, I
> propose that we revisit this topic when we have something more concrete
> to consider.

It is for the core emacs groups leading the development to establish the
principal design that is user-friendly and flexible to allow for easy
extension, without imposing overly stringent requirements beyond what is
typically expected for standard Emacs packages. My role is not to
overstep but to provide occasional input.

At this moment, it's unclear whether the decision will lean toward
implementing an FFI (Foreign Function Interface) or pursuing a different
approach. However, having Emacs provide a built-in solution seems more
conducive to seamless integration, allowing for a more cohesive
experience.

I could contribute concrete mathematical operations and assist in
refining the library as it evolves. While it doesn't need to be a
comprehensive solution, it should be robust enough to meet current needs
and provide a foundation for further development as required in a
collaborative approach.  Ultimately, I adhere to established design,
working within the framework set by the core Emacs team to create a
valuable tool.