From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.help Subject: Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols? Date: Fri, 3 Jan 2014 12:00:05 +0700 Message-ID: References: <87eh4q1mlp.fsf@nl106-137-194.student.uu.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1388725213 13600 80.91.229.3 (3 Jan 2014 05:00:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jan 2014 05:00:13 +0000 (UTC) Cc: "help-gnu-emacs@gnu.org" To: Emanuel Berg Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 03 06:00:20 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vywrq-0005sP-SI for geh-help-gnu-emacs@m.gmane.org; Fri, 03 Jan 2014 06:00:18 +0100 Original-Received: from localhost ([::1]:48186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vywrq-0003SH-Ic for geh-help-gnu-emacs@m.gmane.org; Fri, 03 Jan 2014 00:00:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vywrg-0003Qp-OL for help-gnu-emacs@gnu.org; Fri, 03 Jan 2014 00:00:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vywre-0006Tc-DF for help-gnu-emacs@gnu.org; Fri, 03 Jan 2014 00:00:08 -0500 Original-Received: from mail-qc0-x22d.google.com ([2607:f8b0:400d:c01::22d]:43428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vywre-0006SY-9Q for help-gnu-emacs@gnu.org; Fri, 03 Jan 2014 00:00:06 -0500 Original-Received: by mail-qc0-f173.google.com with SMTP id m20so14181004qcx.4 for ; Thu, 02 Jan 2014 21:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6V4KaKJg7OBnsFo5zTW7pbKnEwmylnfxMFuJSj3x6iA=; b=o6febB/GihYFPFPNSO+gLI1CAbWZASOIbW+DaZr+ELsyMOKMirkDnKCrdWx+0u9lb4 LMv3SkN80QUONprqS3i7uPKA1ob6JJYC4hObfIyifT5ydEbqt0hbEBYnVy8VuBEcWXjh ZXL6lZ7sUBB0WWLhmkrn5LjfeSNnDmm+2v/dqs6KoW0H8Hh/qyOGBpde0ttVHyyehhLM SyWsBOC+jQSBYsmZbB9Jh/8sVd8j3/uZr8SL8aljfttVE1sIqKGvmzwhPqKqdaqoRoeB bWBHpVDuahvswdJqF09FT4gmHaIiUy8jVcfajE6/kpr7H4m99Ls9UXmt7YP/Y/L2Seet 2uZg== X-Received: by 10.229.7.133 with SMTP id d5mr143205495qcd.10.1388725205379; Thu, 02 Jan 2014 21:00:05 -0800 (PST) Original-Received: by 10.96.14.74 with HTTP; Thu, 2 Jan 2014 21:00:05 -0800 (PST) In-Reply-To: <87eh4q1mlp.fsf@nl106-137-194.student.uu.se> X-Google-Sender-Auth: Rt52tg4Q6U1vYjZ10I4QIF96cSs X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c01::22d X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:95233 Archived-At: On Thu, Jan 2, 2014 at 9:31 PM, Emanuel Berg wrote= : > Rustom Mody writes: > > Couldn't you somehow annotate data: '('integer 1) and > then prior to assignment run an appropriate test: > (integerp ... ) You could but it becomes unwieldy pretty soon. One does not simply tell programmers =E2=80=9Cinstead of literal 1, you have to write '('intege= r 1)=E2=80=9D. You also incur run-time tests at each use. > But I still don't understand the benefit of having the > types explicit in code, apart from the mentioned > compiler type-check - is there anything else to it? > Could you overload functions based on types? (And: do > you *want* to do that?) In C++, we do that a lot. We have an operation to write an object into a text stream that=E2=80=99s written as =E2=80=9Cstream << object=E2=80=9D,= where stream is a special class type representing a file opened for text output, and object is anything for which operator<< is overloaded. This allows us to define streaming separately for each type, not in a single universal function with a gargantuan type-switch on the outermost level. (The closest lispic solution that springs to my mind would be to annotate each object with its type and then have an alist mapping types to functions, but this incurs the cost of run-time type information and the dynamic alist lookup, whereas C++ type-based overloading is resolved at compilation time.) > Could the compiler perform > optimizations if there are, for example, only integer > (and no float) arithmetic? Could, and can, and routinely does. It is, in fact, a form of function overloading =E2=80=94 just that the functions being overloaded happen to reside in the standard library and compiled to inline code rather than a function call. > Or is it just a safety-net > so you don't get overflows and truncations and thus > bugs that are very difficult to track? Why is this not > an issue in Lisp? It is. The Emacs Lisp manual specifies that integers are at least 30 bits long and that overflow is not checked. The syntax parser (reader) automatically parses integral literals bigger than the machine integer as floats (which may lead to silent loss of precision). Also, when a library changes the type of some variable (e.g. in v1 it was an integer, in v2 it is *either* an integer *or* an alist mapping mode symbols to integers), the clients of that library break at run time, possibly in the middle of some involved operation, with half of its side effects already applied and an obscure error message to the end user=E2=80=99s face. With type checking, they would break at compile or link time.