bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

Enhancement request:

Provide a Boolean variable or a wrapper macro that has the effect of not
raising an error but just skipping over any unreadable #(...) construct.

(I really wish this were available for older Emacs versions.  Those are
the ones that barf on #(...) constructs that are supported in later
versions.


In GNU Emacs 24.5.1 (i686-pc-mingw32)
 of 2015-04-11 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --host=i686-pc-mingw32'

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Juri Linkov]

> Enhancement request:
>
> Provide a Boolean variable or a wrapper macro that has the effect of not
> raising an error but just skipping over any unreadable #(...) construct.

There is such macro called ‘ignore-errors’.

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> > Enhancement request:
> >
> > Provide a Boolean variable or a wrapper macro that has the effect of not
> > raising an error but just skipping over any unreadable #(...) construct.
> 
> There is such macro called ‘ignore-errors’.

No.  That ignores all errors.

Is there an error handler that covers all and only #(...) read errors?

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Juri Linkov]

>> > Enhancement request:
>> >
>> > Provide a Boolean variable or a wrapper macro that has the effect of not
>> > raising an error but just skipping over any unreadable #(...) construct.
>> 
>> There is such macro called ‘ignore-errors’.
>
> No.  That ignores all errors.
>
> Is there an error handler that covers all and only #(...) read errors?

Then you can use something like

  (condition-case err
      (read (current-buffer))
    (invalid-read-syntax err))

that for example for unreadable #<marker ...> returns

  (invalid-read-syntax "#")

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> >> > Enhancement request:
> >> > Provide a Boolean variable or a wrapper macro that has the effect of
> >> > not raising an error but just skipping over any unreadable #(...)
> >> > construct.
> >>
> >> There is such macro called ‘ignore-errors’.
> >
> > No.  That ignores all errors.
> >
> > Is there an error handler that covers all and only #(...) read errors?
                                              ^^^^^^^^
> Then you can use something like
>   (condition-case err
>       (read (current-buffer))
>     (invalid-read-syntax err))
> that for example for unreadable #<marker ...> returns
>   (invalid-read-syntax "#")

And (read ")((") gives (invalid-read-syntax ")").
So it's not specific to unreadable #(...) or #....

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Juri Linkov]

>> >> > Enhancement request:
>> >> > Provide a Boolean variable or a wrapper macro that has the effect of
>> >> > not raising an error but just skipping over any unreadable #(...)
>> >> > construct.
>> >>
>> >> There is such macro called ‘ignore-errors’.
>> >
>> > No.  That ignores all errors.
>> >
>> > Is there an error handler that covers all and only #(...) read errors?
>                                               ^^^^^^^^
>> Then you can use something like
>>   (condition-case err
>>       (read (current-buffer))
>>     (invalid-read-syntax err))
>> that for example for unreadable #<marker ...> returns
>>   (invalid-read-syntax "#")
>
> And (read ")((") gives (invalid-read-syntax ")").
> So it's not specific to unreadable #(...) or #....

You can also use the position in the source buffer
to scan text near the error where reading failed.

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Stefan Kangas]

Drew Adams <drew.adams@oracle.com> writes:

