[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should Emacs provide a uuid function?
From: |
Eli Zaretskii |
Subject: |
Re: Should Emacs provide a uuid function? |
Date: |
Mon, 09 May 2011 22:32:29 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden, address@hidden
> Date: Mon, 09 May 2011 14:03:44 -0300
>
> > (defcustom battery-status-function
> > (cond ((and (eq system-type 'gnu/linux)
> > (file-readable-p "/proc/apm"))
> > 'battery-linux-proc-apm)
> > ((and (eq system-type 'gnu/linux)
> > (file-directory-p "/proc/acpi/battery"))
> > 'battery-linux-proc-acpi)
> > ((and (eq system-type 'gnu/linux)
> > (file-directory-p "/sys/class/power_supply/")
> > (directory-files "/sys/class/power_supply/" nil "BAT[0-9]$"))
> > 'battery-linux-sysfs)
> > ((and (eq system-type 'darwin)
> > (condition-case nil
> > (with-temp-buffer
> > (and (eq (call-process "pmset" nil t nil "-g" "ps") 0)
> > (> (buffer-size) 0)))
> > (error nil)))
> > 'battery-pmset)
> > ((eq system-type 'windows-nt)
> > 'w32-battery-status))
>
> I don't mind this kind of dispatch table, personally.
>
> > I think it would be much cleaner to have 5 different implementations
> > in sysdep.c of the same primitive, than have the above followed by 4
> > different Lisp functions plus one primitive.
>
> I don't find the dispatch table worse than the sysdep.c
> code, personally.
FWIW, I'm very surprised to hear this from you.
I understand the motivation to move to Lisp everything that can be
moved, especially if the code deals with Lisp data types, but there
should be limits, I think. Lisp is not suited well to reading raw
data from files and device drivers. insert-file-contents is a much
higher abstraction than `read' and `fscanf'.
It's not a coincidence that battery.el's implementation of these 4
functions take at least twice as much code as a C version would.
Worse, a programmer who wants to change battery.el now needs to
understand how the OS stores the data on those special files, which is
something most Lisp programmers don't and shouldn't care about.
Such code is okay in one's ~/.emacs, but not in a bundled package.
It is much better, IMO, to have the low-level stuff in a language that
was designed for that, and present to Lisp lispy data types and
structures that are as platform independent as possible.
- Re: Should Emacs provide a uuid function?, (continued)
- Re: Should Emacs provide a uuid function?, Leo, 2011/05/09
- Re: Should Emacs provide a uuid function?, Eli Zaretskii, 2011/05/09
- Re: Should Emacs provide a uuid function?, Stefan Monnier, 2011/05/09
- Re: Should Emacs provide a uuid function?, Eli Zaretskii, 2011/05/09
- Re: Should Emacs provide a uuid function?, Stefan Monnier, 2011/05/09
- Re: Should Emacs provide a uuid function?, Eli Zaretskii, 2011/05/09
- Re: Should Emacs provide a uuid function?, Stefan Monnier, 2011/05/09
- Re: Should Emacs provide a uuid function?,
Eli Zaretskii <=
- Re: Should Emacs provide a uuid function?, Chong Yidong, 2011/05/09
- Re: Should Emacs provide a uuid function?, Eli Zaretskii, 2011/05/09
- Re: Should Emacs provide a uuid function?, Ted Zlatanov, 2011/05/09
- Re: Should Emacs provide a uuid function?, Eli Zaretskii, 2011/05/09
- Re: Should Emacs provide a uuid function?, Ted Zlatanov, 2011/05/09
- Re: Should Emacs provide a uuid function?, Lars Magne Ingebrigtsen, 2011/05/09
- Re: Should Emacs provide a uuid function?, Stefan Monnier, 2011/05/09
- Re: Should Emacs provide a uuid function?, Lars Magne Ingebrigtsen, 2011/05/09
- Re: Should Emacs provide a uuid function?, Stefan Monnier, 2011/05/09
- Re: Should Emacs provide a uuid function?, joakim, 2011/05/09