Re: Emacs Lisp's future

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> David Kastrup writes:
>
>  > Just bombing out in some predetermined manner in some fixed location is
>  > not a substitute for properly planned behavior.
>
> Nobody proposed that, so please stop arguing against it.
>
>  > Unless told differently, a tool like GUILE or Emacs, when used as a
>  > filter, should do exactly _those_ filtering operations you tell it.
>
> Right.  All Mark and I want is to default safely.  Ie, if you invoke an
> encoding named "utf-8", you get strictly conformant output.
>
> When Emacs is being used as a filter, you just have to use the
> 'utf-8-with-rawbytes coding system, and when Emacs is being used for
> what is presumably valid text, you use the 'utf-8 coding system.  IOW,
> it's use of the *-with-rawbytes coding systems that turns Emacs into a
> filter.
>
> I think that is way preferable to the alternative where 'utf-8 gives
> rawbytes, and you have to use 'utf-8-strict to get validation.

Emacs' current behavior where the low-level operations _obey_ _without_
_asking_ is quite preferable.  Again, you want to have the engine's
responsibilities confused with the application's responsibilities.  And
that means that you generally have to work around the engine for getting
basic work done.  And figure out just where in the operating layers you
have to apply overrides in order to get "don't mess with this"
semantics.

Since verification is best applied at a single place in an application,
being denied control over that place whenever you don't have _every_
_single_ _layer_ under your own control is a nuisance.

I am glad that Emacs does not get in my hair as an application
programmer like that, and it would be doubly appropriate for GUILE not
to do that.  GUILE is supposed to be an extension language and system.
As such, it should not try governing how an application is organizing
its verification processes.

-- 
David Kastrup