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

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Bastien <bzg@gnu.org> writes:

> Hi Pascal,
>
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>> 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).
>
> I'm not into a ancient vs. modern quarrel.

It's not a quarrel, it's just to situate your mindset: you've learned
first another language and you come in emacs lisp with that other
language mindset.  In your own relative history it looks like emacs lisp
is new and changed gratuituously from your "old" language.

But in the absolute time, lisp and emacs lisp was before, and it's the
other languages who tend to differ gratuituously from lisp.  (And then
usually evolve back toward lisp, but THAT is another story).


But it's OK, as I said, you can easily import your habits in lisp, lisp
is very maleable.

 
>> 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")
>
> I'm not interested in doing crazy stuff, I'm interested in
>
> (substring "abc" 0 4 t)
>   => "abc"
>
> where `t' is the value of an option third NOERROR argument.
>
> (substring "abc" 0 4) would still throw an error, so that
> the change does not break any code.

I would not advise that nonetheless.  It can bite you.  I tried things
like that, and it bit me.  Better use a different name.

If there were CL-like packages in emacs lisp, we could use a symbol
named substring in a different package and it would be nice and clean.
But not yet in emacs lisp.


>> 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 please, this is not a language issue, just a suggestion
> on a useful extension to `substring'.

A library defines a "language" or a DSL (Domain Specific Language).

The only thing is that with some languages, the languages defined by
libraries are very constrained, syntactically and semantically.  But not
so in lisp.  Or rather, since lisp restricts itself to the sexp
low-level syntax, all language elements, either provided by the system
or user defined share the same status.


>> 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.
>
> I'm not really interested in other programmers, just in what I could
> write in Elisp.

Yes, that's why my first suggestion was for you to define a mysubstring
function.

With the current tools, you cannot easily use a different symbol named
substring in emacs lisp, and you cannot easily and safely redefine the
symbol substring, because other functions use it and may depend on its
current behavior.  It's better to just use a different symbol bound to
your own function in your own code.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.