Re: Should Emacs provide a uuid function?

[Eli Zaretskii]

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