220 40770 <3c4fad0d-fc54-4e5f-8b10-36c4d77cbb54@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: FrankHB1989 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Some comments on P0976R0 Date: Fri, 26 Oct 2018 04:15:55 -0700 (PDT) Lines: 136 Approved: news@gmane.org Message-ID: <3c4fad0d-fc54-4e5f-8b10-36c4d77cbb54@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_844_1360299663.1540552555132" X-Trace: blaine.gmane.org 1540552434 30857 195.159.176.226 (26 Oct 2018 11:13:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 11:13:54 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCTJVBPG3QIBB3HOZPPAKGQEHGBJ37A@isocpp.org Fri Oct 26 13:13:50 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f69.google.com ([209.85.161.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG03n-0007sV-9c for gclcip-std-proposals@m.gmane.org; Fri, 26 Oct 2018 13:13:47 +0200 Original-Received: by mail-yw1-f69.google.com with SMTP id 141-v6sf373805ywr.10 for ; Fri, 26 Oct 2018 04:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=+2rrNFjWZaIYZFSM44pUBqXE6pR5cJQMhG2ZrrDvm7I=; b=I/yF85rImVHtaA1fPt50/1CUovmqXn3RwVnUvWpF+StK+HxxRYkojPkQL9LyeauRuo sN6j/V+VyXrGtLOxwg4I8R39qu8eZZs0im9lTSU01wWM+WGC3DAr6wd2jAED0aNSDwjg REgUiekE4A5D8D0hthfGodrur2UtgiZ9AbOO+65WViWlNxzSoNtFqLma5FjEsKLvKJkq wGUk4++eceyTAghX6zOBI6460d1BFLH8z9+c0HjnnUGLWMCWUK82Trh12wqVN20U76k5 ogLKv9dvXyciubp7oIaVSNOBQt5OPmYKqFnOr/2DZooLsvZ2L4LKNga4k3CX93EIe+rW UAIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=+2rrNFjWZaIYZFSM44pUBqXE6pR5cJQMhG2ZrrDvm7I=; b=krk7hKYJSeC7EeufLuPNgUEI0TOmTt/SpWyxnr9EN47GMRaWuVg2a7JalKv3o5SSOa xpvdcG6L83Xm1CjATXq/UuOEgNHmRX3cESL+P2q2t/SlAtFG22V+3ilypKJJlN+bBe4n nj6NTH8FwTOiEmeELz4rIs9ionI7OmHFhezNdKcAnspqJ0Fe+whCNPTtSfmxihAxLyJy o57pNp4czp8pd33D3yDSmhRoXvVpEGKy6X4VSo2U3lKyZrZgQgGGUOqCwYSm5eRiE/Jj quqtUBscDZcDIsyMUBr1vRT/Ybwu09hZsTJNl8YtK0WyyazZ+mX4gd6BGLPyDZjrsSWC Mtyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+2rrNFjWZaIYZFSM44pUBqXE6pR5cJQMhG2ZrrDvm7I=; b=AeDIXhS9AIVwSsW0FuHuePnZ7ufcfMxKsZTH+UnSM/R+L2/H98ni9/ZY7V1ZoR5eQQ QyX/bLjnnMEUOb15AOaCScDrL6ka1UviGsTXHneOj2WWUztpUQdSAweTX6ijiReRFIOK 7EeM+1R1ZzAF1/fGhTI6dRcKjRhq3a8O7DlH/8KYdKuSopUZQvAfSq/sQd+QvL5Ln7/o AQStEzu7Ez1po4DHVMZ8OMsQirDKxJAYUbXHvukznCxYgT9158JNke9xfX+KUXkQLpqi ChxQB6Q8zvISXtUylqmbmWJahkf+Ff5kdAQC9YUkx7T4yYfeUZc4SGcrr+yaLU0NEOBZ E4Xg== X-Gm-Message-State: AGRZ1gJiP635Z49GR8GePfhQ41IycSvGYDGMlBq5GRRvDGnVNQRmfBYM DMh7lbkvVVcOMUd1RDA/Q9J1+A== X-Google-Smtp-Source: AJdET5cn6bUtz7Xa74jxjqQsE9UbHZVg4Hr7geUYiUdiuHlB1b/stoIf+u+OI+7+gQcARLX5h/KFNg== X-Received: by 2002:a81:b248:: with SMTP id q69-v6mr1843937ywh.0.1540552557422; Fri, 26 Oct 2018 04:15:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3d45:: with SMTP id k66-v6ls867875ywa.11.gmail; Fri, 26 Oct 2018 04:15:55 -0700 (PDT) X-Received: by 2002:a81:13d4:: with SMTP id 203-v6mr31893ywt.5.1540552555651; Fri, 26 Oct 2018 04:15:55 -0700 (PDT) X-Original-Sender: frankhb1989@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40770 Archived-At: ------=_Part_844_1360299663.1540552555132 Content-Type: multipart/alternative; boundary="----=_Part_845_527868204.1540552555132" ------=_Part_845_527868204.1540552555132 Content-Type: text/plain; charset="UTF-8" (Request for comments. Disclaimers: There may be possibly premature and informal points and misnomers. It is yet not ready for being presented in a paper.) "I didn't see a single facility for totally replacing macros while still remaining sufficiently flexible and efficient." The term "macro" has a huge set of extensions. Macros are used to *extend *a language with user-defined identifiers, and the language feature named "macro" used in the C++ is only an awkward case. I'd like to see macros in C++ being replaced by some saner choices, whether they are still named "macros". For example, hygienic macros can even totally replace most of built-in keywords with accurate formal definitions; modern variants of FEXPRs (e.g. in vau calculi , or the modified quote operator ) can be intuitively strictly more powerful than hygienic macros about abilities of abstraction . Note in the aspect of designing and drafting rules in a language specialization, hygienic macros are far more closed to FEXPRs (even not named "macros"), rather than C++ ones. The differences root far more than paradigms, but (for instance) in view of fundamental methodologies (formalism v. intuitionalism, so on) and language design disciplines (translating v. rewriting, multi-staged v. single-staged, "static" v. "dynamic", type-based v. unityped, manifest v. inferred, nominal v. structural...) and I don't see all of them have been categorized into the so-called paradigms. *Missing insights of them maybe more dangerous to the disordered evolution of features.* "Gradual transition and co-existence of older features with new also allows us to benefit from feedback in the evolutionary process. That's good engineering as opposed to hopeful philosophizing. " I'd still agree on preserving features like macros as the status quo, with more realistic reasons: it is just too difficult to get it done. The changes in the evolution will lead to too much work in the core language design, and making a "clean break" on features involving disciplines seems even impossible. As a user of the language, I have more minor reasons. To make an industrial language harder to teach is stupid; I don't want to see another "export" in the language, before a feasible way of "gradual transition" is found. But anyway, if that cannot be done, features will still bloat - with or without thinking of paradigm shift. On the other hand, co-existence of some features is already considerably bloated. This does not seem like a case of "good engineering" at all. If we need a better one, the first problem to be resolved is *how to systemically prevent the origins of the bloat*. Avoiding blind belief on paradigm shifts seems hardly enough. -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c4fad0d-fc54-4e5f-8b10-36c4d77cbb54%40isocpp.org. ------=_Part_845_527868204.1540552555132 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Request for comments. Disclaimers: There may be possibly = premature and informal points and misnomers. It is yet not ready for being = presented in a paper.)

