From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id DD1B520A1E for ; Sat, 8 Dec 2018 13:58:36 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 485D7120DE4; Sat, 8 Dec 2018 22:58:32 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 0C91A120C8B for ; Sat, 8 Dec 2018 22:58:28 +0900 (JST) Received: by filter0046p3mdw1.sendgrid.net with SMTP id filter0046p3mdw1-9232-5C0BCDFF-17 2018-12-08 13:58:23.475525478 +0000 UTC m=+308631.713403018 Received: from herokuapp.com (ec2-54-145-138-185.compute-1.amazonaws.com [54.145.138.185]) by ismtpd0036p1mdw1.sendgrid.net (SG) with ESMTP id gcIA0uwKQ_2b80r1n_b7bQ Sat, 08 Dec 2018 13:58:23.413 +0000 (UTC) Date: Sat, 08 Dec 2018 13:58:24 +0000 (UTC) From: shevegen@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65771 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15393 X-Redmine-Issue-Author: tenderlovemaking X-Redmine-Sender: shevegen X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS6hJvs13YuqvdBZk1YN42iP3Z0p6HXk02SAC1 3NoBClPt8Fm3JHr+bk8lw6HmzyPbvBrjJuXrCADbKdoGfbpBedW8vfOfnZsjJVCS/Ahgfr1sFeFCXA 3Ek9s/Zg9Ci0PANs+/DChzuFWFJFJy5pOuUayqi/tTs+K5wj+xlHchnnVw== X-ML-Name: ruby-core X-Mail-Count: 90379 Subject: [ruby-core:90379] [Ruby trunk Feature#15393] Add compilation flags to freeze Array and Hash literals X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15393 has been updated by shevegen (Robert A. Heiler). About the name - some suggestions if only to show which variants may be better than others. :) frozen: true # could say "ruby, freeze as much as you possibly can!" In other words, that setting/flag could mean that strings, hashes and arrays are frozen (if the above is approved). Or: frozen_string_array_hash_literals: true frozen_string_hash_array_literals: true frozen_three_literals: true I am not saying any of these names are good names. Just putting them down. :) frozen_literals: true I think one advantage for frozen_literals is that it is short. People could use that in .rb files too. Another approach could of course also be to only allow strings to be frozen (which will become the default in ruby 3.x if I remember correctly); and not allow a change of hash and arrays in a .rb file, but to allow it for the suggestion above, e. g. in RubyVM. One could also split the above up into hash and array as separate calls, so rather than: RubyVM::InstructionSequence.compile(<<-eocode, __FILE__, nil, 0, frozen_string_literal: true, frozen_hash_and_array_literal: true) to have: RubyVM::InstructionSequence.compile(<<-eocode, __FILE__, nil, 0, frozen_string_literal: true, frozen_hash_literal: true, frozen_array_literal: true) I mention the last primarily because we already have frozen string literals; so for consistency it may be useful to have it split up into hash and arrays too. If this is too cumbersome to use three separate calls, then one could always use keys that unify these, such as in the example given by Aaron: frozen_hash_and_array_literal: true could also include Strings into it: frozen_string_and_hash_and_array_literal: true It's a bit cumbersome though. Perhaps a simple variant may then be: frozen: true frozen_literal: true frozen_literals: true This could then mean to "freeze all that can be frozen". Anyway; I think the first step is to ask matz about the functionality itself, and then see which API may be best if this is approved. Personally I think "frozen_literals" would be ok, even if the name may not be 100% "perfect". Ruby is not necessarily perfect in all names e. g. I remember a few folks thinking that the word constant implies "can not be changed", which may be the accurate meaning, but from within ruby itself, I think it is perfectly fine to let people change constants if they want to (e. g. the philosophy of ruby to be practical and useful). ---------------------------------------- Feature #15393: Add compilation flags to freeze Array and Hash literals https://bugs.ruby-lang.org/issues/15393#change-75489 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Hi, I would like to add VM compilation options to freeze array and hash literals. For example: ~~~ ruby frozen = RubyVM::InstructionSequence.compile(<<-eocode, __FILE__, nil, 0, frozen_string_literal: true, frozen_hash_and_array_literal: true) { 'a' => ['b', { 'c' => 'd' }] } eocode puts frozen.disasm ~~~ Output is: ~~~ $ ./ruby thing.rb == disasm: #@thing.rb:0 (0,0)-(0,34)> (catch: FALSE) 0000 putobject {"a"=>["b", {"c"=>"d"}]} 0002 leave ~~~ Anything nested in the hash that can't be "frozen" will cause it to not be frozen. For example: ~~~ ruby not_frozen = RubyVM::InstructionSequence.compile(<<-eocode, __FILE__, nil, 0, frozen_string_literal: true, frozen_hash_and_array_literal: true) { 'a' => some_method } eocode puts not_frozen.disasm ~~~ Output: ~~~ $ ./ruby thing.rb == disasm: #@thing.rb:0 (0,0)-(0,24)> (catch: FALSE) 0000 putobject "a" 0002 putself 0003 opt_send_without_block , 0006 newhash 2 0008 leave ~~~ Eventually I would like to freeze array and hash literals in source code itself, but I think this is a good first step. The reason I want this feature is I think we can reduce some object allocations, and once Guilds are implemented, easily create immutable data. I've attached a patch that implements the above. (Also I think maybe "frozen_literals" would be a better name, but I don't want to imply that numbers or booleans are frozen too) Thanks! ---Files-------------------------------- 0001-Add-compile-options-for-freezing-hash-and-array-lite.patch (6.14 KB) -- https://bugs.ruby-lang.org/