lexicons

lexicons

[Richard Stallman]

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

I read the documentation of lexicons, and they seem to solve the
problems that made me dislike CL packages.

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

Re: lexicons

[Stefan Monnier]

> I read the documentation of lexicons, and they seem to solve the
> problems that made me dislike CL packages.

I also prefer the semantics of lexicon over that of CL packages.
But I don't think this would fly for Elisp, because it completely
separates the notion of symbol from the notion of its binding, so things
like (symbol-value 'foo) don't behave like `foo' any more, so it's
a pretty drastic change.

I think what you don't like is this idea of "look around in various
obarrays to find the symbol that is meant".  I tend to agree here: doing
it at compile/run-time (as in the case of lexicons) might be acceptable
(because you can then distinguish definitions from uses), but doing it
at read-time is more problematic, especially when one of the obarrays is
the global one which can hold any kind of random crap thanks to the
myriad of poorly written packages, or because of code copy&pasted from
the web into the user's ~/.emacs.

While some people think that even a 3-letter prefix is completely
unacceptable (I'll let you guess which prefix I'm thinking about),
I tend to think that using prefixes is not that bad, as long as they're
kept short.

But I agree that there's a problem here: we want prefixes in the code to
be short, but namespace cleanliness wants us to use longish prefixes.

So maybe the solution is simply to provide prefix shorthands.
Chose a "prefix char" (there's a good time for bikeshedding here), let's
say | for now.  Then you could define (file-locally):

   prefixes-alist: '(("" "mypackage-") ("gs" "gnus-summary-"))

and then use `|foo' as a shorthand for `mypackage-foo' and `gs|bar' as
a shorthand for `gnus-summary-bar'.

It's still a read-time operation (which means that it will work just
fine with people's bad habits of using ' to quote code and things like
that), but it doesn't suffer from the ambiguity of a search through
various obarrays.

This wouldn't let you "import without a prefix", but it would free
people to use longish prefixes, since you can locally shorten the ones
you care about (a common practice in the SML module system, where you
typically import modules while renaming them to a very short (1 or
2 chars) local name).


        Stefan

Re: lexicons

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So maybe the solution is simply to provide prefix shorthands.
> Chose a "prefix char" (there's a good time for bikeshedding here), let's
> say | for now.  Then you could define (file-locally):
>
>    prefixes-alist: '(("" "mypackage-") ("gs" "gnus-summary-"))
>
> and then use `|foo' as a shorthand for `mypackage-foo' and `gs|bar' as
> a shorthand for `gnus-summary-bar'.

That's a lot less typing and reading, but I feel that having several
ways of denoting the same thing makes reading the code more difficult.

Common Lisp has the concept of package nicknames, so you'll call the
package `something-very-long-indeed', and have a nickname like `si'.  So
you're reading the code, seeing `si:bar', and you have to either know
what it's a nickname for, or look it up at the package definition.  And
when you get a backtrace, it'll talk about
`something-very-long-indeed:bar', which doesn't match up with the code
you're reading.  So I've stopped using package nicknames in Common Lisp.

I think the prefix concept may have the same problem.

(And we'd have to extend etags etc to parse this stuff, but that's
perhaps a minor issue.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: lexicons

[Stefan Monnier]

> I think the prefix concept may have the same problem.

Yes, it's inherent to the idea of letting people use shorter names for
"local" entities, I think.  So you're basically arguing against providing
any kind of namespace/module/package support.

Obviously, the status quo has the advantage that it works with current
tools (including grep), whereas any change would break some of
those uses.


        Stefan

Re: lexicons

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I think the prefix concept may have the same problem.
>
> Yes, it's inherent to the idea of letting people use shorter names for
> "local" entities, I think.  So you're basically arguing against providing
> any kind of namespace/module/package support.

I think packages are useful, but they also have their problems.

When writing Common Lisp, I'm glad that I don't have to read and write
foo:bar constantly, but I'm annoyed that I can't call my logging
function in foo for `log', because that's a reserved word from the CL
package.  (Your namespace suggestion doesn't have this problem, though.)

When writing Emacs Lisp, I'm annoyed that I'm typing `gnus-summary-foo'
all the time, but I'm happy that grep reliably finds all code that calls
`gnus-summary-foo', and that when I'm reading code, I know immediately
what function that's being called, context-free.

So...  er...  yes.  I think I am arguing against any kind of namespace
support.  >"?  

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php

Re: lexicons

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

Lars Magne Ingebrigtsen [2013-08-01 23:57:24 +02:00] wrote:

> When writing Common Lisp, I'm glad that I don't have to read and write
> foo:bar constantly, but I'm annoyed that I can't call my logging
> function in foo for `log', because that's a reserved word from the CL
> package.

In Common Lisp you can control the symbols in your own packages. For the
annoyance:

    (shadow 'log)

or

    (defpackage :my-package
      (:use :cl)
      (:shadow :log))

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: lexicons

[Lars Brinkhoff]

Lars Magne Ingebrigtsen wrote:
> When writing Common Lisp [...] I'm annoyed that I can't call my
> logging function in foo for `log', because that's a reserved word
> from the CL package.

That's not exctly true, because you could shadow the log symbol in
your own package.  And if necessary refer to the original symbol using
cl:log.  But you probably knew all this.

Re: lexicons

[Lars Magne Ingebrigtsen]

Lars Brinkhoff <lars@nocrew.org> writes:

> That's not exctly true, because you could shadow the log symbol in
> your own package.  And if necessary refer to the original symbol using
> cl:log.  But you probably knew all this.

You could, but you can't.  Then people who are reading your code won't
know what you're doing.  It's like overloading + in C++.  You could, but
you really really can't.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php

Re: lexicons

[Bastien]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> When writing Emacs Lisp, I'm annoyed that I'm typing `gnus-summary-foo'
> all the time, but I'm happy that grep reliably finds all code that calls
> `gnus-summary-foo', and that when I'm reading code, I know immediately
> what function that's being called, context-free.

Exactly my point.  Except that I'm not *that* annoyed to type long
names.  (I mean, are you all seriously annoyed by this?)

With less readable context-free names, a non-CS-educated guy like me
would never have groked the basics of Emacs Lisp writing.

Oh wait!  Maybe that's an argument _for_ namespaces ;)

-- 
 Bastien

Re: lexicons

[Stefan Monnier]

> ... a non-CS-educated guy like me ...

Kind of late, but thanks for letting us know.  I've just revoked your
write access to the repository for the obvious safety reasons,


        Stefan "better late than never"