Re: Why (substring "abc" 0 4) does not return "abc" instead of an error?

[Pascal J. Bourguignon]

Bastien <address@hidden> writes:

> Hi Pascal,
>
> "Pascal J. Bourguignon" <address@hidden> 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 {}.