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 {}.
next prev parent 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
List information: https://www.gnu.org/software/emacs/
* 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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).