[Top][All Lists]

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

Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorth

From: Tomas Hlavaty
Subject: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)
Date: Thu, 30 Sep 2021 16:26:59 +0200

On Thu 30 Sep 2021 at 14:26, João Távora <joaotavora@gmail.com> wrote:
> On Thu, Sep 30, 2021 at 2:00 PM Tomas Hlavaty <tom@logand.com> wrote:
>> On Thu 30 Sep 2021 at 13:41, João Távora <joaotavora@gmail.com> wrote:
>> > On Thu, Sep 30, 2021, 12:46 Gregory Heytings <gregory@heytings.org> wrote:
>> >> > but it's the wrong tool.
>> >> And what is/what are the "right" tool(s) for the above use case?
>> > In contrast, in some common lisp IDEs you have such tools and expose this
>> > database. Xref in Emacs was originally derived from work of a Common Lisp
>> > programmer, which created the amazing SLIME, which you may have heard of.
>> > SLIME (and my fork of it Sly) are indeed able to use these databases.
>> >
>> > André's comment is very accurate. In SLIME, one eats Lisp with a spoon, not
>> > a fork.
>> Except it does not remove the need for grep.
>> It misses a lot of things, you cannot rely on it completely.
>> It needs the lisp code loaded and compiled sucessfully.
> No, you're able to build such a tool that merely needs to Lisp code to be

That does not work.  Common Lisp reader is programable.  If you do not
compile and load everything needed sucessfully, the reader will fail for
anything non-trivial.

> You're supposed to have it loaded in your image while you develop it.

You can restrict yourself like that but why do you think that it is a
reasonable restriction for everybody?

I likely search for things not loaded in my image more often than for
things already loaded in my image.

Which image btw?  The one with or without threads, the one with or
without unicode, the normal one or the one with more debuging support
turned on, the one with sbcl or ccl or ecl or clisp...?

> It's not like C where you do something and have to recompile the whole
> thing.

It really depends on what you change.  Sometimes it is necessary to
recompile the whole thing even in Common Lisp.  For example: If you
change a macro, you need to recompile all places where it is used.  If
you change an inlined function, you need to recompile all places where
it is used.

> And grep fails very horribly in Common Lisp as you well know, if
> you include the package qualifier.

That's why good programmers make effort to choose good names independent
of language.

Lots of Common Lisp code is awful because people play clever tricks with
names and packages, symbol import, export, shadowing.

reply via email to

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