emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs contributions, C and Lisp


From: Óscar Fuentes
Subject: Re: Emacs contributions, C and Lisp
Date: Sat, 01 Mar 2014 20:03:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> > It is already implemented.
>> 
>> This is false, as acknowledged by the C++/CEDET developer himself and
>> easily testable with a few lines of code.
>
> What was acknowledged was that CEDET does not implement the full C++
> standard, that's all.

Actually, it doesn't implement the C++ language as it was used in the
mid 1980s, much less so the old 1998 standard. But that was already
stated multiple times, to no avail.

> It remains to be seen how important that is to
> the Emacs users at large; obviously, CEDET developers didn't think
> what they had was useless.

CEDET is much more than a C++ parser. Regardless the value of its C++
parser, CEDET remains useful. CEDET can use Clang (and it already has
some support for it, AFAIK) for the C++ analysis and then bring in the
associated features into Emacs.

You seem to think that, by using Clang, CEDET is no longer necessary,
when the contrary is the truth: by using Clang, CEDET gets a solid
ground for exploiting its own potential.

> Your needs are not the only ones, and not necessarily representative
> of those of others.

Making an strawman does not help to the discussion.

>> We don't need the backend, but we need all the other big parts. In the
>> case of Clang, that's probably more than 70% of its source code (the
>> backend is provided by LLVM, which is a segregated code base.)
>
> Because Clang was designed and implemented as a compiler, first and
> foremost, and not as a CEDET backend.

You are showing your ignorance here. You can go to clang.llvm.org and
see by yourself, on the front page, that you are wrong, but I guess that
you wont to.

>From day 1, Clang aimed at modularization, with each component providing
a convenient API for the benefit of external clients.

Just in passing I'll mention that that was one of the main motivations
for creating Clang. Some of today's Clang heavy contributors would have
preferred to do that modularization on GCC instead of starting from
scratch on a new project, but that was forbidden. Hence Clang is, in
great part, a consequence of the GNU policies intended to avoid GCC
usage by non-free software. Ironic, uh?

> How many times we will need to go through this before you will
> understand that hand-waving and unsubstantiated claims are not
> convincing?

You saw real examples where CEDET failed to handle basic cases, you
ignored advice to ask to the experts, you refused to look at the actual
code that implements the stuff we are talking about, you prefer to judge
on your (evidently) very limited knowledge of C++ than on seeing how
others use it, you wont devote some minutes to learn about how difficult
it is to implement, you pull from nowhere false claims such as "Clang
was designed and implemented as a compiler, first and foremost"...

But yeah, I'm the one who resorts to hand-waving and unsubstantiated
claims.

> These repetitions serve nothing else but discouraging people for
> trying different approaches -- is this really your goal and your
> agenda?

Eli, I sincerely hope that you are not being serious with this. I prefer
to mentally see you right now having a good laugh at my stubborn attemps
to educate you.

Although my real intention is to kill your claim that going with CEDET's
C++ parser makes Clang/GCC unnecesary.

Hopefully other members on this community got the idea that what you
propose is not such a great idea.




reply via email to

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