Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)

[João Távora]

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
CL:READ.  Grep also "reads" the code, but it reads it line by line. OK for
for C (but not always), not so much for Lisp (In Elisp, CL:READ is 'read', btw).

Also, Lisp is developed iteratively.  You're supposed to have it loaded in your
image while you  develop it.  It's not like C where you do something and have to
recompile the whole thing.

Elisp development is no different here.

CL:READ/'read' areboth  aware of packages/shorthands. It can tell you where
the symbol reference lives. That doesn't tell you if its a function, a variable,
a gremlin, etc... of course [*]

But neither does grep.  Grep is light-years away from that.

And grep fails very horribly in Common Lisp as you well know, if
you include the package qualifier.  Since a package qualifier has
loads of nicknames (much like shorthands to be honest. For those
not in the loop, the package qualifier is the equivalent of the prefix
in Emacs lisp.  So, if in Emacs Lisp, you make it easy to grep for
the previ and non-prefix parts of a given name, then bam!, you have
a achieved Common Lisp grep parity! (which isn't much of course,
as André's point still stands intact: it is a fork for soup).

> Slime + Common Lisp are great but not perfect.

Sure!  But they sure beat anything else I've worked with, including Emacs,
which comes second.

I use grep too, by the way.  But I prefer apropos. Again, it knows a
lot more and
has a French name, so it's frankly impossible not to.

I see some people arguing like shorthands have "broken" grep which was some k
ind of omniscient oracle about code analysis. That's so far away from
the truth.  What
would be the point of all these LSP enhancements we're seeing for all
languages if
it were? Of all Static Code Analysis tools being developed?  In Elisp
many constructs
already escape it or break it.  defmethod or defstruct just to name two.

My point is that Lisp has many much better tools -- available today or
waiting to be
created -- because of its List-based structure.  Grep really is a
middle-ages tool
for Lisp.  Lisp looks like it's from the past, but it's actually from
the future ;-)

João

[*] This, by the way, is _another_ reason why reader-based approaches to
namespacing systems are, IMO, better than macro-based ones.