all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Pascal J. Bourguignon" <pjb@informatimago.com>
To: emacs-devel@gnu.org
Subject: Re: Why (substring "abc" 0 4) does not return "abc" instead of an error?
Date: Mon, 16 Jul 2012 17:00:42 +0200	[thread overview]
Message-ID: <87hat73g4l.fsf@kuiper.lan.informatimago.com> (raw)
In-Reply-To: 87r4sbeplm.fsf@altern.org

Bastien <bzg@gnu.org> writes:

> Hi Pascal,
>
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>> (defun mysubstring (str start end)
>>   (substring str (max start 0)
>>                  (if end
>>                      (min end (length str))
>>                      (length str))))
>>
>> and use (mysubstring "abc" 0 4) --> "abc" 
>> instead of substring.
>
> I know how to implement my own defun for this but thanks.
>
> My question was about what _justifies_ the current behavior.

First, emacs and lisp were invented long before JS, Ruby, Python, C++
and a lot of other _currently_ popular languages and other languages
that were popular but are now forgotten ;-)

So emacs and lisp have another, older tradition.

If you were to invent a new lisp (or better, just writing a new lisp
application or library), then you could design a consistent set of
operators with a more "modern" look-and-feel; (the "modern" style spread
out in the 20's, it's an old style).

Technically, one good reason to signal an error instead of silently
clipping the arguments is that exactly it detects an error.  Since lisp
is a dynamically typed language, the type of the objects is controlled
by what the functions accept.  If you (or your compiler) formalize the
types accepted by the functions, then type inference can be implemented
and the program can be (for the most parts) type checked statically
too.  But even without static type checking with type inference, it's
useful to set up such constraints and signal such errors.

You could also accept non integer values for start and end.  Obviously
any real would be good too (but will you truncate or round?).  What
about complex numbers (if there were complexes in emacs lisp)?  Or just
what about other objects, what if we pass a string:

    (mysubstring str "42" "end-2")

We can imagine several useful behaviors.  But would a library/language
that would accept any type of arguments and values for any parameter be
really that useful?  Have a look at PHP and similar languages that
coerce everything everywhere.  I'm not sure that entirely helps writing
clean and bug-free programs.

But mostly the point is that it's a question of language (or DSL,
library) design.  It's somewhat arbitrary.  We can say that the
designers of substring (subseq in CL, and similar functions in ancestors
of CL and emacs lisp) found that it was useful to signal an error when
passing out of bounds arguments.



> Dmitry said at least JS, Ruby, Python and perhaps C++ uses 
> the behavior I mention --  so I'm even more curious now.
>
> I am not saying the behavior I expect is superior, it is
> just the one I expect -- I would like to read a good reason
> for the current one.  Juanma have a point when he said that 
> the current behavior is consistent with other *-substring 
> functions but again, `substring' seems different to me.

Well, lisp has this great advantage over other programming languages
that it is really very accomodating to your specific needs.

Look how emacs lisp provides a cl package with macros and functions
similar to those provided in Common Lisp.

Similarly, nothing prevents you to write an emacs lisp package with
macros and functions having a Javascript, or Ruby or Python or C++
look-and-feel, that would help programmers coming from those languages
to more easily adapt and feel more comfortable with emacs lisp, just
like cl helps me, a Common Lisp programmer, be more comfortable with
emacs lisp.

(require 'js)
(js-substring "abc" "0" 1000) --> "abc" ; and let JavaScript 
                                        ; programmers be happy!

(just document those functions and macros well, so that other emacs lisp
programmers can still understand what's happening).
-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.




  reply	other threads:[~2012-07-16 15:00 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16  3:45 Why (substring "abc" 0 4) does not return "abc" instead of an error? Dmitry Gutov
2012-07-16  7:32 ` Bastien
2012-07-16  7:52   ` Thierry Volpiatto
2012-07-16  8:38     ` Bastien
2012-07-16 13:03   ` Dmitry Gutov
2012-07-16 14:32     ` Bastien
2012-07-16 13:10 ` Pascal J. Bourguignon
2012-07-16 14:40   ` Bastien
2012-07-16 15:00     ` Pascal J. Bourguignon [this message]
2012-07-16 15:07       ` Lennart Borgman
2012-07-16 15:19         ` Pascal J. Bourguignon
2012-07-16 15:22         ` Bastien
2012-07-16 15:46       ` Bastien
2012-07-16 15:49         ` Bastien
2012-07-16 19:49           ` Thien-Thi Nguyen
2012-07-16 22:32             ` Bastien
2012-07-16 15:56         ` Pascal J. Bourguignon
2012-07-16 16:13           ` Bastien
  -- strict thread matches above, loose matches on Subject: below --
2012-07-16 19:00 Dmitry Gutov
2012-07-16 19:51 ` Tassilo Horn
2012-07-15 23:15 Bastien
2012-07-15 23:29 ` Juanma Barranquero
2012-07-15 23:59   ` Bastien
2012-07-16  0:10     ` Juanma Barranquero
2012-07-16  7:14       ` Bastien
2012-07-16 16:15         ` Stefan Monnier
2012-07-16 16:22           ` Bastien
2012-07-16 16:46           ` Bastien
2012-07-16 17:57             ` Tassilo Horn
2012-07-16 18:51               ` Lars Magne Ingebrigtsen
2012-07-16 19:30                 ` Bastien
2012-07-16 19:30                 ` Tassilo Horn
2012-07-16 20:20                 ` Pascal J. Bourguignon
2012-07-16 19:25               ` Bastien
2012-07-16 19:43                 ` Bastien
2012-07-16 20:19             ` Pascal J. Bourguignon
2012-07-16 20:30             ` Stefan Monnier
2012-07-16 22:28               ` Lennart Borgman
2012-07-16 22:48                 ` Bastien
2012-07-16 22:53                   ` Lennart Borgman
2012-07-16  7:38       ` Andreas Schwab
2012-07-16  9:40         ` Juanma Barranquero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hat73g4l.fsf@kuiper.lan.informatimago.com \
    --to=pjb@informatimago.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.