> Enhancement request:
>
> Provide a Boolean variable or a wrapper macro that has the effect of not
> raising an error but just skipping over any unreadable #(...) construct.
>
> (I really wish this were available for older Emacs versions.  Those are
> the ones that barf on #(...) constructs that are supported in later
> versions.

What's the use-case here?  Why can't you use `ignore-errors'?

Best regards,
Stefan Kangas

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> Drew Adams <drew.adams@oracle.com> writes:
>
>> Enhancement request:
>>
>> Provide a Boolean variable or a wrapper macro that has the effect of not
>> raising an error but just skipping over any unreadable #(...) construct.
>>
>> (I really wish this were available for older Emacs versions.  Those are
>> the ones that barf on #(...) constructs that are supported in later
>> versions.
>
> What's the use-case here?  Why can't you use `ignore-errors'?

The problem is when the thing inside the construct is unreadable, not
when there's errors (in a syntactically valid form).  For instance:

(ignore-errors #0)

In Common Lisp, this is the #| ...  |# operator, and it's handy
occasionally.  It's really like a nesting comment thing...

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

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> The problem is when the thing inside the construct is unreadable, not
> when there's errors (in a syntactically valid form).  For instance:
> 
> (ignore-errors #0)
> 
> In Common Lisp, this is the #| ...  |# operator, and it's handy
> occasionally.  It's really like a nesting comment thing...

Good point.  I was thinking of #(...), but yes,
the situation is more general.  It's about #
syntax that's found to be invalid, but for cases
where # nevertheless can tell where the sexp
parsing should end (and so can advance point there).

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> In Common Lisp, this is the #| ...  |# operator, and it's handy
>> occasionally.  It's really like a nesting comment thing...
>
> Good point.  I was thinking of #(...), but yes,
> the situation is more general.  It's about #
> syntax that's found to be invalid, but for cases
> where # nevertheless can tell where the sexp
> parsing should end (and so can advance point there).

Yup.

I couldn't quite remember whether the Common Lisp #| |# was balanced,
but it is, which is nice.  That is, you can write

#| foo #| bar |# zot |#

and the first |# doesn't end the first #|.

Digression: While Googling, I was reminded that Common Lisp also has

#+condition
(foo:bar)

which (possibly) ignores the next sexp...  which is handy in Common
Lisp, but Emacs doesn't need it.  Common Lisp needs it because reference
to an unloaded package is a read error, instead of an undefined error.
Which is a really bad design choice.  That is, you can't say
(if (fboundp 'foo:bar) ...) if foo is a package that isn't loaded --
it's a read error.

Digression over!

I'm not an expert on the Emacs Lisp reader, but poking at it at bit, it
seems like adding support for #| |# should be trivial: It's just a new
comment syntax, really, so we just have to count #|'s and discard the
input.

A bigger issue would be in emacs-lisp-mode -- having forward-sexp etc do
the right thing.  However, surely that's handled already in the Common
Lisp modes, so we could just crib code from those, I'd have thought...

So I think it's doable, which only leaves us with the question: What's
the use case?

Well, I think it's handy when developing.  If I'm in the middle of a
function

...
(foo)
(bar)
(and-here-i'm-adding-some-new-stuff-that's-not-finished
  ...
  )
(zot)
...

and I'm testing stuff, and I decide to take out the stuff I'm
writing...  Emacs doesn't really handle that well.  I usually end up
deleting the sexp, and hoping that the kill ring is big enough to hold
it until I need it again, or slapping a (when nil ...) around it, which
is unsatisfactory, because that changes the indentation.

Just being able to do:

...
(foo)
(bar)
#|
(and-here-i'm-adding-some-new-stuff-that's-not-finished
  ...
  )
|#
(zot)
...

would be nice.  And then the stuff I'm working on doesn't even have to
be syntactically correct.

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

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

You bring up a few things.  I'll comment only about
commenting. ;-)

> I couldn't quite remember whether the Common Lisp #| |# was balanced,
> but it is, which is nice.  That is, you can write
> #| foo #| bar |# zot |#
> and the first |# doesn't end the first #|.

Yes, CL block commenting is fully nestable and unnestable.

(IMO, that's really the point/advantage of block commenting.)

> I'm not an expert on the Emacs Lisp reader, but poking at it at bit, it
> seems like adding support for #| |# should be trivial: It's just a new
> comment syntax, really, so we just have to count #|'s and discard the
> input.

Possibly; dunno.

[Aside: I think it would be great if Elisp had reader
macros - give Lisp programs control over the Lisp reader.]
 
> So ... What's the use case?  Well, I think it's handy
> when developing.  If I'm in the middle of a function
> (foo)
> (bar)
> (and-here-i'm-adding-some-new-stuff-that's-not-finished
>   ...
>   )
> (zot)
> 
> and I'm testing stuff, and I decide to take out the stuff I'm
> writing...  Emacs doesn't really handle that well.  I usually end up
> deleting the sexp, and hoping that the kill ring is big enough to hold
> it until I need it again, or slapping a (when nil ...) around it, which
> is unsatisfactory, because that changes the indentation.
> 
> Just being able to do:
> (foo)
> (bar)
> #|
> (and-here-i'm-adding-some-new-stuff-that's-not-finished
>   ...
>   )
> |#
> (zot)
> 
> would be nice.  And then the stuff I'm working on doesn't even have to
> be syntactically correct.

Yes.  Well, we do have such a feature, but we don't have
it by just inserting paired delimiters.

We have it with `comment-region' (and similar).  How so?
Plain `C-u' UNcomments/unnests a given comment level.

One difference, besides the paired-delimiter one (but
which follows from it), is that you can't do it with
the same effect in-line.

Another is that because a single `;' comments to eol,
syntactically there's no essential difference among
`;', `;;', `;;;', etc.  And yet the commenting and
UNcommenting of `comment-region' give you the
additional control of how many `;' to work with.

E.g., you can "uncomment" by N `;', which may uncomment
some code and leave other code commented (which had M>N
`;').  But that's also what makes `comment-region' and
its `C-u' give you block-commenting behavior.

That's how I use `comment-region' - for block commenting
and uncommenting - unnesting a block of commented code.

And it's why I use `M-;' (`comment-dwim') ONLY for a
comment after a line of code.  I don't use it to comment
the region as a block comment.  Its behavior when the
region consists only of comments is different from its
region behavior otherwise.  And I don't want that.
___


Actually, instead of `comment-region' for block commenting
I use this, which is the same except it comments/uncomments
whole lines.

(defun comment-region-lines (beg end &optional arg)
  (interactive "*r\nP")
  (when (> beg end) (setq beg  (prog1 end (setq end  beg))))
  (let ((bol  (save-excursion
                (goto-char beg)
                (line-beginning-position)))
        (eol  (save-excursion
                (goto-char end)
                (if (bolp) (point) (line-end-position)))))
    (comment-region bol eol arg)))

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> > Enhancement request:
> >
> > Provide a Boolean variable or a wrapper macro that has the effect of not
> > raising an error but just skipping over any unreadable #(...) construct.
> >
> > (I really wish this were available for older Emacs versions.  Those are
> > the ones that barf on #(...) constructs that are supported in later
> > versions.
> 
> What's the use-case here?  Why can't you use `ignore-errors'?

(ignore-errors (read (current-buffer))

doesn't advance over the sexp.

I guess what I mean is a #() construct that raises
an (invalid-read-syntax "#") error.  A situation
where there is, in fact, a #(...) present but that
error gets raised.

It's possible that the request is underspecified;
dunno.

The parenthetical remark in the request is really
the motivation.  For older Emacs the syntax #(...)
didn't exist.  But that error can still be raised,
when the syntax of the `...' isn't valid.

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Provide a Boolean variable or a wrapper macro that has the effect of not
> raising an error but just skipping over any unreadable #(...) construct.

I assume you mean #<...> here?

Anyway, there was some discussion about this in the context of the new
readablep function and the `print-unreadable-function' variable.  We
could indeed introduce a new `read-unreadable-function' variable that's
called when we encounter a #< instead of throwing an error (with no
performance impact).

Does anybody see any major downsides to doing that?  We've been wary of
allowing the users to customise the Emacs Lisp reader, but this seems
like a very small thing.  And it'd allow people to implement having

#<marker in no buffer>

read to (make-marker), etc, if they find that useful for some data
structures.

I had an extremely quick peek at this some time back, and it seemed
pretty trivial to implement.

Any opinions?

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

bug#24982: [External] : Re: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> > Provide a Boolean variable or a wrapper macro that has the effect of not
> > raising an error but just skipping over any unreadable #(...) construct.
> 
> I assume you mean #<...> here?

No.  I meant #(...).  I wrote that twice.

But if you like you could extend this request
to some other - or to ALL - # reader syntax.
In that case, it would be good to be able to
specify just which syntaxes to ignore - e.g.,
have an option or defvar whose value is a list
that specifies which to ignore (e.g. in a
given context).

E.g. (from `i # TAB' in the Elisp manual):

 ##
 #$
 #'
 #(
 #@COUNT
 #:
 #N#
 #N=
 #^

> Anyway, there was some discussion about this in the context of the new
> readablep function and the `print-unreadable-function' variable.  We
> could indeed introduce a new `read-unreadable-function' variable that's
> called when we encounter a #< instead of throwing an error (with no
> performance impact).
> 
> Does anybody see any major downsides to doing that?  We've been wary of
> allowing the users to customise the Emacs Lisp reader, but this seems
> like a very small thing.  And it'd allow people to implement having
> 
> #<marker in no buffer>
> 
> read to (make-marker), etc, if they find that useful for some data
> structures.
> 
> I had an extremely quick peek at this some time back, and it seemed
> pretty trivial to implement.
> 
> Any opinions?
> 
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog:
> https://urldefense.com/v3/__http://lars.ingebrigtsen.no__;!!ACWV5N9M2RV99hQ!
> ecUUd4A1C-jNt5HVD7l0qY450h_bpEQRCBEBtE78iCT4tITSqr-AY6VKDdpX9cNx$

bug#24982: [External] : Re: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> > Provide a Boolean variable or a wrapper macro that has the effect of not
>> > raising an error but just skipping over any unreadable #(...) construct.
>> 
>> I assume you mean #<...> here?
>
> No.  I meant #(...).  I wrote that twice.

There's nothing unreadable about #("..."), which is the only thing
that's printed as #(...).

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

bug#24982: [External] : Re: bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> There's nothing unreadable about #("..."), which is the only thing
> that's printed as #(...).

I agree that this could usefully be generalized.
As I wrote:

  I was thinking of #(...), but yes,
  the situation is more general.  It's about #
  syntax that's found to be invalid, but for cases
  where # nevertheless can tell where the sexp
  parsing should end (and so can advance point there).

The reason I'm interested in #(...) is stated at
the outset - for Emacs releases where that isn't
supported.  If the bug is fixed in Elisp then I
could likely add whatever the fix is (a macro or
whatever) to my code, to handle such older releases.

But sure, let's consider handling # constructs
more generally, as I said in my previous mail.

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

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

  > Anyway, there was some discussion about this in the context of the new
  > readablep function and the `print-unreadable-function' variable.  We
  > could indeed introduce a new `read-unreadable-function' variable that's
  > called when we encounter a #< instead of throwing an error (with no
  > performance impact).

  > Does anybody see any major downsides to doing that?  We've been wary of
  > allowing the users to customise the Emacs Lisp reader, but this seems
  > like a very small thing.  And it'd allow people to implement having

I think it is asking for trouble to make `read' extensible, because
then people will extend it in different, incompatible ways.  That is
asking for trouble.

Uniformity is what we need here.  If we want to handle some additional
read syntax, we should implement it in the C code so that it works the
same for everyone.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> I think it is asking for trouble to make `read' extensible, because
> then people will extend it in different, incompatible ways.  That is
> asking for trouble.
>
> Uniformity is what we need here.  If we want to handle some additional
> read syntax, we should implement it in the C code so that it works the
> same for everyone.

So there doesn't seem to be much enthusiasm for adding this to Emacs,
and I'm therefore closing this bug report.

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

bug#24982: 24.5; way to let Elisp reader ignore unreadable #(...) constructs

[Drew Adams]

> > I think it is asking for trouble to make `read' extensible, because
> > then people will extend it in different, incompatible ways.  That is
> > asking for trouble.
> >
> > Uniformity is what we need here.  If we want to handle some
> additional
> > read syntax, we should implement it in the C code so that it works
> the
> > same for everyone.
> 
> So there doesn't seem to be much enthusiasm for adding this to Emacs,
> and I'm therefore closing this bug report.

It seems you went off and dreamed up your own
substitute for the actual bug report and request.

Your reply here only to RMS's reply to your
detour shows that.  You're in effect closing your
own imaginary bug report, but with the unfortunate
side effect of closing this request as well.
___

Don't get me wrong; I assume the hijacking was
unintentional, from misunderstanding, not from
any desire to divert.

But coming back to what this request was actually
about, and to where you hijacked it to take the
detour:

>>> Provide a Boolean variable or a wrapper macro
>>> that has the effect of not raising an error
>>> but just skipping over any unreadable #(...)
>>> construct.

That's the request.

>> I assume you mean #<...> here?
>
> No.  I meant #(...).  I wrote that twice.
>
> But if you like you could extend this request
> to some other - or to ALL - # reader syntax.

With that last sentence I guess I unfortunately
encouraged you to ignore the preceding sentence,
where I said NO, that's not what this is about.

The request is _not_ about extending the reader
in any general way, though (unlike RMS) I'm not
against Elisp considering doing that (the devil
would be in the details).

The request is only about what is written above:
give users and code a way to, in effect,
`ignore-errors' for unreadable #(...).  Only that.

[It's not about `ignore-errors'; I mention that
as an analogy: we provide ways to ignore errors,
but not this kind of (reader) error.]