[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Richard Stallman
Subject: Re: Emacs contributions, C and Lisp
Date: Wed, 07 Jan 2015 21:46:14 -0500

[[[ 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. ]]]

  > >   foo.x - bar.y
  > >
  > > it makes no difference for completion what that operator is.

  > In C++, I am afraid you are wrong.  It depends on what types operator+
  > and operator- may be defined for.  If you define operator+ on a
  > half-group, you won't generally have operator- available.

Could you explain how that is so?

If + and - accept different types,
how does that affect completion?

Eli tried to explain

  > In an object-oriented language that supports operator overloading, the
  > + or - can do anything, and accept only specific data types under
  > certain constraints.  For example, if foo.x is of a certain data type,
  > the candidates for the right-hand operand might be restricted to a
  > small subset of what a + or a - can generally support.  If you
  > complete to a large list of candidates here disregarding the
  > constraints, you'd leave a lot of users unhappy.

but he didn't give the substance, so I still don't follow.

I have never used C++.

  > But the plugin interface then needs to be general and convenient enough
  > to get any aspect of it on-demand.  And with regard to enabling
  > undesirable uses of it, I don't see that this buys us significant
  > savings over a non-Emacs specific AST dump.

Are you thinking of this only in terms of the amount of work?
I'm concerned with avoiding dangers.

If you want to convince me generating the whole AST is safe, you have
to understand my concern and take it seriously.  You can't do this by
brushing off the issue.  That will only convince me that you haven't seen
the issue.

Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]