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: Check for redundancy Date: Mon, 29 Jun 2015 01:47:04 +0200 Message-ID: <87si9bl7k7.fsf@nl106-137-147.student.uu.se> References: <87twtrn86z.fsf@nl106-137-147.student.uu.se> <877fqnpl7h.fsf@robertthorpeconsulting.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1435535333 28621 80.91.229.3 (28 Jun 2015 23:48:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2015 23:48:53 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jun 29 01:48:44 2015 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 1Z9MJW-00043x-VR for geh-help-gnu-emacs@m.gmane.org; Mon, 29 Jun 2015 01:48:43 +0200 Original-Received: from localhost ([::1]:40134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9MJW-00058w-GO for geh-help-gnu-emacs@m.gmane.org; Sun, 28 Jun 2015 19:48:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9MJK-00058p-Mx for help-gnu-emacs@gnu.org; Sun, 28 Jun 2015 19:48:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z9MJH-0006mC-4y for help-gnu-emacs@gnu.org; Sun, 28 Jun 2015 19:48:30 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:54437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z9MJG-0006ll-U5 for help-gnu-emacs@gnu.org; Sun, 28 Jun 2015 19:48:27 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z9MJE-0003uF-6h for help-gnu-emacs@gnu.org; Mon, 29 Jun 2015 01:48:24 +0200 Original-Received: from nl106-137-246.student.uu.se ([130.243.137.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jun 2015 01:48:24 +0200 Original-Received: from embe8573 by nl106-137-246.student.uu.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jun 2015 01:48:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Original-Lines: 89 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: nl106-137-246.student.uu.se Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Cancel-Lock: sha1:ExRtbdao4U4a20z8MWl07KMSxNI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:105267 Archived-At: Robert Thorpe writes: > Just because there aren't types doesn't mean that > variables don't have types. What "untyped" means is > that the language doesn't enforce typing for you. > That makes it more important that you manage them > carefully for yourself. ... are you sure? In C, you do int five = 5; In Lisp (Elisp), you do (let ((five 5)) ...) If you want to, you can do (integerp five) but there is seldom a reason to do that unless you are into verifying indata. In my experience, you don't have to do that because such errors will implicitly be brought to day all but instantly when data is put to use. Only cool use of such "type" checks are DWIM functions where you can pass say either a char or a string and it will put it together differently but produce a consistent (transparent) result. Note that if those args were explicitly typed, or HN-typed, that would not work (unless some HN notion for char-or-string was invented). Maybe the variables values have types at runtime but not necessarily the variable *names* at coding time, which is when you'd prepend the HN-designation. In C, tho typing is explicit at declaration, which would seemingly hand over the responsibility to the compiler, there is still incomparably more mucking around with types - explicit and implicit casts, (void) pointers - typically on first compilation you get a bunch of this kind of errors (and warnings), all about types many panes ahead! So in this case it is the other way around - in C, having types explicit doesn't reduce "type work", but instead it is there tenfold, while in Lisp, not bothering with that makes for not having to do any of that. Besides, I don't think of (integerp five) as checking the "type" in a compiler sense, I think of it as checking what's there in a human sense much like looking into a bucket to see what's there so to decide what to do with it. > I agree with Yuri Khan that it's useful in other > situations. Khan's examples depend on how broadly > you treat the word "type". Khan is treating things > as types that you don't think of as types, his > definition is a bit broader than yours. There are > arguments for both ways of looking at things. > > Another thing that it's useful for is > differentiating a type from instances of a type. > For example, many people use "something_t" as the > type and "something" as the instance. I prefer to be > more specific, e.g.: "something_s" for a struct and > "something_e" for an enum. Yeah, I think there is a misunderstanding where you think I say you cannot mention types, encodings, units, etc. ever in variable names, i.e. you should never name something in terms of technology. That isn't so; I agree there are such cases when that is called for. However, the way I understood HN is that you should *always* use prefixes like that. What I remembered it looked like this: intMoney = 0; strGreeting = "Stay a while, and listen!"; And I don't see any reason to do that. -- underground experts united http://user.it.uu.se/~embe8573