"I didn't see a single facility for = totally replacing macros while still remaining sufficiently flexible and ef= ficient."

The term "macro" has a huge set of extensio= ns. Macros are used to extend a language with user-defined identifie= rs, and the language feature named "macro" used in the C++ is onl= y an awkward case. I'd like to see macros in C++ being replaced by some= saner choices, whether they are still named "macros". For exampl= e, hygienic macros can even totally replace most of built-in keywords with = accurate formal definitions; modern variants of FEXPRs (e.g. in vau calculi,= or the modified quote operator) can be intuitively strictly more powerful than h= ygienic macros about abilities of abstraction. Note in the aspect of designin= g and drafting rules in a language specialization, hygienic macros are far = more closed to FEXPRs (even not named "macros"), rather than C++ = ones. The differences root far more than paradigms, but (for instance) in v= iew of fundamental methodologies (formalism v. intuitionalism, so on) and l= anguage design disciplines (translating v. rewriting, multi-staged v. singl= e-staged, "static" v. "dynamic", type-based v. unityped= , manifest v. inferred, nominal v. structural...) and I don't see all o= f them have been categorized into the so-called paradigms. Missing insig= hts of them maybe more dangerous to the disordered evolution of features.

"Gradual transition and co-existence of older features with= new also allows us to benefit from feedback in the evolutionary process. T= hat's good engineering as opposed to hopeful philosophizing. "
=
I'd still agree on preserving features like macros as the status qu= o, with more realistic reasons: it is just too difficult to get it done. Th= e changes in the evolution will lead to too much work in the core language = design, and making a "clean break" on features involving discipli= nes seems even impossible.

As a user of the language, I have more mi= nor reasons. To make an industrial language harder to teach is stupid; I do= n't want to see another "export" in the language, before a fe= asible way of "gradual transition" is found. But anyway, if that = cannot be done, features will still bloat - with or without thinking of par= adigm shift.

On the other hand, co-existence of some features is alr= eady considerably bloated. This does not seem like a case of "good eng= ineering" at all. If we need a better one, the first problem to be res= olved is how to systemically prevent the origins of the bloat. Avoid= ing blind belief on paradigm shifts seems hardly enough.



--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/3c4fad0d-fc54-4e5f-8b10-36c4d77cbb54= %40isocpp.org.
------=_Part_845_527868204.1540552555132-- ------=_Part_844_1360299663.1540552555132-- .