From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols? Date: Sat, 04 Jan 2014 00:47:28 +0100 Organization: Aioe.org NNTP Server Message-ID: <878uuwr5jq.fsf@nl106-137-194.student.uu.se> 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: 8bit X-Trace: ger.gmane.org 1388793038 6414 80.91.229.3 (3 Jan 2014 23:50:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jan 2014 23:50:38 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jan 04 00:50:46 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 1VzEVo-00038s-2u for geh-help-gnu-emacs@m.gmane.org; Sat, 04 Jan 2014 00:50:44 +0100 Original-Received: from localhost ([::1]:52608 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzEVn-0008PF-Mr for geh-help-gnu-emacs@m.gmane.org; Fri, 03 Jan 2014 18:50:43 -0500 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!news.stack.nl!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 81 Original-NNTP-Posting-Host: /ZLK7EtDT1dvbkmVtWlLYw.user.speranza.aioe.org Original-X-Complaints-To: abuse@aioe.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Notice: Filtered by postfilter v. 0.8.2 Cancel-Lock: sha1:W3bWCssLfbs3NW9Wn+P84TD+vRk= Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:202974 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:95243 Archived-At: Yuri Khan 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 “instead of literal > 1, you have to write '('integer 1)”. You also incur > run-time tests at each use. For sure, if anyone actually did that, just plain with no automatizing or preprocessing, it would be grotesque. But let's think about how Lisp processing is often illustrated, not as an endless list but as nested lists that folds into a tree, with the functions (the first element of each list) as root or parent (inner) nodes, and with data as leaves. If every function node was annotated with argument types, and a return type, then the whole tree (list) could be fed to a type checker to see if all input types are consistent with the output types (i.e., the return values and argument types all match). The types of data could be checked at the leaves, because there it is known what type is expected, so a single check would be enough. What would complicate matters is for example the addition function (+), as (floatp (+ 1.0 1)) ; t (integerp (+ 1 1)) ; t So such cases would have to be replaced by one-type equivalents unless the uncertainty could somehow be "bounded", I suppose by "mixed" types, as in 'number' (integer *or* float, etc.). If I would ever use it though, I doubt. I just never felt the need to think about types in Lisp. >> 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’s written as “stream > << object”, 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.) That's true, in C++ it is a very vivid concept. You can have two classes and then overload the + function, and then have to instances seemingly "added" but in fact that operator is setup to whatever turn of events or data change the programmer sees fit. I remember they didn't want to allow that in Java because they were afraid over-creative programmers would setup all kinds of overloads that would sooner rather than later render unreadable code. (But Java has overload, just not down to the bare bones like C++.) -- underground experts united: http://user.it.uu.se/~embe8573