as for Calc and the math library

as for Calc and the math library

[Emanuel Berg]

;; __________________________________________________________
;; ``````````````````````````````````````````````````````````
;; |                         
;; 3                        CCUG-ML                        60
;;                                                          |
;; __________________________________________________________
;; `-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-`-

I have now been using the Calc library a bit!

Not a lot. Very little.

But I can already say about Calc that it is very good.
The code is good as well and as for math it is at a very
high level.

But it it is too complicated and the entry level is too high.
It is advanced math but also an advanced program.

We still need a math library that covers like up to the
introductory courses at the university. This should be
accessible with the familiar Elisp syntax.

Every function in math from school and again, maybe including
the introductory courses at the university, should be
available with Emacs notation.

So now, we don't have

(** 4 1)
( ^ 4 1)

(We do have `expt' but notation is important and should be,
for a math library, using "their" symbols and conventions,
not ours, as much as possible.)

We don't have

(defun distance-point (min max)
  (+ min (/ (- max min) 2.0)) )

Or from Logic, we don't have `nand' i.e. (not (and a b)). [last]

All that we don't have, or we do, as Calc can do it - easily.

Okay, so we don't need a new generic library. We need
a generic library which is a complement to all the basic
stuff, we don't have readily available as for now.

Out of respect for Calc there is no need to move it, now need
for that and no practical reason to.

However the new stuff must be totally transparent. When some
dude comes home from school/university and wants to try some
half-basic stuff, this should work instantly using the Elisp
he is used to. It should be "Oh, cool, Emacs has it!" And for
a long time, it should be like that for him.

If at some much later point, he (or she) moves on to "real
Calc", then he is so good we don't have to worry about
him anymore.

So we should have a CCUG-ML project: the Generic Complementary
Math Library Using Calc.

Yes, it would be to some small extent *using* Calc but to
a huge extent it would just be an interface. But 100%
transparent, so one can use Elisp and the common math
notation people know from school.

No long prefixes, no special notation, nothing, as I now know
there is _a lot_ of in Calc. People should be allowed to use
the basics of Calc without knowing it!

It should just be just like when I looked for `**' and `nand',
only this time, they should exist, thru the interface,
using Calc.

IMO!

Here is nand BTW:

(defun nand (&rest conditions)
  (when (member nil conditions)
    t) )

;; (nand)           ; nil
;; (nand 1 2 3)     ; nil
;; (nand nil)       ; t
;; (nand 1 2 nil 3) ; t

;; (not (and))           ; nil
;; (not (and 1 2 3))     ; nil
;; (not (and nil))       ; t
;; (not (and 1 2 nil 3)) ; t

And here is some Calc:

(require 'calc-ext)
(require 'cl-lib)

;; (infx "0 < 10")

(defun infx (str)
  (let* ((exp (math-read-expr str))
         (fun (car exp))
         (new (cons (intern (caar (cl-member fun math-expr-opers :key #'cadr :test #'equal)))
                    (cdr exp))))
    (apply (car new) (cdr new))))

-- 
underground experts united
https://dataswamp.org/~incal

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sun, 11 Aug 2024 00:48:13 +0200
> 
> We don't have
> 
> (defun distance-point (min max)
>   (+ min (/ (- max min) 2.0)) )

Once again, if we want this and other functions for a math library in
Emacs, we should make sure the algorithms used are solid and stable,
and in particular don't cause errors unless the result really cannot
be expressed as a valid number.  For example, in the above, the
expression (- min max) could overflow when min/2 - max/2 that it
calculates is a valid number.

If Emacs is to have a math library, the library must use high-quality
mathematical and numerical algorithms that are well-known and
described in many textbooks on this subject matter.  This high quality
should start from the simplest calculations, and go all the way to the
most complex ones.  For example, even summing many float values
naïvely will eventually lose accuracy.  E.g., try adding 10 values of
1e-16 followed by the value of 1, that is

  (+ 1.0 1.e-16 1.e-16 1.e-16 1.e-16 1.e-16 1.e-16 1.e-16 1.e-16 1.e-16 1.e-16)

Doing this naïvely will lose all the small values, as if they were not
there at all.  So even such seemingly-simple operations might need
non-trivial algorithm to avoid losing accuracy when it could be kept.

Re: as for Calc and the math library

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> If Emacs is to have a math library, the library must use high-quality
> mathematical and numerical algorithms that are well-known and
> described in many textbooks on this subject matter...

I agree with this point, but I suspect that writing such a library from
scratch might be a bit difficult.

May I suggest an alternative: abstract out GNU Calc math routines to be
available from Elisp without having to read Calc sources.
Such a task would require:
1. Documenting some Calc data structures
2. Possibly refactoring some Calc functions to use simpler API.

It would be a much easier task and can improve the existing
functionality.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

as for Calc and the math library

[Christopher Dimech]

> Sent: Monday, August 12, 2024 at 4:45 AM
> From: "Ihor Radchenko" <yantar92@posteo.net>
> To: "Eli Zaretskii" <eliz@gnu.org>
> Cc: "Emanuel Berg" <incal@dataswamp.org>, emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > If Emacs is to have a math library, the library must use high-quality
> > mathematical and numerical algorithms that are well-known and
> > described in many textbooks on this subject matter...
>
> I agree with this point, but I suspect that writing such a library from
> scratch might be a bit difficult.
>
> May I suggest an alternative: abstract out GNU Calc math routines to be
> available from Elisp without having to read Calc sources.
> Such a task would require:
> 1. Documenting some Calc data structures
> 2. Possibly refactoring some Calc functions to use simpler API.
>
> It would be a much easier task and can improve the existing
> functionality.  - Ihor Radchenko

That would be my recommendation.  Calc already offer robust mathematical
routines.  Doing a mathematical library is not difficult but required focus
and the ability to deal with complicated implementation, not just applying
direct solutions.

Re: as for Calc and the math library

[Emanuel Berg]

Ihor Radchenko wrote:

> I suspect that writing such a library from scratch might be
> a bit difficult.
>
> May I suggest an alternative: abstract out GNU Calc math
> routines to be available from Elisp without having to read
> Calc sources. Such a task would require:
;
> 1. Documenting some Calc data structures
> 2. Possibly refactoring some Calc functions to use simpler API.
>
> It would be a much easier task and can improve the
> existing functionality.

Very smart suggestion.

-- 
underground experts united
https://dataswamp.org/~incal

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Emanuel Berg <incal@dataswamp.org>, emacs-devel@gnu.org
> Date: Sun, 11 Aug 2024 16:45:54 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If Emacs is to have a math library, the library must use high-quality
> > mathematical and numerical algorithms that are well-known and
> > described in many textbooks on this subject matter...
> 
> I agree with this point, but I suspect that writing such a library from
> scratch might be a bit difficult.

It depends on the scope and the person who'd like to work on that.

> May I suggest an alternative: abstract out GNU Calc math routines to be
> available from Elisp without having to read Calc sources.
> Such a task would require:
> 1. Documenting some Calc data structures
> 2. Possibly refactoring some Calc functions to use simpler API.
> 
> It would be a much easier task and can improve the existing
> functionality.

I don't think I understand well enough what will this entail in
practice.  Can you show an example of doing this for a couple of
functions?

In any case, this job, as any other job in Emacs, needs its
volunteer(s).  Until we have such volunteers, it's all academic.

as for Calc and the math library

[Christopher Dimech]

> Sent: Monday, August 12, 2024 at 5:59 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Ihor Radchenko" <yantar92@posteo.net>
> Cc: incal@dataswamp.org, emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> > From: Ihor Radchenko <yantar92@posteo.net>
> > Cc: Emanuel Berg <incal@dataswamp.org>, emacs-devel@gnu.org
> > Date: Sun, 11 Aug 2024 16:45:54 +0000
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > If Emacs is to have a math library, the library must use high-quality
> > > mathematical and numerical algorithms that are well-known and
> > > described in many textbooks on this subject matter...
> >
> > I agree with this point, but I suspect that writing such a library from
> > scratch might be a bit difficult.
>
> It depends on the scope and the person who'd like to work on that.
>
> > May I suggest an alternative: abstract out GNU Calc math routines to be
> > available from Elisp without having to read Calc sources.
> > Such a task would require:
> > 1. Documenting some Calc data structures
> > 2. Possibly refactoring some Calc functions to use simpler API.
> >
> > It would be a much easier task and can improve the existing
> > functionality.
>
> I don't think I understand well enough what will this entail in
> practice.  Can you show an example of doing this for a couple of
> functions?
>
> In any case, this job, as any other job in Emacs, needs its
> volunteer(s).  Until we have such volunteers, it's all academic.

For good mathematical libraries, you require a practicing applied
mathematician.  A programmer is not enough.

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: Ihor Radchenko <yantar92@posteo.net>, incal@dataswamp.org,
>  emacs-devel@gnu.org
> Date: Sun, 11 Aug 2024 20:17:48 +0200
> 
> For good mathematical libraries, you require a practicing applied
> mathematician.  A programmer is not enough.

That's not true.  A programmer experienced in numerical computations
is more than enough, because the relevant algorithms are known and
described in the literature, so there's no need to invent them.

as for Calc and the math library

[Christopher Dimech]

> Sent: Monday, August 12, 2024 at 6:32 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: yantar92@posteo.net, incal@dataswamp.org, emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: Ihor Radchenko <yantar92@posteo.net>, incal@dataswamp.org,
> >  emacs-devel@gnu.org
> > Date: Sun, 11 Aug 2024 20:17:48 +0200
> >
> > For good mathematical libraries, you require a practicing applied
> > mathematician.  A programmer is not enough.
>
> That's not true.  A programmer experienced in numerical computations
> is more than enough, because the relevant algorithms are known and
> described in the literature, so there's no need to invent them.

A mathematician can usually do better than the standard techniques.
Some descriptions in the literature can be quite old and not so up
to date.  Most of the original fortran routines was not done by programmers.

Re: as for Calc and the math library

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > If Emacs is to have a math library, the library must use high-quality
>> > mathematical and numerical algorithms that are well-known and
>> > described in many textbooks on this subject matter...
>> 
>> I agree with this point, but I suspect that writing such a library from
>> scratch might be a bit difficult.
>
> It depends on the scope and the person who'd like to work on that.

Yes, of course. If somebody is up to writing a serious math lib, it
would be better. But having a bit simpler task idea can increase the pool
of potential volunteers.

>> May I suggest an alternative: abstract out GNU Calc math routines to be
>> available from Elisp without having to read Calc sources.
>> Such a task would require:
>> 1. Documenting some Calc data structures
>> 2. Possibly refactoring some Calc functions to use simpler API.
>> 
>> It would be a much easier task and can improve the existing
>> functionality.
>
> I don't think I understand well enough what will this entail in
> practice.  Can you show an example of doing this for a couple of
> functions?

For (1), I was referring to ";;;; Arithmetic routines." in
calc.el. Now, people must simply know the internal format of special
number representations to work with Calc from Elisp.
It might be worth (a) putting them into a proper manual (some kind of
Calc Lisp API description); (b) maybe creating constructor functions to
abstract the types away.

For (2), for starters, Calc functions often do not even have
docstrings. One simply has to guess(?) or read the code to understand
what kinds of values can be passed. For example, take `math-add' - no
docstring, and go try adding invalid arguments:

M-: (math-add "foo" '(frac 1 2))

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p "foo")
  (math-mul "foo" 2)
  (calc-add-fractions "foo" (frac 1 2))
  (math-add "foo" (frac 1 2))

The error checking could be improved, especially since it is a
polymorphic function that is capable of doing things like

(math-add '(vec (frac 1 2) 3 1) '(frac 1 2)) ; => (vec 1 (frac 7 2) (frac 3 2))

but somehow not

M-: (math-add 0.1 '(frac 1 10))

Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p 2.0)
  (math-gcd 2.0 10)
  (math-make-frac 2.0 10)
  (calc-add-fractions 0.1 (frac 1 10))
  (math-add 0.1 (frac 1 10))

> In any case, this job, as any other job in Emacs, needs its
> volunteer(s).  Until we have such volunteers, it's all academic.

Yes, of course. I was hoping that Emanual (who is apparently interested
in this topic, or at least in improving Elisp) can be the one.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: as for Calc and the math library

[Emanuel Berg]

Ihor Radchenko wrote:

> Yes, of course. I was hoping that Emanual (who is apparently
> interested in this topic, or at least in improving Elisp)
> can be the one.

Thanks for that but after the controversy I lost the
enthusiasm just a little bit since that was very unpleasant,
but it is all good because now my own programming ideas keep
me busy instead!

You need to reach out to the young guys studying math at
universities today, one thinks all they do all day is math but
almost _all_ of them are into computers as well, how many will
use Emacs I don't know but this is the person you want for
this job :)

-- 
underground experts united
https://dataswamp.org/~incal

New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Ihor Radchenko]

Emanuel Berg <incal@dataswamp.org> writes:

> Ihor Radchenko wrote:
>
>> Yes, of course. I was hoping that Emanual (who is apparently
>> interested in this topic, or at least in improving Elisp)
>> can be the one.
> ...
> You need to reach out to the young guys studying math at
> universities today, one thinks all they do all day is math but
> almost _all_ of them are into computers as well, how many will
> use Emacs I don't know but this is the person you want for
> this job :)

Hmm. This reminds me of Google Summer of Code.
Eli, have you considered using GSC to get volunteers for implementing
some moderately difficult Emacs features? Since GSC provides financial
incentive, it may be possible to get student volunteers.

Of course, someone still needs to mentor the students, but that's less
effort compared to actually writing all the code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Aug 2024 06:28:21 +0000
> 
> Hmm. This reminds me of Google Summer of Code.
> Eli, have you considered using GSC to get volunteers for implementing
> some moderately difficult Emacs features? Since GSC provides financial
> incentive, it may be possible to get student volunteers.
> 
> Of course, someone still needs to mentor the students, but that's less
> effort compared to actually writing all the code.

People, including the other co-maintainers, are welcome to pursue
this, but I personally have no free time or resources to do that.

I can only say that it would be harder for a casual contributor to do
a GSoC-style job for Emacs than for other projects, because Emacs has
a lot of specialized needs and requirements that take time to learn.
But maybe this is not an obstacle.

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Joel Reicher]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 12 Aug 2024 06:28:21 +0000
>>
>> Hmm. This reminds me of Google Summer of Code.
>> Eli, have you considered using GSC to get volunteers for 
>> implementing some moderately difficult Emacs features? Since 
>> GSC provides financial incentive, it may be possible to get 
>> student volunteers.
>
> I can only say that it would be harder for a casual contributor 
> to do a GSoC-style job for Emacs than for other projects, 
> because Emacs has a lot of specialized needs and requirements 
> that take time to learn.  But maybe this is not an obstacle.

Does GSC have an 'avenue' for working on bugfixes rather than 
features?

I know that's not where this thread started, and it's 
significantly less glamorous, but the requirements for a bugfix 
tend to be more immediately clear than a 'library'.

Regards,

        - Joel

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Ihor Radchenko]

Joel Reicher <joel.reicher@gmail.com> writes:

>>> Eli, have you considered using GSC to get volunteers for 
>>> implementing some moderately difficult Emacs features? Since 
>>> GSC provides financial incentive, it may be possible to get 
>>> student volunteers.
>>
>> I can only say that it would be harder for a casual contributor 
>> to do a GSoC-style job for Emacs than for other projects, 
>> because Emacs has a lot of specialized needs and requirements 
>> that take time to learn.  But maybe this is not an obstacle.
>
> Does GSC have an 'avenue' for working on bugfixes rather than 
> features?

AFAIK, no. It is based on well-defined projects.
Some nontrivial bugfixes may be worth a whole project, but I doubt that
having a goal like "close N bugs" will qualify.

> I know that's not where this thread started, and it's 
> significantly less glamorous, but the requirements for a bugfix 
> tend to be more immediately clear than a 'library'.

If we aim for volunteers to fix bugs, it should probably be some other
funding scheme; not GSoC. I am not aware about anything existing.
The only somewhat relevant thing I recall was crowdfunding scheme like
code bounty (proposed in the past on the list), but that is also more
suitable for new features.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Pedro]

[-- Attachment #1.1.1: Type: text/plain, Size: 886 bytes --]

On 2024-08-12 20:59, Ihor Radchenko wrote:
> Joel Reicher <joel.reicher@gmail.com> writes:
>
> (...)
>
>> I know that's not where this thread started, and it's
>> significantly less glamorous, but the requirements for a bugfix
>> tend to be more immediately clear than a 'library'.
> If we aim for volunteers to fix bugs, it should probably be some other
> funding scheme; not GSoC. I am not aware about anything existing.
> The only somewhat relevant thing I recall was crowdfunding scheme like
> code bounty (proposed in the past on the list), but that is also more
> suitable for new features.

Let me share these links, if it helps to fund specific emacs stuff

- https://www.sovereigntechfund.de/programs
- https://www.sovereigntechfund.de/programs/applications
- 
https://docs.opentech.fund/otf-application-guidebook/appendix-iv-alternative-sources-of-support

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3323 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Ihor Radchenko]

Pedro <pinmacs@cas.cat> writes:

>> If we aim for volunteers to fix bugs, it should probably be some other
>> funding scheme; not GSoC. I am not aware about anything existing.
>> The only somewhat relevant thing I recall was crowdfunding scheme like
>> code bounty (proposed in the past on the list), but that is also more
>> suitable for new features.
>
> Let me share these links, if it helps to fund specific emacs stuff
>
> - https://www.sovereigntechfund.de/programs
> - https://www.sovereigntechfund.de/programs/applications

This looks interesting, but I am afraid that Emacs may not exactly
qualify to fit their mission.

I am looking at https://www.sovereigntechfund.de/programs/applications,
and they write

    The Sovereign Tech Fund invests in open digital base technologies
    that are vital to the development of other software or enable
    digital networking. We invest in projects that benefit and
    strengthen the open source ecosystem. Examples include libraries for
    programming languages, package managers, open implementations of
    communication protocols, administration tools for developers,
    digital encryption technologies,...
    
    We are currently not looking for user-facing applications, such as
                     ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^
    messaging apps or file storage services. If this changes, we will
    announce it here.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Ihor Radchenko]

Pedro <pinmacs@cas.cat> writes:

> Let me share these links, if it helps to fund specific emacs stuff
> ...
> - 
> https://docs.opentech.fund/otf-application-guidebook/appendix-iv-alternative-sources-of-support

I reviewed this one.
I can only see a single fund that might be relevant - Microsoft
FOSS. (Please correct me if I missed something)

However, Microsoft FOSS is not application-based - Microsoft employees
choose. They also link to a couple of funds from other companies that
work in similar ways.

I guess that it is technically possible to participate if we somehow
spread the word to relevant company employees that Emacs could make use of
such a fund. Here is a list of links with several companies running
FOSS funds based on employee selection:
- https://github.com/microsoft/foss-fund
- https://engineering.salesforce.com/announcing-the-first-foss-contributor-fund-recipient-60a295201497/
- https://fossfunders.com/ (this one looks promising, but also
  suspicious - not much info on their website, no rules, just "contact
  us privately")

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli, have you considered using GSC to get volunteers for implementing
>> some moderately difficult Emacs features? Since GSC provides financial
>> incentive, it may be possible to get student volunteers.
>> 
>> Of course, someone still needs to mentor the students, but that's less
>> effort compared to actually writing all the code.

> I can only say that it would be harder for a casual contributor to do
> a GSoC-style job for Emacs than for other projects, because Emacs has
> a lot of specialized needs and requirements that take time to learn.
> But maybe this is not an obstacle.

May you elaborate?
The interested students will likely also be at least casual Emacs users.
So, some degree of familiarity is expected.
Other than that, how is Emacs dramatically different from working with
any other large codebase?

> People, including the other co-maintainers, are welcome to pursue
> this, but I personally have no free time or resources to do that.

Adding Stefan and Andrea to CC.

To add more details, FSF/GNU qualifies as a valid mentor organization
for GSoC. Org mode project even participated in it in the past:
https://orgmode.org/worg/archive/gsoc2012/orgmode-gsoc2012-ideas.html
AFAIR, there was a request from GNU this spring to submit proposals.

So, what I am talking about is not a theoretical idea. It can be done.

What is needed is a formulation of projects/features that are desired.
Mentors do not have to be maintainers. Experienced Emacs contributors
can be the mentors (also, mentoring a student can be a good addition to
some types of CVs).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Andrea Corallo]

Ihor Radchenko <yantar92@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Eli, have you considered using GSC to get volunteers for implementing
>>> some moderately difficult Emacs features? Since GSC provides financial
>>> incentive, it may be possible to get student volunteers.
>>> 
>>> Of course, someone still needs to mentor the students, but that's less
>>> effort compared to actually writing all the code.
>
>> I can only say that it would be harder for a casual contributor to do
>> a GSoC-style job for Emacs than for other projects, because Emacs has
>> a lot of specialized needs and requirements that take time to learn.
>> But maybe this is not an obstacle.
>
> May you elaborate?
> The interested students will likely also be at least casual Emacs users.
> So, some degree of familiarity is expected.
> Other than that, how is Emacs dramatically different from working with
> any other large codebase?
>
>> People, including the other co-maintainers, are welcome to pursue
>> this, but I personally have no free time or resources to do that.
>
> Adding Stefan and Andrea to CC.
>
> To add more details, FSF/GNU qualifies as a valid mentor organization
> for GSoC. Org mode project even participated in it in the past:
> https://orgmode.org/worg/archive/gsoc2012/orgmode-gsoc2012-ideas.html
> AFAIR, there was a request from GNU this spring to submit proposals.
>
> So, what I am talking about is not a theoretical idea. It can be done.
>
> What is needed is a formulation of projects/features that are desired.
> Mentors do not have to be maintainers. Experienced Emacs contributors
> can be the mentors (also, mentoring a student can be a good addition to
> some types of CVs).

I think I could propose something related improving the native compiler
why not.

But I'm no expert of the GSoC, what is the typical deadline?

Also, a source of topics to work on could be our TODO, it's really full
of interesting things that needs man power (ex the paragraph "Emacs as
word processor").

Thanks

  Andrea

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Ihor Radchenko]

Andrea Corallo <acorallo@gnu.org> writes:

> I think I could propose something related improving the native compiler
> why not.

That would be welcome!

> But I'm no expert of the GSoC, what is the typical deadline?

Not this year. This year GSoC is ongoing.
Here is the timeline:
https://developers.google.com/open-source/gsoc/timeline

I presume that next year should be similar. So, expect ~ end of March
next year.

For mentors, the timeline will be May-September (with May dedicated to
getting to know each other, not actual work). In other words, summer.

> Also, a source of topics to work on could be our TODO, it's really full
> of interesting things that needs man power (ex the paragraph "Emacs as
> word processor").

I'm afraid that "Emacs as word processor" is a bit too much for
_students_ within 3 months timeline. Many other todo entries should be
suitable though.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, Stefan Kangas
>  <stefankangas@gmail.com>
> Date: Sun, 18 Aug 2024 11:48:17 +0000
> 
> Andrea Corallo <acorallo@gnu.org> writes:
> 
> > Also, a source of topics to work on could be our TODO, it's really full
> > of interesting things that needs man power (ex the paragraph "Emacs as
> > word processor").
> 
> I'm afraid that "Emacs as word processor" is a bit too much for
> _students_ within 3 months timeline.

That paragraph includes 20 separate tasks.  They could be performed
one by one, not necessarily all of them together.  At least some of
them are definitely suitable for GSoC type jobs.  For example, "import
/ export RTF files".

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm afraid that "Emacs as word processor" is a bit too much for
>> _students_ within 3 months timeline.
>
> That paragraph includes 20 separate tasks.  They could be performed
> one by one, not necessarily all of them together.  At least some of
> them are definitely suitable for GSoC type jobs.  For example, "import
> / export RTF files".

Doesn't it require completing a couple of display-engine related
features like flowing text around images? Or does import/export imply
something else, not _displaying_ and editing RTF document?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
> Date: Sun, 18 Aug 2024 12:52:22 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'm afraid that "Emacs as word processor" is a bit too much for
> >> _students_ within 3 months timeline.
> >
> > That paragraph includes 20 separate tasks.  They could be performed
> > one by one, not necessarily all of them together.  At least some of
> > them are definitely suitable for GSoC type jobs.  For example, "import
> > / export RTF files".
> 
> Doesn't it require completing a couple of display-engine related
> features like flowing text around images? Or does import/export imply
> something else, not _displaying_ and editing RTF document?

Determining what it means and where it ends is IMO part of the job.
The ability to import RTF files will be a very useful feature even if
it doesn't support images at first.  (And what exactly is a problem
with supporting images, given that Emacs is already capable of
displaying them?)

RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > That paragraph includes 20 separate tasks.  They could be performed
>> > one by one, not necessarily all of them together.  At least some of
>> > them are definitely suitable for GSoC type jobs.  For example, "import
>> > / export RTF files".
>> 
>> Doesn't it require completing a couple of display-engine related
>> features like flowing text around images? Or does import/export imply
>> something else, not _displaying_ and editing RTF document?
>
> Determining what it means and where it ends is IMO part of the job.
> The ability to import RTF files will be a very useful feature even if
> it doesn't support images at first.

Then, it is indeed doable.
If we limit features to current display engine capabilities, simply
something like libpandoc will be good enough for basic import/export
(not just RTF, but a plethora of other formats as well).

> ... (And what exactly is a problem
> with supporting images, given that Emacs is already capable of
> displaying them?)

Some text flowing around the images
....	 ...  with multiple lines of text
   ....	   ....	    . going beside the
  .		.    . image.
  . ....	.     .
    .	   ..  ..     .
    ..	    .....      .
     .........	 ...   .
            ..	    ..

Or text and image displayed on top of each other.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
> Date: Sun, 18 Aug 2024 13:56:46 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Determining what it means and where it ends is IMO part of the job.
> > The ability to import RTF files will be a very useful feature even if
> > it doesn't support images at first.
> 
> Then, it is indeed doable.
> If we limit features to current display engine capabilities, simply
> something like libpandoc will be good enough for basic import/export
> (not just RTF, but a plethora of other formats as well).

The job, as I see it, is to decode the RTF format and convert its
typeface information into Emacs faces.

> > ... (And what exactly is a problem
> > with supporting images, given that Emacs is already capable of
> > displaying them?)
> 
> Some text flowing around the images
> ....	 ...  with multiple lines of text
>    ....	   ....	    . going beside the
>   .		.    . image.
>   . ....	.     .
>     .	   ..  ..     .
>     ..	    .....      .
>      .........	 ...   .
>             ..	    ..
> 
> Or text and image displayed on top of each other.

We aren't afraid of that in EWW and shr.el, are we?  We could use the
same technique here.

Re: RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> If we limit features to current display engine capabilities, simply
>> something like libpandoc will be good enough for basic import/export
>> (not just RTF, but a plethora of other formats as well).
>
> The job, as I see it, is to decode the RTF format and convert its
> typeface information into Emacs faces.

Agree.

>> > ... (And what exactly is a problem
>> > with supporting images, given that Emacs is already capable of
>> > displaying them?)
>> 
>> Some text flowing around the images
>>  ...
>> Or text and image displayed on top of each other.
>
> We aren't afraid of that in EWW and shr.el, are we?  We could use the
> same technique here.

You mean slicing? This may work for flowing text around, but it will not
work for overlaying images and text.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
> Date: Sun, 18 Aug 2024 14:35:15 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Or text and image displayed on top of each other.
> >
> > We aren't afraid of that in EWW and shr.el, are we?  We could use the
> > same technique here.
> 
> You mean slicing? This may work for flowing text around, but it will not
> work for overlaying images and text.

Then overlaying will not be supported.  It is still a valuable
feature, IMO.

Re: RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[Jim Porter]

On 8/18/2024 7:35 AM, Ihor Radchenko wrote:
>>> Some text flowing around the images
>>>   ...
>>> Or text and image displayed on top of each other.
>>
>> We aren't afraid of that in EWW and shr.el, are we?  We could use the
>> same technique here.
> 
> You mean slicing? This may work for flowing text around, but it will not
> work for overlaying images and text.

EWW/shr.el don't actually use slicing for flowing text, as far as I 
know. I suppose that could work, but I'd be worried about 
miscalculations causing the slices to be misaligned (for example if we 
tried to support the CSS 'float: right' property).

In short, EWW/shr.el's strategy for flowing text around images is to 
simply ignore it (unless I'm misunderstanding part of that code).

For RTF support, I don't know if Emacs needs to support all (or even 
most) features of RTF to still be useful. If Emacs showed images on 
their own line no matter what the RTF document requests, that's still a 
big improvement over not being able to view RTF documents at all.

Re: RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[Eli Zaretskii]

> Date: Sun, 18 Aug 2024 10:37:51 -0700
> Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 8/18/2024 7:35 AM, Ihor Radchenko wrote:
> >>> Some text flowing around the images
> >>>   ...
> >>> Or text and image displayed on top of each other.
> >>
> >> We aren't afraid of that in EWW and shr.el, are we?  We could use the
> >> same technique here.
> > 
> > You mean slicing? This may work for flowing text around, but it will not
> > work for overlaying images and text.
> 
> EWW/shr.el don't actually use slicing for flowing text, as far as I 
> know. I suppose that could work, but I'd be worried about 
> miscalculations causing the slices to be misaligned (for example if we 
> tried to support the CSS 'float: right' property).

Using :align-to should allow us to align the slices horizontally (if
that is what you had in mind).

> In short, EWW/shr.el's strategy for flowing text around images is to 
> simply ignore it (unless I'm misunderstanding part of that code).

Right, and the display of RTF could do the same.

> For RTF support, I don't know if Emacs needs to support all (or even 
> most) features of RTF to still be useful. If Emacs showed images on 
> their own line no matter what the RTF document requests, that's still a 
> big improvement over not being able to view RTF documents at all.

I say let's start from the text parts: the fonts, the faces, the
indentation, the numbered and unnumbered lists, etc.  If we can pull
that out, we will already have a terrifically useful feature.

Rome wasn't built in a day.

Re: RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[Jim Porter]

On 8/18/2024 11:16 AM, Eli Zaretskii wrote:
>> Date: Sun, 18 Aug 2024 10:37:51 -0700
>> Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>> EWW/shr.el don't actually use slicing for flowing text, as far as I
>> know. I suppose that could work, but I'd be worried about
>> miscalculations causing the slices to be misaligned (for example if we
>> tried to support the CSS 'float: right' property).
> 
> Using :align-to should allow us to align the slices horizontally (if
> that is what you had in mind).

My worry was that if you had this,

   This is some text   [image slice]
   that goes on        [image slice]
   multiple lines.     [image slice]

we'd have to be very careful. Text-scaling is probably the biggest risk. 
If you enlarge the text, the line-height changes, which would probably 
break things (though I guess we could scale the image too).

In any case, we can cross this bridge when we get to it.

> I say let's start from the text parts: the fonts, the faces, the
> indentation, the numbered and unnumbered lists, etc.  If we can pull
> that out, we will already have a terrifically useful feature.

I agree. SHR has already implemented these[1], so it would probably be a 
good source of ideas for how to render these parts. Maybe we could even 
pull some of the code out into a common file.

[1] There's no CSS support though, so in practice, most web pages these 
days end up using the default font with SHR.

Re: RTF import/export emacs (was: New Emacs features via Google Summer of Code (or other similar stipend schemes))

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Sun, Aug 18, 2024 at 11:38:49AM -0700, Jim Porter wrote:
> On 8/18/2024 11:16 AM, Eli Zaretskii wrote:
> > > Date: Sun, 18 Aug 2024 10:37:51 -0700
> > > Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
> > > From: Jim Porter <jporterbugs@gmail.com>
> > > 
> > > EWW/shr.el don't actually use slicing for flowing text, as far as I
> > > know. I suppose that could work, but I'd be worried about
> > > miscalculations causing the slices to be misaligned (for example if we
> > > tried to support the CSS 'float: right' property).
> > 
> > Using :align-to should allow us to align the slices horizontally (if
> > that is what you had in mind).
> 
> My worry was that if you had this,
> 
>   This is some text   [image slice]
>   that goes on        [image slice]
>   multiple lines.     [image slice]
> 
> we'd have to be very careful. Text-scaling is probably the biggest risk. If
> you enlarge the text, the line-height changes, which would probably break
> things (though I guess we could scale the image too).

Let alone when you have lines with differing heights. Sounds like quite a bit
of fun :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-devel@gnu.org, Stefan Kangas <stefankangas@gmail.com>, Andrea
>  Corallo <acorallo@gnu.org>
> Date: Mon, 12 Aug 2024 19:17:05 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Eli, have you considered using GSC to get volunteers for implementing
> >> some moderately difficult Emacs features? Since GSC provides financial
> >> incentive, it may be possible to get student volunteers.
> >> 
> >> Of course, someone still needs to mentor the students, but that's less
> >> effort compared to actually writing all the code.
> 
> > I can only say that it would be harder for a casual contributor to do
> > a GSoC-style job for Emacs than for other projects, because Emacs has
> > a lot of specialized needs and requirements that take time to learn.
> > But maybe this is not an obstacle.
> 
> May you elaborate?

Sorry, I don't know what else to say.  I think the above is clear
enough.  Granted, it's my opinion, and others could disagree, but I
didn't write that by accident, I wrote that with full intent.

> The interested students will likely also be at least casual Emacs users.
> So, some degree of familiarity is expected.

User-level familiarity doesn't help in these matters, IME.

> Other than that, how is Emacs dramatically different from working with
> any other large codebase?

In a nutshell, Emacs is much larger than most other projects, and its
features are much less localized than those of other large projects.

> So, what I am talking about is not a theoretical idea. It can be done.

I didn't say it couldn't be done.

> What is needed is a formulation of projects/features that are desired.
> Mentors do not have to be maintainers. Experienced Emacs contributors
> can be the mentors (also, mentoring a student can be a good addition to
> some types of CVs).

We have etc/TODO which could be used as a source of ideas.

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> The interested students will likely also be at least casual Emacs users.
>> So, some degree of familiarity is expected.
>
> User-level familiarity doesn't help in these matters, IME.

>> Other than that, how is Emacs dramatically different from working with
>> any other large codebase?
>
> In a nutshell, Emacs is much larger than most other projects, and its
> features are much less localized than those of other large projects.

But not every feature, right? Some parts are easier to hack than others.
I imagine that many Elisp parts are somewhat easier compared to C code.

>> What is needed is a formulation of projects/features that are desired.
>> Mentors do not have to be maintainers. Experienced Emacs contributors
>> can be the mentors (also, mentoring a student can be a good addition to
>> some types of CVs).
>
> We have etc/TODO which could be used as a source of ideas.

Are there any specific todo items there that you view as more suitable
for people with limited experience in Emacs codebase?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, acorallo@gnu.org
> Date: Sun, 18 Aug 2024 11:09:54 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The interested students will likely also be at least casual Emacs users.
> >> So, some degree of familiarity is expected.
> >
> > User-level familiarity doesn't help in these matters, IME.
> 
> >> Other than that, how is Emacs dramatically different from working with
> >> any other large codebase?
> >
> > In a nutshell, Emacs is much larger than most other projects, and its
> > features are much less localized than those of other large projects.
> 
> But not every feature, right? Some parts are easier to hack than others.
> I imagine that many Elisp parts are somewhat easier compared to C code.

Only if you are lucky, and only if you are familiar with the code in
question.

> >> What is needed is a formulation of projects/features that are desired.
> >> Mentors do not have to be maintainers. Experienced Emacs contributors
> >> can be the mentors (also, mentoring a student can be a good addition to
> >> some types of CVs).
> >
> > We have etc/TODO which could be used as a source of ideas.
> 
> Are there any specific todo items there that you view as more suitable
> for people with limited experience in Emacs codebase?

Possibly, but someone needs to look at them with this in mind.

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Stefan Kangas]

Ihor Radchenko <yantar92@posteo.net> writes:

>> We have etc/TODO which could be used as a source of ideas.
>
> Are there any specific todo items there that you view as more suitable
> for people with limited experience in Emacs codebase?

I agree with many of the reservations Eli has, but on the other hand
this depends highly on what the projects will be.  Perhaps this could be
a good way to attract new contributors, some of which will be found in
the already existing Emacs community (parts of which do not interact
much with emacs-devel).

So I'm basically all in favor of GSoC, but someone needs to do the work
to get the ball rolling, for example with regards to suitable proposals.
If someone were to propose a list of projects, then it would be easier
for others to comment on it.  This could potentially also be used to
expand the text that is currently in etc/TODO, to improve that file.
If that's possible, the effort will never be wasted.

Another thing that would be useful in this regard is if people could
indicate their interest in mentoring students, even tentatively.
As for me, I _might_ have the time to act as mentor, but that is highly
tentative as I didn't consider or think about that very closely.  It
would also depend on the project idea, of course.

Re: New Emacs features via Google Summer of Code (or other similar stipend schemes) (was: as for Calc and the math library)

[Ihor Radchenko]

Stefan Kangas <stefankangas@gmail.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>>> We have etc/TODO which could be used as a source of ideas.
>>
>> Are there any specific todo items there that you view as more suitable
>> for people with limited experience in Emacs codebase?
>
> I agree with many of the reservations Eli has, but on the other hand
> this depends highly on what the projects will be.  Perhaps this could be
> a good way to attract new contributors, some of which will be found in
> the already existing Emacs community (parts of which do not interact
> much with emacs-devel).

Yup. I want to have some kind of shortlist of tasks that the
maintainers familiar with the code can suggest as student projects.

Then, we can eventually go out to reddit/mastodon/reach Sacha
Chua/Emacsconf to ask the community.

> So I'm basically all in favor of GSoC, but someone needs to do the work
> to get the ball rolling, for example with regards to suitable proposals.
> If someone were to propose a list of projects, then it would be easier
> for others to comment on it.  This could potentially also be used to
> expand the text that is currently in etc/TODO, to improve that file.
> If that's possible, the effort will never be wasted.

+1

> Another thing that would be useful in this regard is if people could
> indicate their interest in mentoring students, even tentatively.
> As for me, I _might_ have the time to act as mentor, but that is highly
> tentative as I didn't consider or think about that very closely.  It
> would also depend on the project idea, of course.

I am also considering mentoring, but that will be for Org mode.

I think that it is a good idea to shortlist things from TODO file before
asking potential mentors. Simply to prioritize projects that are deemed
important by the maintainers.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: incal@dataswamp.org, emacs-devel@gnu.org
> Date: Sun, 11 Aug 2024 18:27:16 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 1. Documenting some Calc data structures
> >> 2. Possibly refactoring some Calc functions to use simpler API.
> >> 
> >> It would be a much easier task and can improve the existing
> >> functionality.
> >
> > I don't think I understand well enough what will this entail in
> > practice.  Can you show an example of doing this for a couple of
> > functions?
> 
> For (1), I was referring to ";;;; Arithmetic routines." in
> calc.el.

(1) is documentation of Calc data structures.  If you mean the large
commentary that describes the various form of objects that Calc can
handle, then what is left to document?

> Now, people must simply know the internal format of special
> number representations to work with Calc from Elisp.
> It might be worth (a) putting them into a proper manual (some kind of
> Calc Lisp API description); (b) maybe creating constructor functions to
> abstract the types away.

Doesn't (a) already exist in the Calc manual chapter "Data Types"?
And if not, then you are talking about enhancing the documentation of
Calc, which is always welcome, but I fail to see how it is a step
towards a separate library.

> For (2), for starters, Calc functions often do not even have
> docstrings. One simply has to guess(?) or read the code to understand
> what kinds of values can be passed.

And how is this relevant to (2), which is about refactoring some of
Calc code into hopefully easier-to-use functions?

> For example, take `math-add' - no
> docstring, and go try adding invalid arguments:
> 
> M-: (math-add "foo" '(frac 1 2))

It's a small wonder that you cannot math-add a string, especially
since none of the objects described in the commentary are any kind of
string.  More generally, AFAIU these don't have doc strings because
they are internal functions.

But still, I don't understand the relevance.

> but somehow not
> 
> M-: (math-add 0.1 '(frac 1 10))
> 
> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p 2.0)
>   (math-gcd 2.0 10)
>   (math-make-frac 2.0 10)
>   (calc-add-fractions 0.1 (frac 1 10))
>   (math-add 0.1 (frac 1 10))

You again play against the rules: 0.1 is not a valid object for these
functions.  Try

  M-: (math-add '(float 1 -1) '(frac 1 10))

Re: as for Calc and the math library

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> For (1), I was referring to ";;;; Arithmetic routines." in
>> calc.el.
>
> (1) is documentation of Calc data structures.  If you mean the large
> commentary that describes the various form of objects that Calc can
> handle, then what is left to document?

Put this commentary, and other relevant APIs into .texi, explained and
organized aiming for Elisp API users.

>> Now, people must simply know the internal format of special
>> number representations to work with Calc from Elisp.
>> It might be worth (a) putting them into a proper manual (some kind of
>> Calc Lisp API description); (b) maybe creating constructor functions to
>> abstract the types away.
>
> Doesn't (a) already exist in the Calc manual chapter "Data Types"?

Hmm. Yes. Last time, I failed to see them.

> And if not, then you are talking about enhancing the documentation of
> Calc, which is always welcome, but I fail to see how it is a step
> towards a separate library.

The idea is to have a description and overview of what the library
does. It will make the design easier later.

>> For (2), for starters, Calc functions often do not even have
>> docstrings. One simply has to guess(?) or read the code to understand
>> what kinds of values can be passed.
>
> And how is this relevant to (2), which is about refactoring some of
> Calc code into hopefully easier-to-use functions?

If these functions are going to be used from Elisp, they must have
docstrings.

>> For example, take `math-add' - no
>> docstring, and go try adding invalid arguments:
>> 
>> M-: (math-add "foo" '(frac 1 2))
>
> It's a small wonder that you cannot math-add a string, especially
> since none of the objects described in the commentary are any kind of
> string.  More generally, AFAIU these don't have doc strings because
> they are internal functions.
>
> But still, I don't understand the relevance.

I meant this function as a candidate for math library we are
discussing.

>> but somehow not
>> 
>> M-: (math-add 0.1 '(frac 1 10))
>> 
>> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p 2.0)
>>   (math-gcd 2.0 10)
>>   (math-make-frac 2.0 10)
>>   (calc-add-fractions 0.1 (frac 1 10))
>>   (math-add 0.1 (frac 1 10))
>
> You again play against the rules: 0.1 is not a valid object for these
> functions.  Try
>
>   M-: (math-add '(float 1 -1) '(frac 1 10))

My point is that the error message could be nicer.
Something like (wrong-type-argument calc-value-p 2.0)
"integer-or-marker-p" creates an impression that you can only pass
integers there.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: incal@dataswamp.org, emacs-devel@gnu.org
> Date: Sun, 11 Aug 2024 19:13:16 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And if not, then you are talking about enhancing the documentation of
> > Calc, which is always welcome, but I fail to see how it is a step
> > towards a separate library.
> 
> The idea is to have a description and overview of what the library
> does. It will make the design easier later.

I think if someone will step forward to do this kind of job, it will
be up to them what steps should lead to the goal.

> >> M-: (math-add 0.1 '(frac 1 10))
> >> 
> >> Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p 2.0)
> >>   (math-gcd 2.0 10)
> >>   (math-make-frac 2.0 10)
> >>   (calc-add-fractions 0.1 (frac 1 10))
> >>   (math-add 0.1 (frac 1 10))
> >
> > You again play against the rules: 0.1 is not a valid object for these
> > functions.  Try
> >
> >   M-: (math-add '(float 1 -1) '(frac 1 10))
> 
> My point is that the error message could be nicer.

For internal functions that don't expect to see objects other than
what they were designed to handle?  Nice error messages are for the
application level, not for this level, IMO.

as for Calc and the math library

[Christopher Dimech]

> Sent: Monday, August 12, 2024 at 6:52 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Ihor Radchenko" <yantar92@posteo.net>
> Cc: incal@dataswamp.org, emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> > From: Ihor Radchenko <yantar92@posteo.net>
> > Cc: incal@dataswamp.org, emacs-devel@gnu.org
> > Date: Sun, 11 Aug 2024 18:27:16 +0000
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> 1. Documenting some Calc data structures
> > >> 2. Possibly refactoring some Calc functions to use simpler API.
> > >>
> > >> It would be a much easier task and can improve the existing
> > >> functionality.
> > >
> > > I don't think I understand well enough what will this entail in
> > > practice.  Can you show an example of doing this for a couple of
> > > functions?
> >
> > For (1), I was referring to ";;;; Arithmetic routines." in
> > calc.el.
>
> (1) is documentation of Calc data structures.  If you mean the large
> commentary that describes the various form of objects that Calc can
> handle, then what is left to document?
>
> > Now, people must simply know the internal format of special
> > number representations to work with Calc from Elisp.
> > It might be worth (a) putting them into a proper manual (some kind of
> > Calc Lisp API description); (b) maybe creating constructor functions to
> > abstract the types away.
>
> Doesn't (a) already exist in the Calc manual chapter "Data Types"?
> And if not, then you are talking about enhancing the documentation of
> Calc, which is always welcome, but I fail to see how it is a step
> towards a separate library.
>
> > For (2), for starters, Calc functions often do not even have
> > docstrings. One simply has to guess(?) or read the code to understand
> > what kinds of values can be passed.
>
> And how is this relevant to (2), which is about refactoring some of
> Calc code into hopefully easier-to-use functions?

Well, if the task is focused on refactoring, then we should not change
any implementations if we are to test the results before and after, just
to be sure things are as we think should be.

> > For example, take `math-add' - no
> > docstring, and go try adding invalid arguments:
> >
> > M-: (math-add "foo" '(frac 1 2))
>
> It's a small wonder that you cannot math-add a string, especially
> since none of the objects described in the commentary are any kind of
> string.  More generally, AFAIU these don't have doc strings because
> they are internal functions.
>
> But still, I don't understand the relevance.
>
> > but somehow not
> >
> > M-: (math-add 0.1 '(frac 1 10))
> >
> > Debugger entered--Lisp error: (wrong-type-argument integer-or-marker-p 2.0)
> >   (math-gcd 2.0 10)
> >   (math-make-frac 2.0 10)
> >   (calc-add-fractions 0.1 (frac 1 10))
> >   (math-add 0.1 (frac 1 10))
>
> You again play against the rules: 0.1 is not a valid object for these
> functions.  Try
>
>   M-: (math-add '(float 1 -1) '(frac 1 10))
>
>

Re: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

> > If Emacs is to have a math library, the library must use high-quality
> > mathematical and numerical algorithms that are well-known and
> > described in many textbooks on this subject matter...
>
> I agree with this point, but I suspect that writing such a library from
> scratch might be a bit difficult.
>
> May I suggest an alternative: abstract out GNU Calc math routines to be
> available from Elisp without having to read Calc sources.
> Such a task would require:
> 1. Documenting some Calc data structures
> 2. Possibly refactoring some Calc functions to use simpler API.
>
> It would be a much easier task and can improve the existing
> functionality.

Even better, given people proper FFI so they can import and use any of the tens
or hundreds of quality math libraries available.

That would also help to keep C core smaller, and relieve the dependency on core
devs to add bindings to future libraries when users want or need them.

A third of Emacs C core could have easily been implemented by users if they had
proper FFI exposed to Lisp instead of C modules which very few people use.

[-- Attachment #2: Type: text/html, Size: 3943 bytes --]

Re: as for Calc and the math library

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> Date: Mon, 12 Aug 2024 05:30:08 +0000
> 
> Even better, given people proper FFI so they can import and use any of the tens
> or hundreds of quality math libraries available.

Not going to happen, and you know it.

Re: as for Calc and the math library

[Nicolas Martyanoff]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: arthur miller <arthur.miller@live.com>
>> Date: Mon, 12 Aug 2024 05:30:08 +0000
>> 
>> Even better, given people proper FFI so they can import and use any of the tens
>> or hundreds of quality math libraries available.
>
> Not going to happen, and you know it.

Naïve question, why? I had this problem not so long ago because I wanted
to bind libpq, and I had to abandon the whole idea because dealing with
dynamic modules was way too inconvenient.

Having something similar to Common Lisp FFIs would make it trivial.

Best,

-- 
Nicolas Martyanoff
https://n16f.net
nicolas@n16f.net

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: arthur miller <arthur.miller@live.com>,  emacs-devel@gnu.org
> Date: Mon, 12 Aug 2024 13:23:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: arthur miller <arthur.miller@live.com>
> >> Date: Mon, 12 Aug 2024 05:30:08 +0000
> >> 
> >> Even better, given people proper FFI so they can import and use any of the tens
> >> or hundreds of quality math libraries available.
> >
> > Not going to happen, and you know it.
> 
> Naïve question, why?

Because providing FFI would allow using non-free libraries in Emacs.

We made the effort to allow loading dynamic modules precisely for this
reason: to allow free libraries to be used, but not non-free ones.

Re: as for Calc and the math library

[Nicolas Martyanoff]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Martyanoff <nicolas@n16f.net>
>> Cc: arthur miller <arthur.miller@live.com>,  emacs-devel@gnu.org
>> Date: Mon, 12 Aug 2024 13:23:27 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: arthur miller <arthur.miller@live.com>
>> >> Date: Mon, 12 Aug 2024 05:30:08 +0000
>> >> 
>> >> Even better, given people proper FFI so they can import and use any of the tens
>> >> or hundreds of quality math libraries available.
>> >
>> > Not going to happen, and you know it.
>> 
>> Naïve question, why?
>
> Because providing FFI would allow using non-free libraries in Emacs.
>
> We made the effort to allow loading dynamic modules precisely for this
> reason: to allow free libraries to be used, but not non-free ones.

You absolutely can use non-free dynamic modules: enforcing the existence
of a symbol saying "I promise I'm free" does not change anything. One
could also easily add a free dynamic module that calls non-free
libraries.

It is sad to see Emacs being hamstrung and users being limited because
someone could do something that would have no impact whatsoever with the
project or any other user.

But your software your rules.

-- 
Nicolas Martyanoff
https://n16f.net
nicolas@n16f.net

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: Nicolas Martyanoff <nicolas@n16f.net>,  arthur.miller@live.com,
>   emacs-devel@gnu.org
> Date: Mon, 12 Aug 2024 14:11:07 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > We made the effort to allow loading dynamic modules precisely for this
> > reason: to allow free libraries to be used, but not non-free ones.
> 
> You absolutely can use non-free dynamic modules: enforcing the existence
> of a symbol saying "I promise I'm free" does not change anything. One
> could also easily add a free dynamic module that calls non-free
> libraries.

The need to declare that a library is free and have its sources freely
available does serve as an obstacle for non-free software.  And using
non-free library with a free module is against the GPL, so it is
illegal.  We cannot prevent people from lying and doing illegal
things, we can only make it harder.

> It is sad to see Emacs being hamstrung and users being limited because
> someone could do something that would have no impact whatsoever with the
> project or any other user.

This is a sad world for more reasons than one, but discussing that is
off-topic here.

as for Calc and the math library

[Christopher Dimech]

----- Kristof Đymek
Administrator General - Chilkat Design Build - Naiad Informatics - Gnu Project

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://www.gnu.org     https://www.fsf.org/


> Sent: Tuesday, August 13, 2024 at 1:22 AM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Nicolas Martyanoff" <nicolas@n16f.net>
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> > From: Nicolas Martyanoff <nicolas@n16f.net>
> > Cc: Nicolas Martyanoff <nicolas@n16f.net>,  arthur.miller@live.com,
> >   emacs-devel@gnu.org
> > Date: Mon, 12 Aug 2024 14:11:07 +0200
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > We made the effort to allow loading dynamic modules precisely for this
> > > reason: to allow free libraries to be used, but not non-free ones.
> > 
> > You absolutely can use non-free dynamic modules: enforcing the existence
> > of a symbol saying "I promise I'm free" does not change anything. One
> > could also easily add a free dynamic module that calls non-free
> > libraries.
> 
> The need to declare that a library is free and have its sources freely
> available does serve as an obstacle for non-free software.  And using
> non-free library with a free module is against the GPL, so it is
> illegal.  We cannot prevent people from lying and doing illegal
> things, we can only make it harder.

License terms do not prohibit the software's use, such a restriction would 
not be enforceable. 
 
> > It is sad to see Emacs being hamstrung and users being limited because
> > someone could do something that would have no impact whatsoever with the
> > project or any other user.
> 
> This is a sad world for more reasons than one, but discussing that is
> off-topic here.
 
What you can do is remove non-free software from free-software tools.
You are wasting time for no real returns.

Re: as for Calc and the math library

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

GPL3 explicitly does not place rules on what changes you can make
in a covered progra _for your private use_.

A user can lawfully write a nonfree program for private use that
dynamically links in a GPL3-covered module, just as a user can
lawfully copy GPL3-covered code plus nonfree code into a program for
private use.

However, _distribution_ of such a nonfree combination would violate
GPLv3.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

as for Calc and the math library

[Christopher Dimech]

> Sent: Thursday, August 15, 2024 at 1:59 PM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> GPL3 explicitly does not place rules on what changes you can make
> in a covered progra _for your private use_.
> 
> A user can lawfully write a nonfree program for private use that
> dynamically links in a GPL3-covered module, just as a user can
> lawfully copy GPL3-covered code plus nonfree code into a program for
> private use.
> 
> However, _distribution_ of such a nonfree combination would violate
> GPLv3.
> 
> -- 
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

Despite this clarity, there's a recurring problem with the community:
some maintainers go beyond the requirements of the GPL3 by creating
additional barriers within the source code to prevent what they perceive
as undesirable use cases.

This could involve adding checks to verify that only certain libraries
are used or implementing "allowed-lists" to restrict what modifications
can be made or with what the software can interact.

It's quite right to argue that these additional obstacles are
unnecessary and, in some cases, counterproductive. The GPL3 already sets
clear boundaries — if a nonfree module or library is being used in a way
that is kept private and not distributed, it is perfectly legal under
the license. The problem arises when maintainers attempt to enforce
additional restrictions that go beyond the license’s requirements,
sometimes under the misconception that doing so aligns with the GPL's
spirit.

For instance, claims that using a nonfree library with a GPL3-covered
module is inherently illegal reflect a misunderstanding of the
license.  As clarified, such usage is only problematic if the
software is distributed. Unfortunately, these misunderstandings can lead
to a unpleasant environment where maintainers unnecessarily police the
actions of users or other developers, potentially stifling innovation
and cooperation.

Moreover, some maintainers might believe they are in a better position
to judge what is or isn't permissible under the GPL3. While it’s true
that interpreting the nuances of free-licenses requires a good
understanding, dismissing the judgments of others, such as those with
significant experience or legal knowledge, is unproductive. The GPL3 was
crafted to empower users, not to restrict them unnecessarily, and the
community should focus on upholding that ethos rather than imposing
additional, unwarranted barriers.

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 15 Aug 2024 05:06:47 +0200
> 
> > However, _distribution_ of such a nonfree combination would violate
> > GPLv3.
> 
> Despite this clarity, there's a recurring problem with the community:
> some maintainers go beyond the requirements of the GPL3 by creating
> additional barriers within the source code to prevent what they perceive
> as undesirable use cases.
> 
> This could involve adding checks to verify that only certain libraries
> are used or implementing "allowed-lists" to restrict what modifications
> can be made or with what the software can interact.
> 
> It's quite right to argue that these additional obstacles are
> unnecessary and, in some cases, counterproductive. The GPL3 already sets
> clear boundaries — if a nonfree module or library is being used in a way
> that is kept private and not distributed, it is perfectly legal under
> the license. The problem arises when maintainers attempt to enforce
> additional restrictions that go beyond the license’s requirements,
> sometimes under the misconception that doing so aligns with the GPL's
> spirit.

The maintainers only add these obstacles when there's a request for
Emacs as a project to distribute code which would allow making Emacs a
front-end for non-free software.  As long as such code is used
privately by someone, or even left on some repository outside of
Emacs, it is not our business (although distributing non-compliant
software which claims to be compliant is against the law).  But please
understand that you cannot request _us_ to include such code in Emacs,
because then _we_ will be either violating the GPL or encouraging use
of non-free software.

And please don't forget or ignore that in addition to GPL violations,
there's one more aspect involved here, and that is not to encourage
use of non-free software.  For the same reason we don't mention
non-free programs or libraries or fonts in our sources and
documentation, we do not intend to make it easy for people to use
non-free shared libraries by providing _our_ code that caters to such
use cases.  Emacs is Free Software, so anyone can take its sources and
modify them to do whatever they want, but don't expect _us_ to do that
as part of the official Emacs sources.  This is not new, although some
people tend to raise the same issues here time and again for some
reason.

> For instance, claims that using a nonfree library with a GPL3-covered
> module is inherently illegal reflect a misunderstanding of the
> license.

It would be illegal for a library to claim GPL compliance when in fact
there's no compliance, yes.  Other than that, no one said anything
about the legal aspects; the issues discussed in this thread are our
usual ethics that precludes us from encouraging use of non-free
software in conjunction with Emacs.

> As clarified, such usage is only problematic if the
> software is distributed. Unfortunately, these misunderstandings can lead
> to a unpleasant environment where maintainers unnecessarily police the
> actions of users or other developers, potentially stifling innovation
> and cooperation.

It could, but it doesn't, not in this case.

> Moreover, some maintainers might believe they are in a better position
> to judge what is or isn't permissible under the GPL3.

This is a strawman: no one said anything about GPL; the fact that the
symbol required by loading dynamic modules has "GPL" in its name does
not contradict this, because the requirement is to be GPL-compatible,
not GPLv3.

as for Calc and the math library

[Christopher Dimech]

> Sent: Thursday, August 15, 2024 at 6:43 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: emacs-devel@gnu.org
> > Date: Thu, 15 Aug 2024 05:06:47 +0200
> > 
> > > However, _distribution_ of such a nonfree combination would violate
> > > GPLv3.
> > 
> > Despite this clarity, there's a recurring problem with the community:
> > some maintainers go beyond the requirements of the GPL3 by creating
> > additional barriers within the source code to prevent what they perceive
> > as undesirable use cases.
> > 
> > This could involve adding checks to verify that only certain libraries
> > are used or implementing "allowed-lists" to restrict what modifications
> > can be made or with what the software can interact.
> > 
> > It's quite right to argue that these additional obstacles are
> > unnecessary and, in some cases, counterproductive. The GPL3 already sets
> > clear boundaries — if a nonfree module or library is being used in a way
> > that is kept private and not distributed, it is perfectly legal under
> > the license. The problem arises when maintainers attempt to enforce
> > additional restrictions that go beyond the license’s requirements,
> > sometimes under the misconception that doing so aligns with the GPL's
> > spirit.
> 
> The maintainers only add these obstacles when there's a request for
> Emacs as a project to distribute code which would allow making Emacs a
> front-end for non-free software.  As long as such code is used
> privately by someone, or even left on some repository outside of
> Emacs, it is not our business (although distributing non-compliant
> software which claims to be compliant is against the law).  But please
> understand that you cannot request _us_ to include such code in Emacs,
> because then _we_ will be either violating the GPL or encouraging use
> of non-free software.

> And please don't forget or ignore that in addition to GPL violations,
> there's one more aspect involved here, and that is not to encourage
> use of non-free software.  For the same reason we don't mention
> non-free programs or libraries or fonts in our sources and
> documentation, we do not intend to make it easy for people to use
> non-free shared libraries by providing _our_ code that caters to such
> use cases.  

The focus in free software is on creating clear, understandable, and
accessible code. The core principle of free software is that users have
the freedom to study, modify, and distribute the software as they see
fit. This freedom is best supported by writing clear and well-documented
code that users can easily understand and adapt to their needs.

Encouraging free software adoption through software design or structural
means — such as intentionally complicating the code to guide or limit how
users interact with it — is problematic. This approach runs counter to
the spirit of free software because it resembles the kind of code
obfuscation often seen in proprietary software, where the intent is to
prevent users from understanding or modifying the code.

In free software, the goal should be to empower users, not restrict
them. Any attempt to influence how users engage with the software
through code structure, rather than through education or advocacy,
undermines the principles of transparency and user freedom that are
central to the free software movement. The power of free software lies
in its openness, and that openness should be reflected in the clarity
and accessibility of the code itself.


> Emacs is Free Software, so anyone can take its sources and
> modify them to do whatever they want, but don't expect _us_ to do that
> as part of the official Emacs sources.  This is not new, although some
> people tend to raise the same issues here time and again for some
> reason.
> 
> > For instance, claims that using a nonfree library with a GPL3-covered
> > module is inherently illegal reflect a misunderstanding of the
> > license.
> 
> It would be illegal for a library to claim GPL compliance when in fact
> there's no compliance, yes.  Other than that, no one said anything
> about the legal aspects; the issues discussed in this thread are our
> usual ethics that precludes us from encouraging use of non-free
> software in conjunction with Emacs.

Emacs, as a project, must always ensure that its releases are fully 
compliant with the GPL, which governs its distribution and use.  

There is ambiguity in determining software freedom.  One cannot always
determine a priori whether external software is free or non-free without
examining its license. Imposing restrictions or enforcing certain ways
of doing things to ensure compliance with the free software ethos is an
overreaching approach. Forcing a particular method of interaction and
then claiming that this makes the software free misses the point that
freedom is inherent in the license itself, not in the prescribed usage.
 
> > As clarified, such usage is only problematic if the
> > software is distributed. Unfortunately, these misunderstandings can lead
> > to a unpleasant environment where maintainers unnecessarily police the
> > actions of users or other developers, potentially stifling innovation
> > and cooperation.
> 
> It could, but it doesn't, not in this case.
> 
> > Moreover, some maintainers might believe they are in a better position
> > to judge what is or isn't permissible under the GPL3.
> 
> This is a strawman: no one said anything about GPL; the fact that the
> symbol required by loading dynamic modules has "GPL" in its name does
> not contradict this, because the requirement is to be GPL-compatible,
> not GPLv3.

The statement you’re referring to touches on an important aspect of the
free software ecosystem - namely, that the GPL (GNU General Public
License) is just one of many licenses under which free software can be
distributed. The idea that software needs to be GPL-compliant is indeed
a common misconception, but it's more accurate to say that it needs to
be compatible with the GPL, especially when interacting with GPL-licensed 
code.  

But only when distributed.  For software that is not distributed (e.g.,
used privately or within an organization), these requirements do not
apply.  Suggesting or enforcing limitations on what users can code, even
in private use is where the controversy lies.  The GPL, as stated, does
not place restrictions on private modifications or use. Users are free
to experiment, modify, and even create non-free software for their
private use, without any obligation to comply with the GPL’s
distribution requirements.  But you decided to hinder that possibility.
An additional item to the list of bad ideas.

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: rms@gnu.org, emacs-devel@gnu.org
> Date: Thu, 15 Aug 2024 15:28:24 +0200
> 
> The focus in free software is on creating clear, understandable, and
> accessible code.

That's _part_ of our focus here.  Another part, and definitely no less
important, is to make sure the software is free.

> The core principle of free software

Just one of the core principles, not the only one.

> is that users have the freedom to study, modify, and distribute the
> software as they see fit.

Not "as they see fit": there are some restrictions on what they can
do.  For example, they cannot distribute the modified software without
its complete source code, including the modifications and additions.

> This freedom is best supported by writing clear and well-documented
> code that users can easily understand and adapt to their needs.

And by other measures, some of which are no less important.

> Encouraging free software adoption through software design or structural
> means — such as intentionally complicating the code to guide or limit how
> users interact with it — is problematic.

It's a judgment call, yes.  There's a trade-off to be considered.

> This approach runs counter to
> the spirit of free software because it resembles the kind of code
> obfuscation often seen in proprietary software, where the intent is to
> prevent users from understanding or modifying the code.

No, nothing in the specific issue at hand causes any kind of
obfuscation.

> In free software, the goal should be to empower users, not restrict
> them.

To empower users to be able to use, modify, and redistribute the
software they receive.  Not to empower them to do everything
imaginable.

> Any attempt to influence how users engage with the software
> through code structure, rather than through education or advocacy,
> undermines the principles of transparency and user freedom that are
> central to the free software movement.

No, nothing in our practice undermines any transparency nor any user
freedom to use, study, and modify the software.

> The power of free software lies in its openness, and that openness
> should be reflected in the clarity and accessibility of the code
> itself.

Nothing in our practice makes the Emacs code less open and clear.

> There is ambiguity in determining software freedom.  One cannot always
> determine a priori whether external software is free or non-free without
> examining its license. Imposing restrictions or enforcing certain ways
> of doing things to ensure compliance with the free software ethos is an
> overreaching approach.

Once again, this is the approach taken by the GNU Project, and if you
want to argue against it, you are in the wrong place.  Kindly take
this dispute elsewhere.

> The statement you’re referring to touches on an important aspect of the
> free software ecosystem - namely, that the GPL (GNU General Public
> License) is just one of many licenses under which free software can be
> distributed. The idea that software needs to be GPL-compliant is indeed
> a common misconception, but it's more accurate to say that it needs to
> be compatible with the GPL, especially when interacting with GPL-licensed 
> code.  
> 
> But only when distributed.  For software that is not distributed (e.g.,
> used privately or within an organization), these requirements do not
> apply.

Nothing in what we do prevents users from doing whatever they like
with Emacs as long as they do it for their private use.

> Suggesting or enforcing limitations on what users can code, even
> in private use is where the controversy lies.

No one enforces users to do anything nor prevents them from doing
anything they like.  The request was to force the Emacs project to
actively help people do something that we do not want to endorse. Such
kind of request is ridiculous: a software project is not obliged to do
everything its users request, only those parts with which it (the
project) agrees.

> The GPL, as stated, does not place restrictions on private
> modifications or use.

Yes.

> Users are free to experiment, modify, and even create non-free
> software for their private use, without any obligation to comply
> with the GPL’s distribution requirements.

Yes.

> But you decided to hinder that possibility.

No.

Please stop accusing the project with these false accusations.

Sv: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 4754 bytes --]

> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > We made the effort to allow loading dynamic modules precisely for this
> > > reason: to allow free libraries to be used, but not non-free ones.

Emacs users are "linking" Emacs to all kind of proprietary, non-free services
these days. You are reading /r/Emacs yourself and seen packages popping up
targeting this or that proprietary service almost every day. Shared libraries
are no longer the staple of distributing closed source. The computing landscape
has change a lot since 1980s/1990s.

> > You absolutely can use non-free dynamic modules: enforcing the existence
> > of a symbol saying "I promise I'm free" does not change anything. One
> > could also easily add a free dynamic module that calls non-free
> > libraries.
>
> The need to declare that a library is free and have its sources freely
> available does serve as an obstacle for non-free software.  And using
> non-free library with a free module is against the GPL, so it is
> illegal.  We cannot prevent people from lying and doing illegal
> things, we can only make it harder.

IMO, licenses are to restrict the usage, not arbitrary technical
limitations. We could similary have a token declaration in FFI interface, when
loading a library, no?

You are preventing  people not familiar with programming who can't write a
simple C wrapper to load a proprietary library, but it ain't stop any malicious
company anyway. At the same time, the strategy is slowing down
Emacs development and make it harder for talented people to actually write
useful code for Emacs. It is also growing the C core unnecessary.

There is a plethora of MIT licensed math libraries, with big API surfaces,
well optimized for many architectures which users could bring into Emacs
 themselves.

Anyway, Guile is the "gnu extension language", and there are no
problems to expose FFI:

https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html

How come there is no decision against loading shared objects in Guile? There was
even a discussion, on this very mailing list, of Emacs core re-written in Guile
(which seems to not happen). That would auto-expose Guile FFI, but that seemed
to be OK?

Similar for CLisp and GCL, both are GNU projects and expose FFI.

With all respect to Emacs developers, especially RMS and you, I am very grateful
for all your work and the software you gave us, but I don't understand how is
this strategy helping Emacs and GNU development?

> > It is sad to see Emacs being hamstrung and users being limited because
> > someone could do something that would have no impact whatsoever with the
> > project or any other user.
>
> This is a sad world for more reasons than one, but discussing that is
> off-topic here.

It shouldn't be Eli, because it is about Emacs development, and you know as well
that it is rather shooting us in the foot, than helping.

I am honesly not trying to be PITA. I understand the subject is sensitive. I have
seen the history, and (I think) I understand why the decision was made. I
won't press the subject more, but I think it may be worth to revisit the
 decision since times have changed.

With all respect
/arthur
________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 12 augusti 2024 15:22
Till: Nicolas Martyanoff <nicolas@n16f.net>
Kopia: arthur.miller@live.com <arthur.miller@live.com>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: Nicolas Martyanoff <nicolas@n16f.net>,  arthur.miller@live.com,
>   emacs-devel@gnu.org
> Date: Mon, 12 Aug 2024 14:11:07 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > We made the effort to allow loading dynamic modules precisely for this
> > reason: to allow free libraries to be used, but not non-free ones.
>
> You absolutely can use non-free dynamic modules: enforcing the existence
> of a symbol saying "I promise I'm free" does not change anything. One
> could also easily add a free dynamic module that calls non-free
> libraries.

The need to declare that a library is free and have its sources freely
available does serve as an obstacle for non-free software.  And using
non-free library with a free module is against the GPL, so it is
illegal.  We cannot prevent people from lying and doing illegal
things, we can only make it harder.

> It is sad to see Emacs being hamstrung and users being limited because
> someone could do something that would have no impact whatsoever with the
> project or any other user.

This is a sad world for more reasons than one, but discussing that is
off-topic here.

[-- Attachment #2: Type: text/html, Size: 14404 bytes --]

Re: as for Calc and the math library

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Tue, 13 Aug 2024 07:16:35 +0000
> 
> > > Eli Zaretskii <eliz@gnu.org> writes:
> > >
> > > > We made the effort to allow loading dynamic modules precisely for this
> > > > reason: to allow free libraries to be used, but not non-free ones.
> 
> Emacs users are "linking" Emacs to all kind of proprietary, non-free services
> these days. You are reading /r/Emacs yourself and seen packages popping up
> targeting this or that proprietary service almost every day. Shared libraries
> are no longer the staple of distributing closed source. The computing landscape
> has change a lot since 1980s/1990s.
> 
> > > You absolutely can use non-free dynamic modules: enforcing the existence
> > > of a symbol saying "I promise I'm free" does not change anything. One
> > > could also easily add a free dynamic module that calls non-free
> > > libraries.
> >
> > The need to declare that a library is free and have its sources freely
> > available does serve as an obstacle for non-free software.  And using
> > non-free library with a free module is against the GPL, so it is
> > illegal.  We cannot prevent people from lying and doing illegal
> > things, we can only make it harder.
> 
> IMO, licenses are to restrict the usage, not arbitrary technical
> limitations. We could similary have a token declaration in FFI interface, when
> loading a library, no? 

You are basically reiterating what Nicolas already said, and I
answered that.  I see no reason to repeat my answers to these
arguments, they are still the same.

> You are preventing  people not familiar with programming who can't write a
> simple C wrapper to load a proprietary library, but it ain't stop any malicious
> company anyway.

People not familiar with programming will be unable to use FFI for
anything serious anyway.

> At the same time, the strategy is slowing down
> Emacs development and make it harder for talented people to actually write
> useful code for Emacs. It is also growing the C core unnecessary. 

I don't share this view of the Emacs development, of course.  And with
all due respect, I don't think you are in a good position to judge
that: you are not involved in this deep enough and long enough to have
the perspective and experience to make such judgments.

> There is a plethora of MIT licensed math libraries, with big API surfaces, 
> well optimized for many architectures which users could bring into Emacs
>  themselves.

AFAIU, there should be no reasons not to be able to load MIT licensed
libraries via the emacs-module machinery.

> Anyway, Guile is the "gnu extension language", and there are no
> problems to expose FFI:
> 
> https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html
> 
> How come there is no decision against loading shared objects in Guile? There was
> even a discussion, on this very mailing list, of Emacs core re-written in Guile
> (which seems to not happen). That would auto-expose Guile FFI, but that seemed
> to be OK?
> 
> Similar for CLisp and GCL, both are GNU projects and expose FFI.

These questions are not for me to answer.  I'm not responsible for
these other projects.  I think they are mistaken, but then the Guile
folks never listened to what I had to say on quite a few subjects, so
I'm not surprised.  (I know nothing about how Common Lisp is developed
and what are its goals.)

For the record: there are other GNU projects that use the same
"restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I
know about.  So it isn't like Emacs is alone in this.

Re: as for Calc and the math library

[Nicolas Martyanoff]

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIU, there should be no reasons not to be able to load MIT licensed
> libraries via the emacs-module machinery.

IIRC the reason I abandoned was that you can load a dynamic module but
there is no mechanism to reload it once modified, meaning one cannot
develop packages with dynamic modules iteratively.

There is also nothing in place to facilitate building these dynamic
modules as part of an Emacs package, and it is not that simple: locate C
files distributed with the package, build the library with the right
flags depending on the current platform, cache it in a place that makes
sense…

-- 
Nicolas Martyanoff
https://n16f.net
nicolas@n16f.net

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: arthur miller <arthur.miller@live.com>,  nicolas@n16f.net,
>   emacs-devel@gnu.org
> Date: Tue, 13 Aug 2024 15:10:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > AFAIU, there should be no reasons not to be able to load MIT licensed
> > libraries via the emacs-module machinery.
> 
> IIRC the reason I abandoned was that you can load a dynamic module but
> there is no mechanism to reload it once modified, meaning one cannot
> develop packages with dynamic modules iteratively.

This is a technical problem with loading shared libraries, so it will
also happen with FFI, AFAIU.

In general, unloading and reloading doesn't work in Emacs well even in
Lisp, less so with native-compiled Lisp.  Not sure this can be
improved and how, but it would be a welcome addition and enhancement.

> There is also nothing in place to facilitate building these dynamic
> modules as part of an Emacs package, and it is not that simple: locate C
> files distributed with the package, build the library with the right
> flags depending on the current platform, cache it in a place that makes
> sense…

That again is mostly common with any solution based on loading shared
libraries.  We have elaborate documentation of then interfaces for
writing and using dynamic modules, but of course if someone will
submit some boilerplate code to ease this, or come up with automation
of some of this, I'm sure that would be welcome.

Re: as for Calc and the math library

[Nicolas Martyanoff]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Martyanoff <nicolas@n16f.net>
>> Cc: arthur miller <arthur.miller@live.com>,  nicolas@n16f.net,
>>   emacs-devel@gnu.org
>> Date: Tue, 13 Aug 2024 15:10:28 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > AFAIU, there should be no reasons not to be able to load MIT licensed
>> > libraries via the emacs-module machinery.
>> 
>> IIRC the reason I abandoned was that you can load a dynamic module but
>> there is no mechanism to reload it once modified, meaning one cannot
>> develop packages with dynamic modules iteratively.
>
> This is a technical problem with loading shared libraries, so it will
> also happen with FFI, AFAIU.
>
> In general, unloading and reloading doesn't work in Emacs well even in
> Lisp, less so with native-compiled Lisp.  Not sure this can be
> improved and how, but it would be a welcome addition and enhancement.

The main difference is that with a dynamic module, if you want to add a
new C function available in elisp or modify an existing one, you have to
update the C glue code defining the function and restart Emacs to build
and reload it.

With the kind of FFI API we are talking about, once the
foreign library has been loaded (e.g. libpq), one can write Elisp
functions calling foreign functions incrementally.

This is not the end of the world if you are just binding a couple
functions and you know everything you need. When you are binding a
large and complex library, being able to go at it incrementally and
testing everything in Emacs at each step makes it much comfortable.

Ultimately all of this is moot since the political aspect takes
precedence. But thinking about it, it should be possible to build a
dynamic module exposing a couple functions whose job would be to open
arbitrary shared libraries and call functions with libffi (which is MIT
licensed so no license violation here). Some Emacs code could be used to
extract constant values, structure layouts and other information
necessary at runtime, but it is not that hard (see cffi-grovel in Common
Lisp for example).

-- 
Nicolas Martyanoff
https://n16f.net
nicolas@n16f.net

Sv: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 10345 bytes --]

> > > > Eli Zaretskii <eliz@gnu.org> writes:
> > > >
> > > > > We made the effort to allow loading dynamic modules precisely for this
> > > > > reason: to allow free libraries to be used, but not non-free ones.
> >
> > Emacs users are "linking" Emacs to all kind of proprietary, non-free services
> > these days. You are reading /r/Emacs yourself and seen packages popping up
> > targeting this or that proprietary service almost every day. Shared libraries
> > are no longer the staple of distributing closed source. The computing
> > landscape
> > has change a lot since 1980s/1990s.
> >
> > > > You absolutely can use non-free dynamic modules: enforcing the existence
> > > > of a symbol saying "I promise I'm free" does not change anything. One
> > > > could also easily add a free dynamic module that calls non-free
> > > > libraries.
> > >
> > > The need to declare that a library is free and have its sources freely
> > > available does serve as an obstacle for non-free software.  And using
> > > non-free library with a free module is against the GPL, so it is
> > > illegal.  We cannot prevent people from lying and doing illegal
> > > things, we can only make it harder.
> >
> > IMO, licenses are to restrict the usage, not arbitrary technical
> > limitations. We could similary have a token declaration in FFI interface, when
> > loading a library, no?
>
> You are basically reiterating what Nicolas already said, and I
> answered that.  I see no reason to repeat my answers to these
> arguments, they are still the same.

Just justifiying the statement that Emacs could have something similar as
GPL_COMPATIBLE token in Lisp API, just as there is in module API. I don't
 think I have seen anyone suggesting that before, at least not what I know of.

> > You are preventing  people not familiar with programming who can't write a
> > simple C wrapper to load a proprietary library, but it ain't stop any
> > malicious
> > company anyway.
>
> People not familiar with programming will be unable to use FFI for
> anything serious anyway.

I think you have misunderstand what I am saying: my point was that this
situation is making it more tedious for experienced people to work with Emacs
while possibly being a stopper *only* for unexperienced programmers.

> > At the same time, the strategy is slowing down
> > Emacs development and make it harder for talented people to actually write
> > useful code for Emacs. It is also growing the C core unnecessary.
>
> I don't share this view of the Emacs development, of course.  And with
> all due respect, I don't think you are in a good position to judge
> that: you are not involved in this deep enough and long enough to have
> the perspective and experience to make such judgments.

Sure, I certainly am not experienced nor involved in Emacs as long and
as much as you or many others here.

However, I think everyone understands possible fears of a company, or even
just individuals loading proprietary libraries, which free world (GNU) does not
want to endorse and promote such usage. I don't even disagree that it is unjustified.

However, pragmatically, I don't think putting an obstacle is the best way. On the
 contrary, I think, making it as easy as possible to use and extend Emacs for
 whichever purpose, gives a positive incentive for people to see qualities in Emacs
 in particular, and implicitly in GNU project.

As with every important decision, there is a balance between the gain and the
damage. In this case, considering how easy is to work with C libraries in some
other Lisp implementations, and how faster it would be to write extensions and
experiment with Emacs, the gain is perhaps bigger than the possible loss.

> > There is a plethora of MIT licensed math libraries, with big API surfaces,
> > well optimized for many architectures which users could bring into Emacs
> >  themselves.
>
> AFAIU, there should be no reasons not to be able to load MIT licensed
> libraries via the emacs-module machinery.

Nobody is stopping anyone to implement anything as modules, outside of Emacs
core, and I didn't say anything against modules either. I just say FFI would
make it easier and faster.

> > Anyway, Guile is the "gnu extension language", and there are no
> > problems to expose FFI:
> >
> > https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html
> >
> > How come there is no decision against loading shared objects in Guile? There
> > was
> > even a discussion, on this very mailing list, of Emacs core re-written in
> > Guile
> > (which seems to not happen). That would auto-expose Guile FFI, but that seemed
> > to be OK?
> >
> > Similar for CLisp and GCL, both are GNU projects and expose FFI.
>
> These questions are not for me to answer.  I'm not responsible for
> these other projects.  I think they are mistaken, but then the Guile
> folks never listened to what I had to say on quite a few subjects, so
> I'm not surprised.  (I know nothing about how Common Lisp is developed
> and what are its goals.)

Of course you are not responsible for other projects, nobody thinks you are. My
point is that it is not unthinkable for a GNU project to implement FFI. Also, we
are not directly seeing commercial companies running toward Guile and linking
bunch of proprietary binaries into Guile runtime, and Guile is de facto, a
popular Scheme implementation.

> For the record: there are other GNU projects that use the same
> "restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I
> know about.  So it isn't like Emacs is alone in this.

I am not sure if it is relevant with non-lisp projects. There are lots of
projects with different needs, some are less, others are more self-contained. It
all depends how the software is used. Lisp(s), Emacs Lisp included, are usually
in somewhat special situation of being relatively isolated islands when it comes
to available software. Common Lisp perhaps being a biggest exception there.
An easy to use FFI makes it easier to take advantage of already existing software,
such as mathematical libraries for example.

Anyway, thanks for the arguments; I think it is useful to re-think the arguments,
regardless on which side of the arguments I am.

best regards
________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 13 augusti 2024 14:12
Till: arthur miller <arthur.miller@live.com>
Kopia: nicolas@n16f.net <nicolas@n16f.net>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library

> From: arthur miller <arthur.miller@live.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Tue, 13 Aug 2024 07:16:35 +0000
>
> > > Eli Zaretskii <eliz@gnu.org> writes:
> > >
> > > > We made the effort to allow loading dynamic modules precisely for this
> > > > reason: to allow free libraries to be used, but not non-free ones.
>
> Emacs users are "linking" Emacs to all kind of proprietary, non-free services
> these days. You are reading /r/Emacs yourself and seen packages popping up
> targeting this or that proprietary service almost every day. Shared libraries
> are no longer the staple of distributing closed source. The computing landscape
> has change a lot since 1980s/1990s.
>
> > > You absolutely can use non-free dynamic modules: enforcing the existence
> > > of a symbol saying "I promise I'm free" does not change anything. One
> > > could also easily add a free dynamic module that calls non-free
> > > libraries.
> >
> > The need to declare that a library is free and have its sources freely
> > available does serve as an obstacle for non-free software.  And using
> > non-free library with a free module is against the GPL, so it is
> > illegal.  We cannot prevent people from lying and doing illegal
> > things, we can only make it harder.
>
> IMO, licenses are to restrict the usage, not arbitrary technical
> limitations. We could similary have a token declaration in FFI interface, when
> loading a library, no?

You are basically reiterating what Nicolas already said, and I
answered that.  I see no reason to repeat my answers to these
arguments, they are still the same.

> You are preventing  people not familiar with programming who can't write a
> simple C wrapper to load a proprietary library, but it ain't stop any malicious
> company anyway.

People not familiar with programming will be unable to use FFI for
anything serious anyway.

> At the same time, the strategy is slowing down
> Emacs development and make it harder for talented people to actually write
> useful code for Emacs. It is also growing the C core unnecessary.

I don't share this view of the Emacs development, of course.  And with
all due respect, I don't think you are in a good position to judge
that: you are not involved in this deep enough and long enough to have
the perspective and experience to make such judgments.

> There is a plethora of MIT licensed math libraries, with big API surfaces,
> well optimized for many architectures which users could bring into Emacs
>  themselves.

AFAIU, there should be no reasons not to be able to load MIT licensed
libraries via the emacs-module machinery.

> Anyway, Guile is the "gnu extension language", and there are no
> problems to expose FFI:
>
> https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html
>
> How come there is no decision against loading shared objects in Guile? There was
> even a discussion, on this very mailing list, of Emacs core re-written in Guile
> (which seems to not happen). That would auto-expose Guile FFI, but that seemed
> to be OK?
>
> Similar for CLisp and GCL, both are GNU projects and expose FFI.

These questions are not for me to answer.  I'm not responsible for
these other projects.  I think they are mistaken, but then the Guile
folks never listened to what I had to say on quite a few subjects, so
I'm not surprised.  (I know nothing about how Common Lisp is developed
and what are its goals.)

For the record: there are other GNU projects that use the same
"restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I
know about.  So it isn't like Emacs is alone in this.

[-- Attachment #2: Type: text/html, Size: 27709 bytes --]

Re: as for Calc and the math library

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "nicolas@n16f.net" <nicolas@n16f.net>, "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>
> Date: Tue, 13 Aug 2024 21:43:00 +0000
> 
> > > IMO, licenses are to restrict the usage, not arbitrary technical
> > > limitations. We could similary have a token declaration in FFI interface, when
> > > loading a library, no?
> >
> > You are basically reiterating what Nicolas already said, and I
> > answered that.  I see no reason to repeat my answers to these
> > arguments, they are still the same.
> 
> Just justifiying the statement that Emacs could have something similar as
> GPL_COMPATIBLE token in Lisp API, just as there is in module API. I don't
>  think I have seen anyone suggesting that before, at least not what I know of.

Then I don't understand what you are suggesting here.  What do you
mean by "token in Lisp API"?  And if you mean something like what we
have in the emacs-module machinery, then how is that different from
what we already have?

> > > You are preventing  people not familiar with programming who can't write a
> > > simple C wrapper to load a proprietary library, but it ain't stop any
> > > malicious
> > > company anyway.
> >
> > People not familiar with programming will be unable to use FFI for
> > anything serious anyway.
> 
> I think you have misunderstand what I am saying: my point was that this
> situation is making it more tedious for experienced people to work with Emacs
> while possibly being a stopper *only* for unexperienced programmers.

I understood what you were saying, and I disagree with your assertion
that using emacs-module API makes the job harder.  If anything, it
makes it somewhat easier: it gives the module a way to call Emacs
primitives and provides various auxiliary facilities, without which
adjusting a library to Emacs would be a very hard job, because Emacs
has its own object system that is quite different from that of any
programming language that can be used to code a module.  I suggest to
re-read the "Writing Dynamically-Loaded Modules" appendix to the ELisp
manual and imagine how hard it would be to use FFI without many of
those facilities provided specifically for dynamic modules.

> However, pragmatically, I don't think putting an obstacle is the best way. On the
>  contrary, I think, making it as easy as possible to use and extend Emacs for
>  whichever purpose, gives a positive incentive for people to see qualities in Emacs
>  in particular, and implicitly in GNU project.
> 
> As with every important decision, there is a balance between the gain and the
> damage. In this case, considering how easy is to work with C libraries in some
> other Lisp implementations, and how faster it would be to write extensions and
> experiment with Emacs, the gain is perhaps bigger than the possible loss.

There are examples out there what happens when projects take the route
you suggest.  I cannot say I'm encouraged with LLVM being used for
proprietary closed-code extensions and targets, nor am I overwhelmed
with the popularity of Guile, which does have unrestricted FFI.  So I
see no reason to believe what you suggest will bring such significant
advantages to Emacs that we should seriously consider lifting the
GPL-compatibility restriction.

> > > There is a plethora of MIT licensed math libraries, with big API surfaces,
> > > well optimized for many architectures which users could bring into Emacs
> > >  themselves.
> >
> > AFAIU, there should be no reasons not to be able to load MIT licensed
> > libraries via the emacs-module machinery.
> 
> Nobody is stopping anyone to implement anything as modules, outside of Emacs
> core, and I didn't say anything against modules either. I just say FFI would
> make it easier and faster.

See above: I think you are mistaken in your assessment.  I don't see
any reasons why using FFI would be so much easier than using the
existing modules API.  Given some simple boilerplate (like the DEFUN
macro you can see in test/src/emacs-module-resources/mod-test.c, and
other utility functions there), the job becomes quite simple.  By
contrast, using FFI the programmer would need to figure all this out
on their own, and that requires very good familiarity with Emacs
internals.

> > For the record: there are other GNU projects that use the same
> > "restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I
> > know about.  So it isn't like Emacs is alone in this.
> 
> I am not sure if it is relevant with non-lisp projects.

How so?  GNU Make has its own scripting language, and Gawk implements
the Awk programming language, which is a full-fledged specialized
language for data processing.  How is this "not relevant" to our case?
Gawk even comes with a small set of extensions written using the
plug-in protocol, and I invite you to review them to see how useful
they are, even though they are relatively small and do simple tasks.

> There are lots of
> projects with different needs, some are less, others are more self-contained. It
> all depends how the software is used. Lisp(s), Emacs Lisp included, are usually
> in somewhat special situation of being relatively isolated islands when it comes
> to available software. Common Lisp perhaps being a biggest exception there.
> An easy to use FFI makes it easier to take advantage of already existing software, 
> such as mathematical libraries for example. 

I think you greatly underestimate the complexity of using FFI-style
API to allow Emacs to use a mathematical library.  For starters,
floating-point values have a very specific representation in Emacs, so
you cannot just take a value from the library and use it.  Next, most
such libraries allocate memory for its data structures (matrices
etc.), so using them will need to provide GC glue for freeing the
resources when an instance of a data structure is no longer needed.
And that is just the tip of a very large iceberg.

> Anyway, thanks for the arguments; I think it is useful to re-think the arguments,
> regardless on which side of the arguments I am.

As a practical example, I suggest to take a library and integrate it
with Emacs using the modules API, if you haven't done that already.
It is sometimes amazing how many little details need to be figured out
and coded for that, when the target is Emacs Lisp.

Sv: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 18449 bytes --]

> >
> > > > IMO, licenses are to restrict the usage, not arbitrary technical
> > > > limitations. We could similary have a token declaration in FFI interface,
> > > > when
> > > > loading a library, no?
> > >
> > > You are basically reiterating what Nicolas already said, and I
> > > answered that.  I see no reason to repeat my answers to these
> > > arguments, they are still the same.
> >
> > Just justifiying the statement that Emacs could have something similar as
> > GPL_COMPATIBLE token in Lisp API, just as there is in module API. I don't
> >  think I have seen anyone suggesting that before, at least not what I know of.
>
> Then I don't understand what you are suggesting here.  What do you
> mean by "token in Lisp API"?  And if you mean something like what we

I suggest exactly that, as it sounds: a compliance token, as you have for modules.

Something like:

(defun load-library (library-name, gpl-compatible)
"Load a shared object with LIBRARY-NAME. The module has to be compatible with
GPL licence, for the deatils see https://www.gnu.org/licenses/gpl-3.0.txt, which
is asserted by GPL-COMPATIBLE been non-nil."
 ( ... ))

> have in the emacs-module machinery, then how is that different from
> what we already have?

It is not different at all; it is the main point and *the* reason why I suggest
it. Being in Lisp is obviously a lesser obstacle than being in C, but the same
argument(s) you presented for module code, and possible violations of the
licence, are valid for the Lisp code as well.

By the way I was about to snitch FFI from SXEmacs, but I see now Tromeys code is
in Emacs, thanks to Madhus mail. I know Tom made one, but I didn't know it was
still included in git sources.

> > > > You are preventing  people not familiar with programming who can't write a
> > > > simple C wrapper to load a proprietary library, but it ain't stop any
> > > > malicious
> > > > company anyway.
> > >
> > > People not familiar with programming will be unable to use FFI for
> > > anything serious anyway.
> >
> > I think you have misunderstand what I am saying: my point was that this
> > situation is making it more tedious for experienced people to work with Emacs
> > while possibly being a stopper *only* for unexperienced programmers.
>
> I understood what you were saying, and I disagree with your assertion
> that using emacs-module API makes the job harder.  If anything, it
> makes it somewhat easier: it gives the module a way to call Emacs
> primitives and provides various auxiliary facilities, without which
> adjusting a library to Emacs would be a very hard job, because Emacs
> has its own object system that is quite different from that of any
> programming language that can be used to code a module.  I suggest to
> re-read the "Writing Dynamically-Loaded Modules" appendix to the ELisp
> manual and imagine how hard it would be to use FFI without many of
> those facilities provided specifically for dynamic modules.

I understand what you say as well. From my relatively short experience of
writing some FFI code for SBCL, I find it easier to work iteratively from a Lisp
repl, than writing a C code, recompile, reload and test. I can just C-x C-e in
Slime and have my glue code re-evaled and re-installed, instead of recompiling
and reloading everything.

> > However, pragmatically, I don't think putting an obstacle is the best way. On
> > the
> >  contrary, I think, making it as easy as possible to use and extend Emacs for
> >  whichever purpose, gives a positive incentive for people to see qualities in
> > Emacs
> >  in particular, and implicitly in GNU project.
> >
> > As with every important decision, there is a balance between the gain and the
> > damage. In this case, considering how easy is to work with C libraries in some
> > other Lisp implementations, and how faster it would be to write extensions and
> > experiment with Emacs, the gain is perhaps bigger than the possible loss.
>
> There are examples out there what happens when projects take the route
> you suggest.  I cannot say I'm encouraged with LLVM being used for
> proprietary closed-code extensions and targets, nor am I overwhelmed
> with the popularity of Guile, which does have unrestricted FFI.  So I
> see no reason to believe what you suggest will bring such significant
> advantages to Emacs that we should seriously consider lifting the
> GPL-compatibility restriction.

I don't say you should allow unrestricted access. Just to furntiture around a
bit, and allow access to a library from Lisp, not just from C.

> > > > There is a plethora of MIT licensed math libraries, with big API surfaces,
> > > > well optimized for many architectures which users could bring into Emacs
> > > >  themselves.
> > >
> > > AFAIU, there should be no reasons not to be able to load MIT licensed
> > > libraries via the emacs-module machinery.
> >
> > Nobody is stopping anyone to implement anything as modules, outside of Emacs
> > core, and I didn't say anything against modules either. I just say FFI would
> > make it easier and faster.
>
> See above: I think you are mistaken in your assessment.  I don't see
> any reasons why using FFI would be so much easier than using the
> existing modules API.  Given some simple boilerplate (like the DEFUN
> macro you can see in test/src/emacs-module-resources/mod-test.c, and
> other utility functions there), the job becomes quite simple.  By
> contrast, using FFI the programmer would need to figure all this out
> on their own, and that requires very good familiarity with Emacs
> internals.
>
> > > For the record: there are other GNU projects that use the same
> > > "restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I
> > > know about.  So it isn't like Emacs is alone in this.
> >
> > I am not sure if it is relevant with non-lisp projects.
>
> How so?  GNU Make has its own scripting language, and Gawk implements

Actually two scripting lanugages. More recent one is Guile. I have never felt
need to extend make, so no idea if Guile FFI is usable from make.

> the Awk programming language, which is a full-fledged specialized
> language for data processing.  How is this "not relevant" to our case?

I didn't thought it is relevant since neither make, nor awk, nor gcc are used
interactively to write Emacs applications, to solve computational problems and
similar in the way Emacs is used.

> Gawk even comes with a small set of extensions written using the
> plug-in protocol, and I invite you to review them to see how useful
> they are, even though they are relatively small and do simple tasks.

I have basically stopped using Bash & Co (tr, awk, sed etc) for any scripting. I
don't think those are bad, but as you have seen from my numerous posts on Reddit
promoting Elisp and debugging in Elisp, I do honestly find scripting in Lisp and
Emacs much more enjoyable than debugging shell scripts. I don't think it is even
comparable.

Perhaps Emanuel could write an awk implementation in Elisp, that works on Emacs
buffers, as a (one of) higher level interface. It would be probably more useful
and enjoybale for text processing than extending awk with C++ modules or
implementing some sort of DSL based on a bunch of cryptic acronyms. At least awk
is well documented. Just my opinion, I hope Emanuel is not angry on me for
reflecting and suggesting it.

By the way, a regression (sorry), perhaps someone more literally gifted than me
and better used to English language, could add a few words to Emacs manual about
how Emacs API works, regarding text processing and buffer management at
least. Something like this:
________________________________________________________________________________
Emacs Lisp uses a simple procedural model to manipulate windows, files, buffers,
and other objects.

In Emacs API, we typically manipulate a current object, whether it is a buffer,
point, window, frame, etc. It means we act on a selected buffer, selected
window, frame which we then manipulate by calling an appropriate function. Which
one we need is best looked up in the manual. The details on the calling
arguments and returned results are easiset looked up via C-h f function-name
RET.

Some of functions can take an optional object to act on, instead of acting on
the current-one, but the basic model of working with Emacs API buffer, window
and frame management, as well as text processing, is to select something (make
it current), and than acting on it.
________________________________________________________________________________

Something in that style, I don't see anything similar in introduction to the
manual, and I think it might be useful to clarify it. At least I have understand
Emacs API so.

One can also speculate how API could look like, and for illustrative purposes,
we can compare for example to similar API model like PostScript or OpenGL vs
Xlib or win32, or to iterator based design as suggested by Yuri. But I don't
think it belongs to the manual or emacs-devel list.

> > There are lots of
> > projects with different needs, some are less, others are more self-contained.
> > It
> > all depends how the software is used. Lisp(s), Emacs Lisp included, are
> > usually
> > in somewhat special situation of being relatively isolated islands when it
> > comes
> > to available software. Common Lisp perhaps being a biggest exception there.
> > An easy to use FFI makes it easier to take advantage of already existing
> > software,
> > such as mathematical libraries for example.
>
> I think you greatly underestimate the complexity of using FFI-style
> API to allow Emacs to use a mathematical library.  For starters,
> floating-point values have a very specific representation in Emacs, so
> you cannot just take a value from the library and use it.  Next, most
> such libraries allocate memory for its data structures (matrices
> etc.), so using them will need to provide GC glue for freeing the
> resources when an instance of a data structure is no longer needed.
> And that is just the tip of a very large iceberg.

Agree. I haven't seen Tromeys code yet, but I have seen and tried FFI in
SXEmacs, and as said in SBCL.

SBCL does not use libffi under the hood (unlike more portable CFFI), and they do
give one access to raw pointers and raw memory allocated by C runtime, as well
as the responsibility to free that allocated memory. For the good and for the
bad.

Now, Emacs also has an interface to GCC, I wonder how hard/easy is to expose C
runtime via native compiler to Lisp? I am not familiar with libgccjit, but as I
udnerstand eln files are shared objects under the hood? Does it not make the ffi
implementation easier? Sorry if it is an uninformed question, I haven't looked
that up myself.

> > Anyway, thanks for the arguments; I think it is useful to re-think the
> > arguments,
> > regardless on which side of the arguments I am.
>
> As a practical example, I suggest to take a library and integrate it
> with Emacs using the modules API, if you haven't done that already.
> It is sometimes amazing how many little details need to be figured out
> and coded for that, when the target is Emacs Lisp.
>

I have done some FFI with SBCL, and yes, I agree there are lots of details to
take care of. Error checking via Lisp is not trivial, compared to simple
if-statement in C. But still, if I f-up in SBCL with my glue, I can just rewrite
and C-x C-e in Slime and switch to repl window to test. As said above, I don't
think it is comparable to writing C code.

________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 14 augusti 2024 07:10
Till: arthur miller <arthur.miller@live.com>
Kopia: nicolas@n16f.net <nicolas@n16f.net>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library

> From: arthur miller <arthur.miller@live.com>
> CC: "nicolas@n16f.net" <nicolas@n16f.net>, "emacs-devel@gnu.org"
>        <emacs-devel@gnu.org>
> Date: Tue, 13 Aug 2024 21:43:00 +0000
>
> > > IMO, licenses are to restrict the usage, not arbitrary technical
> > > limitations. We could similary have a token declaration in FFI interface, when
> > > loading a library, no?
> >
> > You are basically reiterating what Nicolas already said, and I
> > answered that.  I see no reason to repeat my answers to these
> > arguments, they are still the same.
>
> Just justifiying the statement that Emacs could have something similar as
> GPL_COMPATIBLE token in Lisp API, just as there is in module API. I don't
>  think I have seen anyone suggesting that before, at least not what I know of.

Then I don't understand what you are suggesting here.  What do you
mean by "token in Lisp API"?  And if you mean something like what we
have in the emacs-module machinery, then how is that different from
what we already have?

> > > You are preventing  people not familiar with programming who can't write a
> > > simple C wrapper to load a proprietary library, but it ain't stop any
> > > malicious
> > > company anyway.
> >
> > People not familiar with programming will be unable to use FFI for
> > anything serious anyway.
>
> I think you have misunderstand what I am saying: my point was that this
> situation is making it more tedious for experienced people to work with Emacs
> while possibly being a stopper *only* for unexperienced programmers.

I understood what you were saying, and I disagree with your assertion
that using emacs-module API makes the job harder.  If anything, it
makes it somewhat easier: it gives the module a way to call Emacs
primitives and provides various auxiliary facilities, without which
adjusting a library to Emacs would be a very hard job, because Emacs
has its own object system that is quite different from that of any
programming language that can be used to code a module.  I suggest to
re-read the "Writing Dynamically-Loaded Modules" appendix to the ELisp
manual and imagine how hard it would be to use FFI without many of
those facilities provided specifically for dynamic modules.

> However, pragmatically, I don't think putting an obstacle is the best way. On the
>  contrary, I think, making it as easy as possible to use and extend Emacs for
>  whichever purpose, gives a positive incentive for people to see qualities in Emacs
>  in particular, and implicitly in GNU project.
>
> As with every important decision, there is a balance between the gain and the
> damage. In this case, considering how easy is to work with C libraries in some
> other Lisp implementations, and how faster it would be to write extensions and
> experiment with Emacs, the gain is perhaps bigger than the possible loss.

There are examples out there what happens when projects take the route
you suggest.  I cannot say I'm encouraged with LLVM being used for
proprietary closed-code extensions and targets, nor am I overwhelmed
with the popularity of Guile, which does have unrestricted FFI.  So I
see no reason to believe what you suggest will bring such significant
advantages to Emacs that we should seriously consider lifting the
GPL-compatibility restriction.

> > > There is a plethora of MIT licensed math libraries, with big API surfaces,
> > > well optimized for many architectures which users could bring into Emacs
> > >  themselves.
> >
> > AFAIU, there should be no reasons not to be able to load MIT licensed
> > libraries via the emacs-module machinery.
>
> Nobody is stopping anyone to implement anything as modules, outside of Emacs
> core, and I didn't say anything against modules either. I just say FFI would
> make it easier and faster.

See above: I think you are mistaken in your assessment.  I don't see
any reasons why using FFI would be so much easier than using the
existing modules API.  Given some simple boilerplate (like the DEFUN
macro you can see in test/src/emacs-module-resources/mod-test.c, and
other utility functions there), the job becomes quite simple.  By
contrast, using FFI the programmer would need to figure all this out
on their own, and that requires very good familiarity with Emacs
internals.

> > For the record: there are other GNU projects that use the same
> > "restrictions" on plugins: Gawk, GNU Make, and GCC, to mention those I
> > know about.  So it isn't like Emacs is alone in this.
>
> I am not sure if it is relevant with non-lisp projects.

How so?  GNU Make has its own scripting language, and Gawk implements
the Awk programming language, which is a full-fledged specialized
language for data processing.  How is this "not relevant" to our case?
Gawk even comes with a small set of extensions written using the
plug-in protocol, and I invite you to review them to see how useful
they are, even though they are relatively small and do simple tasks.

> There are lots of
> projects with different needs, some are less, others are more self-contained. It
> all depends how the software is used. Lisp(s), Emacs Lisp included, are usually
> in somewhat special situation of being relatively isolated islands when it comes
> to available software. Common Lisp perhaps being a biggest exception there.
> An easy to use FFI makes it easier to take advantage of already existing software,
> such as mathematical libraries for example.

I think you greatly underestimate the complexity of using FFI-style
API to allow Emacs to use a mathematical library.  For starters,
floating-point values have a very specific representation in Emacs, so
you cannot just take a value from the library and use it.  Next, most
such libraries allocate memory for its data structures (matrices
etc.), so using them will need to provide GC glue for freeing the
resources when an instance of a data structure is no longer needed.
And that is just the tip of a very large iceberg.

> Anyway, thanks for the arguments; I think it is useful to re-think the arguments,
> regardless on which side of the arguments I am.

As a practical example, I suggest to take a library and integrate it
with Emacs using the modules API, if you haven't done that already.
It is sometimes amazing how many little details need to be figured out
and coded for that, when the target is Emacs Lisp.

[-- Attachment #2: Type: text/html, Size: 44796 bytes --]

Re: Sv: as for Calc and the math library

[Nicolas Martyanoff]

arthur miller <arthur.miller@live.com> writes:

> I suggest exactly that, as it sounds: a compliance token, as you have for modules.
>
> Something like:
>
> (defun load-library (library-name, gpl-compatible)
> "Load a shared object with LIBRARY-NAME. The module has to be compatible with
> GPL licence, for the deatils see https://www.gnu.org/licenses/gpl-3.0.txt, which
> is asserted by GPL-COMPATIBLE been non-nil."
>  ( ... ))
>
>> have in the emacs-module machinery, then how is that different from
>> what we already have?

I would be fine with that, but I still do not see the point. IANAL but
as far as I know, using dlopen/dlsym to call a function in another
library does not create a new program, there is no notion of derived
work of any kind, this has nothing to do with either the GPL or the
license of the library.

If this is a purely ideological issue, and it feels to me like it is, then
why is it fine for Emacs to have functions to call external programs and
read their output? What if these programs are proprietary?

-- 
Nicolas Martyanoff
https://n16f.net
nicolas@n16f.net

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  "nicolas@n16f.net" <nicolas@n16f.net>,
>   "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Wed, 14 Aug 2024 11:56:01 +0200
> 
> as far as I know, using dlopen/dlsym to call a function in another
> library does not create a new program, there is no notion of derived
> work of any kind, this has nothing to do with either the GPL or the
> license of the library.

AFAIU, according to GPL, using a shared library cannot even be subject
to LGPL, only to GPL.  The libgcc shared library is one frequent case
in point.  So I think you are wrong.

> If this is a purely ideological issue, and it feels to me like it is, then
> why is it fine for Emacs to have functions to call external programs and
> read their output? What if these programs are proprietary?

Exactly because they are separate programs, and because we don't
distribute them (and don't encourage anyone to use them).

In any case, if you, or someone else wants to discuss GPL-related
issues and their utility, please take the discussion elsewhere, for
example gnu-misc-discuss.  This list is not for such discussions.

Re: as for Calc and the math library

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Martyanoff <nicolas@n16f.net>
>> Cc: arthur miller <arthur.miller@live.com>,  emacs-devel@gnu.org
>> Date: Mon, 12 Aug 2024 13:23:27 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: arthur miller <arthur.miller@live.com>
>> >> Date: Mon, 12 Aug 2024 05:30:08 +0000
>> >> 
>> >> Even better, given people proper FFI so they can import and use any of the tens
>> >> or hundreds of quality math libraries available.
>> >
>> > Not going to happen, and you know it.
>> 
>> Naïve question, why?
>
> Because providing FFI would allow using non-free libraries in Emacs.
>
> We made the effort to allow loading dynamic modules precisely for this
> reason: to allow free libraries to be used, but not non-free ones.

There is an item in etc/TODO about adding FFI, as an important feature:

  ** FFI (foreign function interface)
  See e.g. https://lists.gnu.org/r/emacs-devel/2013-10/msg00246.html

  One way of doing this is to start with fx's dynamic loading, and use it
  to implement things like auto-loaded buffer parsers and database
  access in cases which need more than Lisp.

Now I'm confused.

Re: as for Calc and the math library

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Nicolas Martyanoff <nicolas@n16f.net>
>>> Cc: arthur miller <arthur.miller@live.com>,  emacs-devel@gnu.org
>>> Date: Mon, 12 Aug 2024 13:23:27 +0200
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> >> From: arthur miller <arthur.miller@live.com>
>>> >> Date: Mon, 12 Aug 2024 05:30:08 +0000
>>> >> 
>>> >> Even better, given people proper FFI so they can import and use any of the tens
>>> >> or hundreds of quality math libraries available.
>>> >
>>> > Not going to happen, and you know it.
>>> 
>>> Naïve question, why?
>>
>> Because providing FFI would allow using non-free libraries in Emacs.
>>
>> We made the effort to allow loading dynamic modules precisely for this
>> reason: to allow free libraries to be used, but not non-free ones.
>
> There is an item in etc/TODO about adding FFI, as an important feature:
>
>   ** FFI (foreign function interface)
>   See e.g. https://lists.gnu.org/r/emacs-devel/2013-10/msg00246.html
>
>   One way of doing this is to start with fx's dynamic loading, and use it
>   to implement things like auto-loaded buffer parsers and database
>   access in cases which need more than Lisp.
>
> Now I'm confused.

I guess an FFI is already there? Or was there because it looks kind of
dead:

  https://github.com/tromey/emacs-ffi

Tom Tromey says in one of the issues

  https://github.com/tromey/emacs-ffi/issues/20

that John Wigley asked him on IRC to submit it for inclusion. Can't find
anything on emacs-devel though.

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Nicolas Martyanoff <nicolas@n16f.net>,  arthur.miller@live.com,
>   emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 06:11:00 +0200
> 
> I guess an FFI is already there? Or was there because it looks kind of
> dead:
> 
>   https://github.com/tromey/emacs-ffi
> 
> Tom Tromey says in one of the issues
> 
>   https://github.com/tromey/emacs-ffi/issues/20
> 
> that John Wigley asked him on IRC to submit it for inclusion. Can't find
> anything on emacs-devel though.

It doesn't ensure GPL-compliance, AFAICT, so in its current form it
cannot be accepted, sorry.  And I'm not sure I understand how can one
technically enforce GPL compliance in FFI-style loading of arbitrary
shared libraries.  The only idea that comes to mind is allow-list of
known libraries, the way we do in sqlite.c, but I'm not sure that
method is scalable to the basically infinite world of arbitrary
libraries.

Re: as for Calc and the math library

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Nicolas Martyanoff <nicolas@n16f.net>,  arthur.miller@live.com,
>>   emacs-devel@gnu.org
>> Date: Wed, 14 Aug 2024 06:11:00 +0200
>> 
>> I guess an FFI is already there? Or was there because it looks kind of
>> dead:
>> 
>>   https://github.com/tromey/emacs-ffi
>> 
>> Tom Tromey says in one of the issues
>> 
>>   https://github.com/tromey/emacs-ffi/issues/20
>> 
>> that John Wigley asked him on IRC to submit it for inclusion. Can't find
>> anything on emacs-devel though.
>
> It doesn't ensure GPL-compliance, AFAICT, so in its current form it
> cannot be accepted, sorry.  And I'm not sure I understand how can one
> technically enforce GPL compliance in FFI-style loading of arbitrary
> shared libraries.  The only idea that comes to mind is allow-list of
> known libraries, the way we do in sqlite.c, but I'm not sure that
> method is scalable to the basically infinite world of arbitrary
> libraries.

Maybe one should remove the entry from etc/TODO then?

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 08:28:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: Nicolas Martyanoff <nicolas@n16f.net>,  arthur.miller@live.com,
> >>   emacs-devel@gnu.org
> >> Date: Wed, 14 Aug 2024 06:11:00 +0200
> >> 
> >> I guess an FFI is already there? Or was there because it looks kind of
> >> dead:
> >> 
> >>   https://github.com/tromey/emacs-ffi
> >> 
> >> Tom Tromey says in one of the issues
> >> 
> >>   https://github.com/tromey/emacs-ffi/issues/20
> >> 
> >> that John Wigley asked him on IRC to submit it for inclusion. Can't find
> >> anything on emacs-devel though.
> >
> > It doesn't ensure GPL-compliance, AFAICT, so in its current form it
> > cannot be accepted, sorry.  And I'm not sure I understand how can one
> > technically enforce GPL compliance in FFI-style loading of arbitrary
> > shared libraries.  The only idea that comes to mind is allow-list of
> > known libraries, the way we do in sqlite.c, but I'm not sure that
> > method is scalable to the basically infinite world of arbitrary
> > libraries.
> 
> Maybe one should remove the entry from etc/TODO then?

Maybe.

Re: as for Calc and the math library

[Suhail Singh]

Eli Zaretskii <eliz@gnu.org> writes:

>> I guess an FFI is already there? Or was there because it looks kind of
>> dead:
>> 
>>   https://github.com/tromey/emacs-ffi
>> 
>> Tom Tromey says in one of the issues
>> 
>>   https://github.com/tromey/emacs-ffi/issues/20
>> 
>> that John Wigley asked him on IRC to submit it for inclusion. Can't find
>> anything on emacs-devel though.
>
> It doesn't ensure GPL-compliance, AFAICT, so in its current form it
> cannot be accepted, sorry. And I'm not sure I understand how can one
> technically enforce GPL compliance in FFI-style loading of arbitrary
> shared libraries.  The only idea that comes to mind is allow-list of
> known libraries, the way we do in sqlite.c, but I'm not sure that
> method is scalable to the basically infinite world of arbitrary
> libraries.

On the topic of what would be acceptable for an FFI, wouldn't something
akin to what's done for modules be sufficient ?  I.e., have the users of
the interface explicitly state that they are compliant.

It would scale better than an allow-list.  IIUC, Arthur mentioned this
in another thread.  If this wouldn't be sufficient for an FFI, could you
please elaborate on why that's the case ?

The question here isn't about what does or does not constitute GPL
compliance, but what Emacs, as a project, is trying to ensure when it
comes to such compliance.  In the case of modules, at least, a claim of
compliance is sufficient (without any additional verification).

-- 
Suhail

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Suhail Singh <suhailsingh247@gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   nicolas@n16f.net,
>   arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 10:00:18 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It doesn't ensure GPL-compliance, AFAICT, so in its current form it
> > cannot be accepted, sorry. And I'm not sure I understand how can one
> > technically enforce GPL compliance in FFI-style loading of arbitrary
> > shared libraries.  The only idea that comes to mind is allow-list of
> > known libraries, the way we do in sqlite.c, but I'm not sure that
> > method is scalable to the basically infinite world of arbitrary
> > libraries.
> 
> On the topic of what would be acceptable for an FFI, wouldn't something
> akin to what's done for modules be sufficient ?  I.e., have the users of
> the interface explicitly state that they are compliant.
> 
> It would scale better than an allow-list.  IIUC, Arthur mentioned this
> in another thread.  If this wouldn't be sufficient for an FFI, could you
> please elaborate on why that's the case ?

What exactly are you suggesting?  IOW, please describe what you have
in mind in more detail, because I don't think I understand it.

> The question here isn't about what does or does not constitute GPL
> compliance, but what Emacs, as a project, is trying to ensure when it
> comes to such compliance.

It tries to ensure that Emacs is not used as front-end for non-free
software.

Re: as for Calc and the math library

[Suhail Singh]

Eli Zaretskii <eliz@gnu.org> writes:

>> On the topic of what would be acceptable for an FFI, wouldn't something
>> akin to what's done for modules be sufficient ?  I.e., have the users of
>> the interface explicitly state that they are compliant.
>> 
>> It would scale better than an allow-list.  IIUC, Arthur mentioned this
>> in another thread.  If this wouldn't be sufficient for an FFI, could you
>> please elaborate on why that's the case ?
>
> What exactly are you suggesting?  IOW, please describe what you have
> in mind in more detail, because I don't think I understand it.

Specifically, modify the `define-ffi-library' macro that emacs-ffi
provides.

Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
that it be updated to take three arguments: a SYMBOL, a NAME and a
GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
a reference to the library.

If the value of `t' would be insufficient for Emacs' standards for
encouraging GPL compliance (in case it's considered "not explicit
enough"), the third argument could instead be something like
GPL-COMPATIBILITY where the value of 'library-is-GPL-compatible would be
necessary to be able to create a reference to the library.

A further variant/extension of the above proposal is also possible.
This extension modifies both `define-ffi-library' as well as
`define-ffi-function'.  When `define-ffi-library' gets an acceptable
claim of GPL compatibility, it attaches a property (which acts as a
witness for observing the claim of GPL compatibility) to the library
symbol.  The presence of said property is then checked by
`define-ffi-function'.  If the property is missing,
`define-ffi-function' complains.

-- 
Suhail

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Suhail Singh <suhailsingh247@gmail.com>
> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>  nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 11:08:02 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> On the topic of what would be acceptable for an FFI, wouldn't something
> >> akin to what's done for modules be sufficient ?  I.e., have the users of
> >> the interface explicitly state that they are compliant.
> >> 
> >> It would scale better than an allow-list.  IIUC, Arthur mentioned this
> >> in another thread.  If this wouldn't be sufficient for an FFI, could you
> >> please elaborate on why that's the case ?
> >
> > What exactly are you suggesting?  IOW, please describe what you have
> > in mind in more detail, because I don't think I understand it.
> 
> Specifically, modify the `define-ffi-library' macro that emacs-ffi
> provides.
> 
> Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
> that it be updated to take three arguments: a SYMBOL, a NAME and a
> GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
> a reference to the library.

And if the value is not t, then the load will fail?  If so, then this
additional argument makes very little sense: you could instead say
that just by loading the library, the Lisp program which uses
emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
are back where we began.

The way we do it when loading modules requires the _loaded_ library to
declare itself compatible, by exporting a symbol of a certain name.
That is an action by the library we load, not by the Lisp program
which loads it.

Re: as for Calc and the math library

[Suhail Singh]

Eli Zaretskii <eliz@gnu.org> writes:

> The way we do it when loading modules requires the _loaded_ library to
> declare itself compatible, by exporting a symbol of a certain name.
> That is an action by the library we load, not by the Lisp program
> which loads it.

Thank you for elaborating. In the context of Emacs, having a claim of
GPL compatibility is not sufficient; it also matters who is making such
a claim and asserting compliance with the license terms.

IIUC, the claim has to be made either by the library itself (the case of
modules), or by the Emacs maintainers (the case of an allow-list).
However, a claim made by the user (or a repackager) of a library is
insufficient.  Is my understanding correct?

To test my understanding of the above, as a counterfactual, if there was
a standardized way by which libraries identified their license (perhaps
by exporting a pre-determined symbol containing something like an SPDX
license identifier), that too would have been acceptable as long as
emacs-ffi checked against an allow-list of compatible-with-GPL-licenses.
Is that correct?

-- 
Suhail

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Suhail Singh <suhailsingh247@gmail.com>
> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 12:00:35 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The way we do it when loading modules requires the _loaded_ library to
> > declare itself compatible, by exporting a symbol of a certain name.
> > That is an action by the library we load, not by the Lisp program
> > which loads it.
> 
> Thank you for elaborating. In the context of Emacs, having a claim of
> GPL compatibility is not sufficient; it also matters who is making such
> a claim and asserting compliance with the license terms.
> 
> IIUC, the claim has to be made either by the library itself (the case of
> modules), or by the Emacs maintainers (the case of an allow-list).
> However, a claim made by the user (or a repackager) of a library is
> insufficient.  Is my understanding correct?

Yes.

> To test my understanding of the above, as a counterfactual, if there was
> a standardized way by which libraries identified their license (perhaps
> by exporting a pre-determined symbol containing something like an SPDX
> license identifier), that too would have been acceptable as long as
> emacs-ffi checked against an allow-list of compatible-with-GPL-licenses.
> Is that correct?

Yes, I think so.

Re: as for Calc and the math library

[Emanuel Berg]

> IIUC

We cannot have ... because.

Simple functions: those are trivial, and amount to just
a bunch of 3-4 lines of Elisp each anyway; they
add complexity.

Advanced functions: they belong to proprietary and otherwise
incompatible libraries; they are too complex to write.

-- 
underground experts united
https://dataswamp.org/~incal

Sv: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 4461 bytes --]

> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > >> On the topic of what would be acceptable for an FFI, wouldn't something
> > >> akin to what's done for modules be sufficient ?  I.e., have the users of
> > >> the interface explicitly state that they are compliant.
> > >>
> > >> It would scale better than an allow-list.  IIUC, Arthur mentioned this
> > >> in another thread.  If this wouldn't be sufficient for an FFI, could you
> > >> please elaborate on why that's the case ?
> > >
> > > What exactly are you suggesting?  IOW, please describe what you have
> > > in mind in more detail, because I don't think I understand it.
> >
> > Specifically, modify the `define-ffi-library' macro that emacs-ffi
> > provides.
> >
> > Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
> > that it be updated to take three arguments: a SYMBOL, a NAME and a
> > GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
> > a reference to the library.
>
> And if the value is not t, then the load will fail?  If so, then this
> additional argument makes very little sense: you could instead say

It makes as much sense as it makes in C library. The token is basically an
agreement between Emacs developers and the user not to load (link) closed
source libraries into Emacs.

> that just by loading the library, the Lisp program which uses
> emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
> are back where we began.

Yes, you could. It would just completely remove the barrier. However,
the token is an explicit acknowledgment of Emacs policy and license terms, by
the person who loads the library into Emacs.

> The way we do it when loading modules requires the _loaded_ library to
> declare itself compatible, by exporting a symbol of a certain name.
> That is an action by the library we load, not by the Lisp program
> which loads it.

True. But as you said yourself, a malicious user can easily cicrumvent it, even
in C and there is nothing we can do to prevent them other than possibly taking
legal actions against them.

If some company or a state would use Emacs or any other GNU program, as a
front-end to closed-source software, there is very little one can do
technically. It is only the license and the agreement that actually protects it.
________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 14 augusti 2024 17:31
Till: Suhail Singh <suhailsingh247@gmail.com>
Kopia: gerd.moellmann@gmail.com <gerd.moellmann@gmail.com>; nicolas@n16f.net <nicolas@n16f.net>; arthur.miller@live.com <arthur.miller@live.com>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library

> From: Suhail Singh <suhailsingh247@gmail.com>
> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>  nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 11:08:02 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> On the topic of what would be acceptable for an FFI, wouldn't something
> >> akin to what's done for modules be sufficient ?  I.e., have the users of
> >> the interface explicitly state that they are compliant.
> >>
> >> It would scale better than an allow-list.  IIUC, Arthur mentioned this
> >> in another thread.  If this wouldn't be sufficient for an FFI, could you
> >> please elaborate on why that's the case ?
> >
> > What exactly are you suggesting?  IOW, please describe what you have
> > in mind in more detail, because I don't think I understand it.
>
> Specifically, modify the `define-ffi-library' macro that emacs-ffi
> provides.
>
> Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
> that it be updated to take three arguments: a SYMBOL, a NAME and a
> GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
> a reference to the library.

And if the value is not t, then the load will fail?  If so, then this
additional argument makes very little sense: you could instead say
that just by loading the library, the Lisp program which uses
emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
are back where we began.

The way we do it when loading modules requires the _loaded_ library to
declare itself compatible, by exporting a symbol of a certain name.
That is an action by the library we load, not by the Lisp program
which loads it.

[-- Attachment #2: Type: text/html, Size: 10787 bytes --]

Re: as for Calc and the math library

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "gerd.moellmann@gmail.com" <gerd.moellmann@gmail.com>, "nicolas@n16f.net"
> 	<nicolas@n16f.net>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 15 Aug 2024 05:00:06 +0000
> 
> > > Specifically, modify the `define-ffi-library' macro that emacs-ffi
> > > provides.
> > >
> > > Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
> > > that it be updated to take three arguments: a SYMBOL, a NAME and a
> > > GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
> > > a reference to the library.
> >
> > And if the value is not t, then the load will fail?  If so, then this
> > additional argument makes very little sense: you could instead say
> 
> It makes as much sense as it makes in C library. The token is basically an
> agreement between Emacs developers and the user not to load (link) closed
> source libraries into Emacs.

No.  What we need is the declaration _by_the_library_ being loaded
that it complies.  It is not an agreement between Emacs and the
library, it's a _requirement_ on our part that only the library itself
can fulfill.

> > that just by loading the library, the Lisp program which uses
> > emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
> > are back where we began.
> 
> Yes, you could. It would just completely remove the barrier. However,
> the token is an explicit acknowledgment of Emacs policy and license terms, by
> the person who loads the library into Emacs.

No, see above.

> > The way we do it when loading modules requires the _loaded_ library to
> > declare itself compatible, by exporting a symbol of a certain name.
> > That is an action by the library we load, not by the Lisp program
> > which loads it.
> 
> True. But as you said yourself, a malicious user can easily cicrumvent it, even
> in C and there is nothing we can do to prevent them other than possibly taking
> legal actions against them.

Malicious agents can do all kinds of bad and even unlawful things, but
we are not under any obligations to cater to them.  They can always
change the Emacs source code to do whatever they like, but why do you
expect _us_ to do it for them, or make it easier for them to do it?

> If some company or a state would use Emacs or any other GNU program, as a
> front-end to closed-source software, there is very little one can do
> technically. It is only the license and the agreement that actually protects it.

That's a separate issue, although it could be related.  What is at
stake here is the fact that we don't want to encourage use of Emacs as
such a front-end.  That policy of the project is not new, it has many
different expressions, as already mentioned in this thread.  We don't
mention non-free software or fonts in our documentation, we don't
install changes that specifically favor or are designed to support
non-free programs, we don't link against non-free libraries except if
they are system libraries, we don't install functionality enhancements
on non-free systems if there's no equivalent on free systems, etc.
etc.  So I wonder what is this particular fuss all about.  Its
only effect is to waste maintainers' time and energy on replying to
these posts, and I very much doubt this was the intent.  So could we
please stop this Nth instance of the same discussions?  I cannot
change the project policies even if I wanted, because I promised to
uphold them when Richard nominated me.

Sv: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 9547 bytes --]

>> > > Specifically, modify the `define-ffi-library' macro that emacs-ffi
>> > > provides.
>> > >
>> > > Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
>> > > that it be updated to take three arguments: a SYMBOL, a NAME and a
>> > > GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
>> > > a reference to the library.
>> >
>> > And if the value is not t, then the load will fail?  If so, then this
>> > additional argument makes very little sense: you could instead say
>>
>> It makes as much sense as it makes in C library. The token is basically an
>> agreement between Emacs developers and the user not to load (link) closed
>> source libraries into Emacs.
>
>No.  What we need is the declaration _by_the_library_ being loaded
>that it complies.  It is not an agreement between Emacs and the
>library, it's a _requirement_ on our part that only the library itself
>can fulfill.

I have seen your previous answers to others, and I do understand the point you
make, but I think the argument fails because a module can be just a proxy to a
non-free library. If I can put it in other words, I wonder if it is a "false
sense of security", because it is a guarantee by the person who writes the C
module, not the 3rd party library they link to. Of course they are violating the
license if they link to a non-free library, but that we are agreeing about we
can't prevent.

>> > that just by loading the library, the Lisp program which uses
>> > emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
>> > are back where we began.
>>
>> Yes, you could. It would just completely remove the barrier. However,
>> the token is an explicit acknowledgment of Emacs policy and license terms, by
>> the person who loads the library into Emacs.
>
>No, see above.
>
>> > The way we do it when loading modules requires the _loaded_ library to
>> > declare itself compatible, by exporting a symbol of a certain name.
>> > That is an action by the library we load, not by the Lisp program
>> > which loads it.
>>
>> True. But as you said yourself, a malicious user can easily cicrumvent it,
>> even
>> in C and there is nothing we can do to prevent them other than possibly taking
>> legal actions against them.
>
>Malicious agents can do all kinds of bad and even unlawful things, but
>we are not under any obligations to cater to them.  They can always
>change the Emacs source code to do whatever they like, but why do you

Exactly.

>expect _us_ to do it for them, or make it easier for them to do it?

No, of course I don't expect that from you. My point was (is?) that it is a
trade-off between convinience for Emacs users who would use it as intendended,
only with free software, vs the inconvience it causes.

If you look at some other projects which are more interesting than Emacs to use
as front-ends for non-free software, do we see influx of companies misusing
them? I am thinking of Gtk, KDE/Gnome libs and Libre/OpenOffice for example. All
of those projects could be used to plug-in proprietary software, yet, there are
not so many cases, if any? Even Qt which comes as a dual licensed does not seem
to be misused that way. Perhaps I am just uninformed?

You have mentioned llvm, but I am not familiar enough with them. As I understand
they are financied by Apple, Nvidia and few other big tech companies with
explicit goal to have an alternative to GCC just for the more permissive
licensing.

>> If some company or a state would use Emacs or any other GNU program, as a
>> front-end to closed-source software, there is very little one can do
>> technically. It is only the license and the agreement that actually protects
>> it.
>
>That's a separate issue, although it could be related.  What is at
>stake here is the fact that we don't want to encourage use of Emacs as
>such a front-end.  That policy of the project is not new, it has many
>different expressions, as already mentioned in this thread.  We don't
>mention non-free software or fonts in our documentation, we don't
>install changes that specifically favor or are designed to support
>non-free programs, we don't link against non-free libraries except if
>they are system libraries, we don't install functionality enhancements
>on non-free systems if there's no equivalent on free systems, etc.
>etc.  So I wonder what is this particular fuss all about.  Its

I said it in the beginning: sometimes it is useful to revisit policies
when circumstancies have changed.

>only effect is to waste maintainers' time and energy on replying to
>these posts, and I very much doubt this was the intent.  So could we

Have I ever trolled you before? Why would I want to waste your time and energy?
I am certainly the last person in the world to do that, and you should know that.
I understand it takes time and energy, and I appologize for that, but it is
useful to learn why you consider FFI unnaceptable, and to hear the arguments
from the first hand. For the record: I have never brought up this issue before.

>please stop this Nth instance of the same discussions?  I cannot
>change the project policies even if I wanted, because I promised to
>uphold them when Richard nominated me.

I wouldn't expect you to change policy on your own neither. I did hope for RMS,
you and other experienced developers to perhaps take a look at the history,
perhaps at other software and how Emacs development could be, and reflect over
the policy if it is still worth keeping or perhaps it can be changed.
________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 15 augusti 2024 09:02
Till: arthur miller <arthur.miller@live.com>
Kopia: suhailsingh247@gmail.com <suhailsingh247@gmail.com>; gerd.moellmann@gmail.com <gerd.moellmann@gmail.com>; nicolas@n16f.net <nicolas@n16f.net>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library

> From: arthur miller <arthur.miller@live.com>
> CC: "gerd.moellmann@gmail.com" <gerd.moellmann@gmail.com>, "nicolas@n16f.net"
>        <nicolas@n16f.net>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 15 Aug 2024 05:00:06 +0000
>
> > > Specifically, modify the `define-ffi-library' macro that emacs-ffi
> > > provides.
> > >
> > > Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
> > > that it be updated to take three arguments: a SYMBOL, a NAME and a
> > > GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
> > > a reference to the library.
> >
> > And if the value is not t, then the load will fail?  If so, then this
> > additional argument makes very little sense: you could instead say
>
> It makes as much sense as it makes in C library. The token is basically an
> agreement between Emacs developers and the user not to load (link) closed
> source libraries into Emacs.

No.  What we need is the declaration _by_the_library_ being loaded
that it complies.  It is not an agreement between Emacs and the
library, it's a _requirement_ on our part that only the library itself
can fulfill.

> > that just by loading the library, the Lisp program which uses
> > emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
> > are back where we began.
>
> Yes, you could. It would just completely remove the barrier. However,
> the token is an explicit acknowledgment of Emacs policy and license terms, by
> the person who loads the library into Emacs.

No, see above.

> > The way we do it when loading modules requires the _loaded_ library to
> > declare itself compatible, by exporting a symbol of a certain name.
> > That is an action by the library we load, not by the Lisp program
> > which loads it.
>
> True. But as you said yourself, a malicious user can easily cicrumvent it, even
> in C and there is nothing we can do to prevent them other than possibly taking
> legal actions against them.

Malicious agents can do all kinds of bad and even unlawful things, but
we are not under any obligations to cater to them.  They can always
change the Emacs source code to do whatever they like, but why do you
expect _us_ to do it for them, or make it easier for them to do it?

> If some company or a state would use Emacs or any other GNU program, as a
> front-end to closed-source software, there is very little one can do
> technically. It is only the license and the agreement that actually protects it.

That's a separate issue, although it could be related.  What is at
stake here is the fact that we don't want to encourage use of Emacs as
such a front-end.  That policy of the project is not new, it has many
different expressions, as already mentioned in this thread.  We don't
mention non-free software or fonts in our documentation, we don't
install changes that specifically favor or are designed to support
non-free programs, we don't link against non-free libraries except if
they are system libraries, we don't install functionality enhancements
on non-free systems if there's no equivalent on free systems, etc.
etc.  So I wonder what is this particular fuss all about.  Its
only effect is to waste maintainers' time and energy on replying to
these posts, and I very much doubt this was the intent.  So could we
please stop this Nth instance of the same discussions?  I cannot
change the project policies even if I wanted, because I promised to
uphold them when Richard nominated me.

[-- Attachment #2: Type: text/html, Size: 22892 bytes --]

Re: as for Calc and the math library

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "suhailsingh247@gmail.com" <suhailsingh247@gmail.com>,
> 	"gerd.moellmann@gmail.com" <gerd.moellmann@gmail.com>, "nicolas@n16f.net"
> 	<nicolas@n16f.net>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 15 Aug 2024 20:09:56 +0000
> 
> >No.  What we need is the declaration _by_the_library_ being loaded
> >that it complies.  It is not an agreement between Emacs and the
> >library, it's a _requirement_ on our part that only the library itself
> >can fulfill.
> 
> I have seen your previous answers to others, and I do understand the point you
> make, but I think the argument fails because a module can be just a proxy to a
> non-free library.

A module that declares GPL compatibility and loads non-free library is
either lying or (if the library is distributed with the module, as I'd
expect) in clear violation of the GPL.

> >expect _us_ to do it for them, or make it easier for them to do it?
> 
> No, of course I don't expect that from you. My point was (is?) that it is a
> trade-off between convinience for Emacs users who would use it as intendended,
> only with free software, vs the inconvience it causes.

Yes, it's a trade-off.  The GNU Project decided where to take this
trade-off, and I promised to uphold that policy.  So can we please
stop this futile discussion, which just went one more circle?

> If you look at some other projects which are more interesting than Emacs to use
> as front-ends for non-free software, do we see influx of companies misusing
> them? I am thinking of Gtk, KDE/Gnome libs and Libre/OpenOffice for example. All
> of those projects could be used to plug-in proprietary software, yet, there are
> not so many cases, if any? Even Qt which comes as a dual licensed does not seem
> to be misused that way. Perhaps I am just uninformed?
> 
> You have mentioned llvm, but I am not familiar enough with them. As I understand
> they are financied by Apple, Nvidia and few other big tech companies with
> explicit goal to have an alternative to GCC just for the more permissive
> licensing.

Once again, please take these off-topic discussions elsewhere.

> I said it in the beginning: sometimes it is useful to revisit policies
> when circumstancies have changed.

You are talking to the wrong guy about revisiting policies.  As
already explained more than once.

Re: as for Calc and the math library

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >No.  What we need is the declaration _by_the_library_ being loaded
  > >that it complies.  It is not an agreement between Emacs and the
  > >library, it's a _requirement_ on our part that only the library itself
  > >can fulfill.

  > I have seen your previous answers to others, and I do understand
  > the point you make, but I think the argument fails because a
  > module can be just a proxy to a non-free library. If I can put it
  > in other words, I wonder if it is a "false sense of security",
  > because it is a guarantee by the person who writes the C module,
  > not the 3rd party library they link to. Of course they are
  > violating the license if they link to a non-free library, but that
  > we are agreeing about we can't prevent.

You're right, and this is a possible problem, but it raises a real
copyleft compliance issue only in a specific kind of occasion: when
someone writes such an intermediary module that loads a nonfree
library, _and distributes that intermediary module_ for such use.

Just writing such an intermediary module and using it oneself does not
raise a copyleft compliance issue, because GPLv3 says one can make any
sort of modificatoin and use it privately -- even actually copying in
nonfree code.  Where the copyleft requirement comes into pkay is for
making a modified version and distributing it to others.

So it could be good to keep an eye on the modules that people are
releasing, to make sure they do not load in other nonfree code.
If they do, the FSF should tell their distributors to stop.

Given this situation, a spcial label as a flag for "this library is
free" might be useful, We just have to remember taht such a flag label
is not proof of anything.  Its presence is only a statement (which can
be false) of intent that the module be entirely GPL3-compatible free
code and that it link in only GPL3-compatible other modules.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

as for Calc and the math library

[Christopher Dimech]

> Sent: Monday, August 19, 2024 at 4:38 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "arthur miller" <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Subject: Re: as for Calc and the math library
>
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >No.  What we need is the declaration _by_the_library_ being loaded
>   > >that it complies.  It is not an agreement between Emacs and the
>   > >library, it's a _requirement_ on our part that only the library itself
>   > >can fulfill.
>
>   > I have seen your previous answers to others, and I do understand
>   > the point you make, but I think the argument fails because a
>   > module can be just a proxy to a non-free library. If I can put it
>   > in other words, I wonder if it is a "false sense of security",
>   > because it is a guarantee by the person who writes the C module,
>   > not the 3rd party library they link to. Of course they are
>   > violating the license if they link to a non-free library, but that
>   > we are agreeing about we can't prevent.
>
> You're right, and this is a possible problem, but it raises a real
> copyleft compliance issue only in a specific kind of occasion: when
> someone writes such an intermediary module that loads a nonfree
> library, _and distributes that intermediary module_ for such use.
>
> Just writing such an intermediary module and using it oneself does not
> raise a copyleft compliance issue, because GPLv3 says one can make any
> sort of modificatoin and use it privately -- even actually copying in
> nonfree code.  Where the copyleft requirement comes into pkay is for
> making a modified version and distributing it to others.
>
> So it could be good to keep an eye on the modules that people are
> releasing, to make sure they do not load in other nonfree code.
> If they do, the FSF should tell their distributors to stop.
>
> Given this situation, a spcial label as a flag for "this library is
> free" might be useful, We just have to remember taht such a flag label
> is not proof of anything.  Its presence is only a statement (which can
> be false) of intent that the module be entirely GPL3-compatible free
> code and that it link in only GPL3-compatible other modules.

Emacs could recommend and endorse specific libraries without judging or
comparing them based on any criterion other than freedom.  As is done
with the Free GNU/Linux Distributions.  Emacs itself could report a
flag when someone uses such libraries, rather than having the libraries
themselves report the information to the editor.  However GPL Compliance
would be too restrictive.  Knowing a library is free should be enough.
This way users would know what they are doing without harm.

Sv: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 9075 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >No.  What we need is the declaration _by_the_library_ being loaded
>   > >that it complies.  It is not an agreement between Emacs and the
>   > >library, it's a _requirement_ on our part that only the library itself
>   > >can fulfill.
>
>   > I have seen your previous answers to others, and I do understand
>   > the point you make, but I think the argument fails because a
>   > module can be just a proxy to a non-free library. If I can put it
>   > in other words, I wonder if it is a "false sense of security",
>   > because it is a guarantee by the person who writes the C module,
>   > not the 3rd party library they link to. Of course they are
>   > violating the license if they link to a non-free library, but that
>   > we are agreeing about we can't prevent.
>
> You're right, and this is a possible problem, but it raises a real
> copyleft compliance issue only in a specific kind of occasion: when
> someone writes such an intermediary module that loads a nonfree
> library, _and distributes that intermediary module_ for such use.
>
> Just writing such an intermediary module and using it oneself does not
> raise a copyleft compliance issue, because GPLv3 says one can make any
> sort of modificatoin and use it privately -- even actually copying in
> nonfree code.  Where the copyleft requirement comes into pkay is for
> making a modified version and distributing it to others.

Hi, and thank you very much for the clarification RMS. I saw you previous post
saying this also. I think it is useful to remind people that the GPL is about
the distribution and the rights to distribute the changed code not so much about
using the code (I think, I hope I am not sailing out of the clear water here).

> So it could be good to keep an eye on the modules that people are
> releasing, to make sure they do not load in other nonfree code.
> If they do, the FSF should tell their distributors to stop.

Yes, and this perhaps the only thing we can do, since technically it is very
easy to circumwent the license.

> Given this situation, a spcial label as a flag for "this library is
> free" might be useful, We just have to remember taht such a flag label
> is not proof of anything.  Its presence is only a statement (which can
> be false) of intent that the module be entirely GPL3-compatible free
> code and that it link in only GPL3-compatible other modules.

Indeed. I don't know how realisict, technically and resource-wise it would be to
use Elpa as a place to distribute modules and to have each library in Elpa
"signed" or "approved" by someone FSF-trusted who could ensure the GPL license
is not violated. The problem I see is that after the initial review, libraries
are pulled and build automaticly from Git sources, so that would be a constant
process, but perhaps could be automated by a script which checks for presence of
certain system/library calls (dlopen & co) and warns an approved "reviewer" to
take a look at that library? I perhaps also misunderstand how Elpa works since I
am not so familiar with Elpa implementation. Problem with automation is that a
malicious author could, at least in theory, initially commit a perfect library,
and after some time introduce malicious or GPL-incompatible code. I am thinking
of the recent XZ-incident.

Since you have chimmed in, and in the light of your clarifications, may I ask
what do you think of the difference between doing the same thing from the Lisp?
Is there any conceptual difference between loading an external library from a
Lisp library as it is from a C library?

Since you have worked a lot with Lisp(s) in your past, and as I have seen from
the transcripts of the work on the CommonLisp standard, work in which you also
took part, you seem to always been concerned with how easy/difficult constructs
are to use and understand for users. In several contributions you tried to
simplify some constructs, at least as I understand (setf comes to mind for
example, but I don't remember the details at the moment, would have to look up
for the exact reference).

IMO it would be much easier and more convenient for EmacsLisp users and
programmers to use a Lisp interface to work with modules than C. Admittedly it
lowers the technical barrier for violating the GPL license, but that technical
barrier is a hindrance only for very innexperience programmers, who probably
wouldn't be able to use FFI from Lisp neither. As a layman when it comes to
licensing, I don't see the conceptual diffrence between a C library or a Lisp
library when it comes to licensing, and the very same "agreement" that should
uphold between a Lisp library writer, as there is between C library writer and
the GPL code they use.

If you can reflect on the conceptual difference I would be very thankful. I
promised to Eli I won't push for FFI, and I am not doing it either, but I am
interested to learn why it would be different to load a library via Lisp from
loading it from C, more than technical difference of doing it via Lisp is much
easier and convenient. If anyone, you have done lots of work in both Lisp and
C. I think it is very interesting to hear your opinion on the matter.

I hope Eli don't get too angry on me for asking you this, since I understand he
considers this off-topic. I understand it takes time and energy from you, when
we talk about this matters, and I appologize for that. This is also an
opportunity to hear what RMS opinion is and the reason why FFI is bad in
EmacsLisp, if he would be kind to explaing and clarify that one. I am sure I am
not the only one who will find this useful to hear. Perhaps I am just an idiot,
but I am not an enemy, and I don't mean harm as you seem to believe (since you
epressed the concern that I am just trolling to take your time). If you want to
send me the warning, or ban me from this list, so be it.

PS: I hope I didn't sent this twice. In a recent couple of weeks I have a problem with GNUs.
It sometimes works and sometimes not. Several of these mails I had to copy over to a
different client, happend this time, while some went out without problems from Emacs.
________________________________
Från: Richard Stallman <rms@gnu.org>
Skickat: den 18 augusti 2024 18:38
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: as for Calc and the math library

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >No.  What we need is the declaration _by_the_library_ being loaded
  > >that it complies.  It is not an agreement between Emacs and the
  > >library, it's a _requirement_ on our part that only the library itself
  > >can fulfill.

  > I have seen your previous answers to others, and I do understand
  > the point you make, but I think the argument fails because a
  > module can be just a proxy to a non-free library. If I can put it
  > in other words, I wonder if it is a "false sense of security",
  > because it is a guarantee by the person who writes the C module,
  > not the 3rd party library they link to. Of course they are
  > violating the license if they link to a non-free library, but that
  > we are agreeing about we can't prevent.

You're right, and this is a possible problem, but it raises a real
copyleft compliance issue only in a specific kind of occasion: when
someone writes such an intermediary module that loads a nonfree
library, _and distributes that intermediary module_ for such use.

Just writing such an intermediary module and using it oneself does not
raise a copyleft compliance issue, because GPLv3 says one can make any
sort of modificatoin and use it privately -- even actually copying in
nonfree code.  Where the copyleft requirement comes into pkay is for
making a modified version and distributing it to others.

So it could be good to keep an eye on the modules that people are
releasing, to make sure they do not load in other nonfree code.
If they do, the FSF should tell their distributors to stop.

Given this situation, a spcial label as a flag for "this library is
free" might be useful, We just have to remember taht such a flag label
is not proof of anything.  Its presence is only a statement (which can
be false) of intent that the module be entirely GPL3-compatible free
code and that it link in only GPL3-compatible other modules.

--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)



[-- Attachment #2: Type: text/html, Size: 21676 bytes --]

Re: as for Calc and the math library

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > So it could be good to keep an eye on the modules that people are
  > > releasing, to make sure they do not load in other nonfree code.
  > > If they do, the FSF should tell their distributors to stop.

  > Yes, and this perhaps the only thing we can do, since technically it is very
  > easy to circumwent the license.

The crucial preparation for this is to make sure we have effective,
practical control over what modules are being visibly distribued by
others.  that means teachng a substantial part of the community to
understand that this is a kind of deception, and to tell us if they
spot one.

We could also think of some other measures, such as including in Emacs
a list of hash codes of such deceptive modules, and code to refuse
to load them and explain why.

Of course, this would not actually _prevent_ users from loading those
modules.  A user could delete the pertinent item from the list, then
go ahead.  But I expect this would be fairly effective at leading the
community away from doing that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: as for Calc and the math library

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Since you have chimmed in, and in the light of your
  > clarifications, may I ask what do you think of the difference
  > between doing the same thing from the Lisp?  Is there any
  > conceptual difference between loading an external library from a
  > Lisp library as it is from a C library?

In principle, they are the same issue; however, specific details of
the situation might affect the conclusion, and the choice of language
might make a difference to what those details are.  So I can't say
anything more concrete without details (and perhaps consulting a
lawyer).



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: as for Calc and the math library

[Gerd Möllmann]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I guess an FFI is already there? Or was there because it looks kind of
>>> dead:
>>> 
>>>   https://github.com/tromey/emacs-ffi
>>> 
>>> Tom Tromey says in one of the issues
>>> 
>>>   https://github.com/tromey/emacs-ffi/issues/20
>>> 
>>> that John Wigley asked him on IRC to submit it for inclusion. Can't find
>>> anything on emacs-devel though.
>>
>> It doesn't ensure GPL-compliance, AFAICT, so in its current form it
>> cannot be accepted, sorry. And I'm not sure I understand how can one
>> technically enforce GPL compliance in FFI-style loading of arbitrary
>> shared libraries.  The only idea that comes to mind is allow-list of
>> known libraries, the way we do in sqlite.c, but I'm not sure that
>> method is scalable to the basically infinite world of arbitrary
>> libraries.
>
> On the topic of what would be acceptable for an FFI, wouldn't something
> akin to what's done for modules be sufficient ?  I.e., have the users of
> the interface explicitly state that they are compliant.
>
> It would scale better than an allow-list.  IIUC, Arthur mentioned this
> in another thread.  If this wouldn't be sufficient for an FFI, could you
> please elaborate on why that's the case ?

Another question is of course why something like Tom's FFI must be made
part of Emacs when, AFIU, it could be a package like vterm which also
contains an Emacs module.

Re: as for Calc and the math library

[Nicolas Martyanoff]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Another question is of course why something like Tom's FFI must be made
> part of Emacs when, AFIU, it could be a package like vterm which also
> contains an Emacs module.

This is what I had in mind when I suggested a dynamic module using
libffi (apparently exactly what this emacs-ffi does) . I do not see the
point in trying to get this kind of module included in Emacs since it is
obviously not wanted here.

Just distribute it as a package and be done with it. People wanting to
use it will just add it as a dependency.

-- 
Nicolas Martyanoff
https://n16f.net
nicolas@n16f.net

Re: as for Calc and the math library

[Gerd Möllmann]

Nicolas Martyanoff <nicolas@n16f.net> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Another question is of course why something like Tom's FFI must be made
>> part of Emacs when, AFIU, it could be a package like vterm which also
>> contains an Emacs module.
>
> This is what I had in mind when I suggested a dynamic module using
> libffi (apparently exactly what this emacs-ffi does) . I do not see the
> point in trying to get this kind of module included in Emacs since it is
> obviously not wanted here.
>
> Just distribute it as a package and be done with it. People wanting to
> use it will just add it as a dependency.

+1

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: Suhail Singh <suhailsingh247@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>  nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 16:40:41 +0200
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Another question is of course why something like Tom's FFI must be made
> > part of Emacs when, AFIU, it could be a package like vterm which also
> > contains an Emacs module.
> 
> This is what I had in mind when I suggested a dynamic module using
> libffi (apparently exactly what this emacs-ffi does) . I do not see the
> point in trying to get this kind of module included in Emacs since it is
> obviously not wanted here.
> 
> Just distribute it as a package and be done with it. People wanting to
> use it will just add it as a dependency.

Perfectly fine.  Then people who do that will be responsible for
making sure the libraries they load are compatible, license-wise, with
the emacs-ffi module (whose license is not explicitly stated, btw,
AFAICT).

Re: as for Calc and the math library

[Madhu]

* Nicolas Martyanoff <87a5hi0yts.fsf@valhala.localdomain> :
Wrote on Mon, 12 Aug 2024 13:23:27 +0200:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: arthur miller <arthur.miller@live.com>
>>> Date: Mon, 12 Aug 2024 05:30:08 +0000
>>> Even better, given people proper FFI so they can import and use any
>>> of the tens
>>> or hundreds of quality math libraries available.
>>
>> Not going to happen, and you know it.
>
> Naïve question, why? I had this problem not so long ago because I wanted
> to bind libpq, and I had to abandon the whole idea because dealing with
> dynamic modules was way too inconvenient.
>
> Having something similar to Common Lisp FFIs would make it trivial.

There is a workable promising start, with a single lisp module from
Tromey:

https://github.com/tromey/emacs-ffi

I have a clone on gh (user enometh), but I haven't found the time to
polish it up enough to post