From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Tue, 13 Oct 2015 18:46:31 -0700 Message-ID: <561DB3F7.5080000@dancol.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <561BCD40.5040502@cs.ucla.edu> <22043.60385.632764.673759@turnbull.sk.tsukuba.ac.jp> <87wpurht82.fsf@gmx.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H3Va68dHLKdrVhpGQM0o1No6aJwm3htuN" X-Trace: ger.gmane.org 1444787265 2458 80.91.229.3 (14 Oct 2015 01:47:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 01:47:45 +0000 (UTC) Cc: Paul Eggert , emacs-devel@gnu.org To: Marcus Harnisch , "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 14 03:47:44 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZmBAL-0004JV-JC for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 03:47:41 +0200 Original-Received: from localhost ([::1]:40086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmBAK-0001fm-VY for ged-emacs-devel@m.gmane.org; Tue, 13 Oct 2015 21:47:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmB9L-0001YD-Ia for emacs-devel@gnu.org; Tue, 13 Oct 2015 21:46:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmB9K-0003Er-Qc for emacs-devel@gnu.org; Tue, 13 Oct 2015 21:46:39 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:43136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmB9K-0003Ek-Jm for emacs-devel@gnu.org; Tue, 13 Oct 2015 21:46:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=bK0PpTfPSFkBTo2CpHbng36ULAb2ZeDR8wfPoEfELOQ=; b=XHBLV6bjdZrmo3EPf26mWzbu9hM2VPsAr4hL54BT351tMztlx6LTsQtB0aDDc+cU4It/DGdy+iRAsPFfTbKmlgJvj3gW1oHF/DWP99+S4uFZPIdlLwPy8vMWggHI6dKIJvFRVu6guJ5KRp3hDuM2NWv30wVScUPQhrnPduIj6cUgUKYRPhdhfwRxxuhqk2qF+Idn7tb4SeU+Q/kMvPo9o5g3qA8UD1Di0oJmhD/Rhj8WSuCHFxtat/k59wn+cJCfCZlVGvC7WZl6fdTrUZTUu0lhG+FzDo5Ja3tFx8HLc9t6AwdGpV5BswQ+rigvFKCrZat6Ez2bDpZhXYmitEUXTg==; Original-Received: from [2620:10d:c090:200::5:7a3e] (helo=[IPv6:2620:10d:c083:10fb:2ab2:bdff:fe1c:db58]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZmB9I-0001Uz-V8; Tue, 13 Oct 2015 18:46:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <87wpurht82.fsf@gmx.net> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191523 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H3Va68dHLKdrVhpGQM0o1No6aJwm3htuN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/13/2015 05:02 AM, Marcus Harnisch wrote: > Another potential I would see is the availability of higher-level > (STL) data structures w/o dependencies on external libraries, thus > allowing Emacsen to reduce their number of home-grown data > structures. Seeing comments in ancient code Similar comments apply to STL data structure implementations. We can always do better with application-specific data structures than we can with one-size-fits-all C++ data structures designed as reasonable defaults, not optimal implementations. I'd hate for someone to think that std::unordered_map, say, is somehow better than the data structures we've used for a long time merely because the standard stipulates that the runtime must provide it. --H3Va68dHLKdrVhpGQM0o1No6aJwm3htuN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWHbP3AAoJEN4WImmbpWBl3VIP/inIZbSrsqS2JkMPeXTtfEnn KRojPwUeN/b+6ZidcRKGgwhrHOlbGpe3a0MSxakm2jfxPSJg0ZvbDLSzfzwEQ5oX pkRSq9k44cUlB3aCKaGVGcdpkwk6JA8+xGhT0PZiUIfV0Cd8p3D7k8+BAe2WrZ2Z IdtRJZKeSb0twyxh5Z7+EjmQZAUmN+fXyQUQPtcL6G8EnmhondV2T5iDx4pMYWrw PUyrt8TFChPUb1ztPOz5Tj/HKIXeAMoAU/tIIm3lcvtYy7wgDvnwJlKzUrjlXvX4 sb4cpDTDnWD30/aRlLsPuULNITBOosPZtM1mMDFbdXw7R9EyzflhxuE3JvM2mPNm Qf92beTq8Kt+arQIsR19NEcA4N+xmoW5N//CV8TMWjikJ3mrdqeQS9hMnzpvifIU MnS0ObKvgZ7nPX0X3E3owomLlp2iGUgDubbVhETl7LRUMnynDbaw9xv1au42+XPb VhbzjvtZ3AisyJQPVjpAC7Jwgttg9JOseo5RMzTm3S+lV+GCLAWOlgZM/I1FgBAK AdZ4xkSva+Qd9+XCQYuV7ReJz/MdG8HZbWKvkShe1RpLGitDUAPFnt2QE32dDojv JChHugb5P6Lu7LJbFPsy7j1S70u3Pkxj8oNRgU8GagmDa5qayL6Os2gZ+37jRZJx SQAsXqTmkGSMP5/86kD2 =iOhE -----END PGP SIGNATURE----- --H3Va68dHLKdrVhpGQM0o1No6aJwm3htuN--