Re: support for pre-C99 compilers

Sam Steingold <[email protected]>
Newsgroups gmane.lisp.clisp.devel
Message-ID <[email protected]>
> * Bruno Haible <[email protected]> [2017-10-20 01:28:20 +0200]:
>
> Sam wrote:
>> > removing 'varbrace' does not have a significant benefit.
>>
>> The huge benefit is that C files will look like normal C.
>
> This would not be a benefit. It would be a drawback.

People are put off by the weird *.d extension (which falsely hints in
the direction of the D language).
People are put off by the gratuitous syntax modifications.
People keep telling you that and you are ignoring them.

> During development, it is important to see all local variable
> declarations, in an easy way.

Yep - just like all the other syntax highlighting.

> With plain C syntax, neither Emacs nor kate can do this.

I have never used kate/pico/nano/axe/...
Emacs & VIM handle C syntax highlighting just fine
(and MultiEdit did 25 years ago).
Even the extra CLISP types are handled with the clisp/emacs/d-mode.el
and clisp/emacs/d.vim extensions (and, before you ask, if we move to
*.c from *.d, it would be _easier_ to handle them).

> Most probably, because the C syntax is a bit ambiguous.

C syntax is trash, but Emacs & VIM handle it just fine.

> Whereas with 'var' syntax, editors can do this (see attached screenshot).

I removed those "var" markers in Emacs and created a screenshot.
Enjoy.



> For this reason, plain C syntax without 'var' is inferior. Even if
> many people use it.

Whether addition of "var" to C syntax improves it is debatable.
I do not have a strong opinion about it.

However, changing a syntax of code written in a 50yo widely used
language is certainly a very bad idea.
This scares off potential contributors.
Just like with the gratuitous minor deviations from the ANSI CL standard
and the conventional Lisp paren placement, we are sending the message
that "we think we are smarter than everyone else around, we don't care
about what most people think" (note that this is exactly the Emacs
attitude that you despise so much).
The part about "smarter than everyone else around" might actually be
true about you personally, but screaming this into the faces of
potential contributors is counterproductive.

>> Removing varbrace and comment5 (what does "5" stand for, btw?) is just
>> as important for CLISP as making cua-mode the default for Emacs. ;-)
>
> You can remove comment5, if you or someone else converts the comments
> in the remeining files (mostly lisparit.d and its include files) in a
> sensible way - not in a cheap automated way.
>
> I now prefer to write
>   #if 0
>    #define foo bar
>   #endif
> over
>   # define foo bar

I prefer

/* #define foo bar */

or

// #define foo bar

as either takes less screen real estate.

> And comments are well highlighted in today's editors (because the C
> commment syntax is unambiguous).

A kate or pico or nano user has no right to speak about "today's
editors". ;-)
You sound like a pedestrian commenting about car capabilities.
I hope the above does not sound rude, I did not intend to pull a Linus
on you ;-)

However, the point remains: CLISP sources have a scary appearance for no
good reason, as have been pointed out by many people over many years.
This barrier to entry exists should go.

Thanks.

--
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://think-israel.org http://islamexposedonline.com http://memri.org
XML is like violence. If it doesn't solve the problem, use more.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel
spvw.d.png (image/png, 270.7 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.