I guess you could fairly easily write a macro that automatically created a lexical scope and added some prefixes to variable used within its body - Doug Hoyte's "Let over lambda" book has #CommonLisp examples of this kind of approach as way to cut down the syntactic overhead of using gensym in macros. Without much thought, I'd assume something similar could be done in #EmacsLisp
@The ol' tealeg 🐡 I'm thinking something a little more robust involving using a symbol's property list to store everything contained within that namespace.
I'm probably biting off more than I can chew at this point in my understanding of elisp, but I'm sure this idea will stick around in my brain until I have enough of an understanding to pull it (or something comparable) off.
...or I find some already existing thing that does what I want (which is more likely).
SBCL, for example, has the in-package macro set the value of the special variable *PACKAGE* which, I guess, would then ultimately get used in every definition and reference.
I haven't having looked at it, but I imagine that it mostly comes down to switching out in-buffer eval functions to those which are current-package aware. If you resolve and swap out all symbols with their "absolute" versions during definition, you should be able to call that code from different namespaces without problems.
where (:use nil) serves the same purpose as (:use :cl) in Common Lisp.
Afterwards, you can either do
(in-namespace :foo) ...
or
(with-namespace :foo ...)
You should also be able to file-locally set `buffer-namespace', but I haven't tried it.
Here's a working snippet:
(define-namespace :foo (:use nil) (:export bar setq nil))
(define-namespace :baz (:use :foo) (:export bar))
(with-namespace :foo (setq foo 2))
foo:bar ;; => 2
(with-namespace :baz (setq bar 5) (setq quux 10))
foo:bar ;; => 5 baz:bar ;; => 5 baz:quux ;; => 10
although you'll need to patch elisp--preceding-sexp for C-x C-e to see the individual values. Here's the code you need to evaluate (at least on my version, I suggest trying this in a fresh emacs in case something goes wrong): 0x0.st/84sj.txt
@screwtape Oh come on you understand the situation perfectly ;) You can write hacks to make it look like there are namespaces, but at the end of the day, they are just hacks.
There has been multiple discussions about it on emacs-devel, and there is no way to get elisp out of the dark ages until the usual suspects are replaced. Which is not happening any time soon.
@screwlisp @Nicolas Martyanoff If you think I'd actually have anything interesting to say. I feel I can't really hold a candle to some of your previous guests. I'm just aimlessly noodling around with stuff.
You know I like to set an extremely low bar for quality personally. And after all, everyone eats at your sushi place every week...!
It's also interesting to everyone to get opinions on common lisp from the outside or somewhat recent arrivals. I think you and jeremy_list are both interesting as sort of Haskell/MOO/emacs/common lispers.
Counterpointing the "golang for serious business" long-time lisp-heads like @galdor
Harald
in reply to Jonathan Lamothe • • •Currently there are two options which help for the underlying problem:
gnu.org/software/emacs/manual/…
gnu.org/software/emacs/manual/…
I use both here:
codeberg.org/harald/eglot-supp…
For the shorthands, check the last few lines of the file.
But, no doubt, some real namespace with an export/import convention would be great.
eglot-supplements/eglot-selran.el at main
Codeberg.orgThe ol' tealeg 🐡
in reply to Jonathan Lamothe • • •Jonathan Lamothe
in reply to The ol' tealeg 🐡 • •@The ol' tealeg 🐡 I'm thinking something a little more robust involving using a symbol's property list to store everything contained within that namespace.
I'm probably biting off more than I can chew at this point in my understanding of elisp, but I'm sure this idea will stick around in my brain until I have enough of an understanding to pull it (or something comparable) off.
...or I find some already existing thing that does what I want (which is more likely).
The ol' tealeg 🐡
in reply to Jonathan Lamothe • • •Vassil Nikolov
in reply to The ol' tealeg 🐡 • • •@tealeg
Just a sidenote, but `in-package' and Co. are Common Lisp things, not just SBCL's.
And `*package*' is mainly used by the reader.
#CommonLisp
The ol' tealeg 🐡
in reply to Vassil Nikolov • • •@vnikolov the specific macro expansion can differ though, right?
Really I was just quickly checking by doing `(macroexpand ‘(in-package foo))`, I never really thought much about the implementation before now.
Vassil Nikolov
in reply to The ol' tealeg 🐡 • • •@tealeg
tealeg@mastodon.online> the specific macro expansion can differ though, right?
Yes, and it often does (and it may well contain implementation-specific items, of course).
And `macroexpand' is certainly a good way to explore things; just consult the specification as well (in this case the excellent Hyperspec, CLHS).
#CommonLisp
#CommonLispHyperSpec
Thuna
in reply to Jonathan Lamothe • • •Thuna
in reply to Thuna • • •Ok, here's a working(?) proof-of-concept for
#emacs namespaces: git.sr.ht/~thuna/namespace-el
In order to use it, go to your scratch buffer (or just any elisp
buffer), do M-x enable-namespace. Then, define a namespace via
(define-namespace :foo
(:use nil)
(:export my-symbols...))
where (:use nil) serves the same purpose as (:use :cl) in Common Lisp.
Afterwards, you can either do
(in-namespace :foo)
...
or
(with-namespace :foo
...)
You should also be able to file-locally set `buffer-namespace', but I
haven't tried it.
Here's a working snippet:
(define-namespace :foo
(:use nil)
(:export bar setq nil))
(define-namespace :baz
(:use :foo)
(:export bar))
(with-namespace :foo
(setq foo 2))
foo:bar ;; => 2
(with-namespace :baz
(setq bar 5)
(setq quux 10))
foo:bar ;; => 5
baz:bar ;; => 5
baz:quux ;; => 10
although you'll need to patch elisp--preceding-sexp for C-x C-e to see
the individual values. Here's the code you need to evaluate (at least
on my version, I suggest trying this in a fresh emacs in case
something goes wrong): 0x0.st/84sj.txt
Nicolas Martyanoff
in reply to Jonathan Lamothe • • •screwlisp
in reply to Nicolas Martyanoff • • •@galdor
Nicolas Martyanoff
in reply to screwlisp • • •@screwtape
Oh come on you understand the situation perfectly ;) You can write hacks to make it look like there are namespaces, but at the end of the day, they are just hacks.
There has been multiple discussions about it on emacs-devel, and there is no way to get elisp out of the dark ages until the usual suspects are replaced. Which is not happening any time soon.
screwlisp
in reply to Nicolas Martyanoff • • •@galdor
jlamothe did say the words introducing rudimentary...!
By the way, should I interview you ("interview") some time?
@me
Jonathan Lamothe
in reply to screwlisp • •screwlisp
in reply to Jonathan Lamothe • • •You know I like to set an extremely low bar for quality personally. And after all, everyone eats at your sushi place every week...!
It's also interesting to everyone to get opinions on common lisp from the outside or somewhat recent arrivals. I think you and jeremy_list are both interesting as sort of Haskell/MOO/emacs/common lispers.
Counterpointing the "golang for serious business" long-time lisp-heads like @galdor
Jonathan Lamothe likes this.
Jonathan Lamothe
in reply to Jonathan Lamothe • •