March 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:117244] [Ruby master Feature#6594] Integrated Functor
by matheusrich (Matheus Richard) 20 Mar '24

20 Mar '24

Issue #6594 has been updated by matheusrich (Matheus Richard). @mame Can we close this issue? ---------------------------------------- Feature #6594: Integrated Functor https://bugs.ruby-lang.org/issues/6594#change-107331 * Author: trans (Thomas Sawyer) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- I know the developers meeting is coming up so I'd like to get a few ideas I've had sitting in the wings out in the air before then. One the more useful is the idea of integrating Functors directly into the language. "Functor" is the term I use for "higher-order function". I blogged about this idea and you can read it here: http://trans.github.com/2011-09-07-ruby-heart-higher-order-functions/ The super short version is this: ~~~ruby def f => op, arg arg.send(__op__, arg) end f + 3 #=> 6 f * 3 #=> 9 ~~~ Another example: ~~~ruby class String def file => op, *args File.send(__op__, self, *args) end end "README.rdoc".file.mtime #=> 2012-06-14 12:34:45 -0400 ~~~ I'm using `=>` as means of indicating a higher-order function. Of course another syntax could be used if this won't fly. The important thing is the idea of higher-order functions being integrated directly into the language. Doing this without that integration requires the creation of an intermediate object for each call which is very inefficient. ---Files-------------------------------- 6594.pdf (77.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117243] [Ruby master Feature#8421] add Enumerable#find_map and Enumerable#find_all_map
by alexbarret (Alexandre Barret) 19 Mar '24

19 Mar '24

Issue #8421 has been updated by alexbarret (Alexandre Barret). zverok (Victor Shepelev) wrote in #note-4: > @alexbarret There is a somewhat lesser-known trick which looks pretty close to your code: > ```ruby > # proposal: > find_map(emails) do |email| > (matches = pattern.match(email)) && matches[:identifier] > end > # a "trick" > emails.find { |email| match = pattern.match(email) and break match[:identifier] } > # => "thecode" > ``` > It might even be considered two tricks, depending on your point of view: the control-flow `and` allows to chain any statements to it (note it doesn't need extra parentheses after assignment), and `break value` allows to return a non-standard value from a block. > > Not saying it is beautiful, just one more option. Thanks I learned something, and it makes sense thinking about it. Both `and` and `break` aren't things I'm used to use in Ruby code but I'm glad I know this trick. Not sure I'll use it much. Breaking with another value than the expected value returned from the enumerable method can be confusing. ---------------------------------------- Feature #8421: add Enumerable#find_map and Enumerable#find_all_map https://bugs.ruby-lang.org/issues/8421#change-107330 * Author: Hanmac (Hans Mackowiak) * Status: Feedback ---------------------------------------- currently if you have an Enumerable and you want to return the return value of #find you need eigther: (o = enum.find(block) && block.call(o)) || nil or enum.inject(nil) {|ret,el| ret || block.call(el)} neigher of them may be better than an directly maked method same for #find_all_map enum.lazy.map(&:block).find_all{|el| el} it may work but it is not so good -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117242] [Ruby master Feature#8421] add Enumerable#find_map and Enumerable#find_all_map
by alexbarret (Alexandre Barret) 19 Mar '24

19 Mar '24

Issue #8421 has been updated by alexbarret (Alexandre Barret). jeremyevans0 (Jeremy Evans) wrote in #note-5: > `find_map` seems like a bad name as there is no map. map implies calling the same function over all elements in a collection, and in this case, there would be a single element (or none if nothing was found). Combining `find` and `then` seems like the simplest way now if you don't want to use `break`: This is a good point. I always thought map was the action of transforming an element but it does have a implicit reference to an array or a collection. > > ```ruby > emails.find{ pattern.match(it) }&.then{ it[:identifier] } > ``` > > Personally, I would use the following approach is I think it is clearer: > > ```ruby > if match = emails.find{ pattern.match(it) } > match[:identifier] > end > ``` The code aboce doesn't work ^. `match` variable assigned is an email string not the matches found from the email. We implicitly thought that `find` was returning the matches not the item iterated over. ---------------------------------------- Feature #8421: add Enumerable#find_map and Enumerable#find_all_map https://bugs.ruby-lang.org/issues/8421#change-107329 * Author: Hanmac (Hans Mackowiak) * Status: Feedback ---------------------------------------- currently if you have an Enumerable and you want to return the return value of #find you need eigther: (o = enum.find(block) && block.call(o)) || nil or enum.inject(nil) {|ret,el| ret || block.call(el)} neigher of them may be better than an directly maked method same for #find_all_map enum.lazy.map(&:block).find_all{|el| el} it may work but it is not so good -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117241] [Ruby master Feature#8421] add Enumerable#find_map and Enumerable#find_all_map
by jeremyevans0 (Jeremy Evans) 19 Mar '24

19 Mar '24

Issue #8421 has been updated by jeremyevans0 (Jeremy Evans). `find_map` seems like a bad name as there is no map. map implies calling the same function over all elements in a collection, and in this case, there would be a single element (or none if nothing was found). Combining `find` and `then` seems like the simplest way now if you don't want to use `break`: ```ruby emails.find{ pattern.match(it) }&.then{ it[:identifier] } ``` Personally, I would use the following approach is I think it is clearer: ```ruby if match = emails.find{ pattern.match(it) } match[:identifier] end ``` ---------------------------------------- Feature #8421: add Enumerable#find_map and Enumerable#find_all_map https://bugs.ruby-lang.org/issues/8421#change-107328 * Author: Hanmac (Hans Mackowiak) * Status: Feedback ---------------------------------------- currently if you have an Enumerable and you want to return the return value of #find you need eigther: (o = enum.find(block) && block.call(o)) || nil or enum.inject(nil) {|ret,el| ret || block.call(el)} neigher of them may be better than an directly maked method same for #find_all_map enum.lazy.map(&:block).find_all{|el| el} it may work but it is not so good -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117239] [Ruby master Feature#8421] add Enumerable#find_map and Enumerable#find_all_map
by zverok (Victor Shepelev) 19 Mar '24

19 Mar '24

Issue #8421 has been updated by zverok (Victor Shepelev). @alexbarret There is a somewhat lesser-known trick which looks pretty close to your code: ```ruby # proposal: find_map(emails) do |email| (matches = pattern.match(email)) && matches[:identifier] end # a "trick" emails.find { |email| match = pattern.match(email) and break match[:identifier] } # => "thecode" ``` It might even be considered two tricks, depending on your point of view: the control-flow `and` allows to chain any statements to it (note it doesn't need extra parentheses after assignment), and `break value` allows to return a non-standard value from a block. Not saying it is beautiful, just one more option. ---------------------------------------- Feature #8421: add Enumerable#find_map and Enumerable#find_all_map https://bugs.ruby-lang.org/issues/8421#change-107326 * Author: Hanmac (Hans Mackowiak) * Status: Feedback ---------------------------------------- currently if you have an Enumerable and you want to return the return value of #find you need eigther: (o = enum.find(block) && block.call(o)) || nil or enum.inject(nil) {|ret,el| ret || block.call(el)} neigher of them may be better than an directly maked method same for #find_all_map enum.lazy.map(&:block).find_all{|el| el} it may work but it is not so good -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117238] [Ruby master Feature#16153] eventually_frozen flag to gradually phase-in frozen strings
by Dan0042 (Daniel DeLorme) 19 Mar '24

19 Mar '24

Issue #16153 has been updated by Dan0042 (Daniel DeLorme). This proposal is made redundant by #20205 chilled strings. Please close. ---------------------------------------- Feature #16153: eventually_frozen flag to gradually phase-in frozen strings https://bugs.ruby-lang.org/issues/16153#change-107325 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- Freezing strings can give us a nice performance boost, but freezing previously non-frozen strings is a backward-incompatible change which is hard to handle because the place where the string is mutated can be far from where it was frozen, and tests might not cover the cases of frozen input vs non-frozen input. I propose adding a flag which gives us a migration path for freezing strings. For purposes of discussion I will call this flag "eventually_frozen". It would act as a pseudo-frozen flag where mutating the object would result in a warning instead of an error. It would also change the return value of `Object#frozen?` so code like `obj = obj.dup if obj.frozen?` would work as expected to remove the warning. Note that eventually_frozen strings cannot be deduplicated, as they are in reality mutable. This way it would be possible for Symbol#to_s (and many others) to return an eventually_frozen string in 2.7 which gives apps and gems time to migrate, before finally becoming a frozen deduplicated string in 3.0. This might even open up a migration path for eventually using `frozen_string_literal:true` as default. For example if it was possible to add `frozen_string_literal:eventual` to all files in a project (or as a global switch), we could run that in production to discover where to fix things, and then change it to `frozen_string_literal:true` for a bug-free performance boost. ### Proposed changes * Object#freeze(immediately:true) * if `immediately` keyword is true, set frozen=true and eventually_frozen=false * if `immediately` keyword is false, set eventually_frozen=true UNLESS frozen flag is already true * String#+@ * if eventually_frozen is true, create a duplicate string with eventually_frozen=false * Object#frozen?(immediately:false) * return true if `immediately` keyword is false and eventually_frozen flag is true * rb_check_frozen * output warning if eventually_frozen flag is true ### Alternatively: the eventually_frozen flag is an internal detail only * OBJ_EVENTUAL_FREEZE * used instead of OBJ_FREEZE in `rb_sym_to_s` and others to set eventually_frozen=true * Object#freeze * set frozen=true and eventually_frozen=false * String#+@ * if eventually_frozen is true, create a duplicate string with eventually_frozen=false * Object#frozen? * return true (or maybe `:eventually`) if eventually_frozen flag is true * rb_check_frozen * output warning if eventually_frozen flag is true -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117237] [Ruby master Feature#8421] add Enumerable#find_map and Enumerable#find_all_map
by alexbarret (Alexandre Barret) 19 Mar '24

19 Mar '24

Issue #8421 has been updated by alexbarret (Alexandre Barret). Can we reconsider introducing `#find_map` please, especially since `#find_all_map` has been introduced as `#filter_map` in Ruby in 2.7? Here are some examples ```ruby require "minitest/autorun" # Option 1 def identifier(emails, pattern: /\Ausername\+(?<identifier>[a-z|0-9]+)(a)domain\.com\z/i) result = nil emails.each do |email| if matches = pattern.match(email) result = matches[:identifier] break end end result end # Option 2 def identifier(emails, pattern: /\Ausername\+(?<identifier>[a-z|0-9]+)(a)domain\.com\z/i) matches = nil matches[:identifier] if emails.find { |email| matches = pattern.match(email) } end class TestIdentifierMethod < Minitest::Test def test_identifier assert_equal 'thecode', identifier(%w[ username(a)domain.com username+123@domainAcom wrongusername+123(a)domain.com username+123(a)wrongdomain.com username+thecode(a)domain.com ]) assert_nil identifier(%w[ username(a)domain.com username+123@domainAcom wrongusername+123(a)domain.com username+123(a)wrongdomain.com ]) end end ``` Having a find_map would ease it a bit ```ruby def find_map(collection, &block) result = nil collection.each do |item| break if result = yield(item) end result end def identifier(emails, pattern: /\Ausername\+(?<identifier>[a-z|0-9]+)(a)domain\.com\z/i) find_map(emails) do |email| (matches = pattern.match(email)) && matches[:identifier] end end ``` Here is a second use case ```ruby # Problem 2 Pet = Struct.new(:name) Person = Struct.new(:name, :pet, keyword_init: true) class TestPetIdentitifer < Minitest::Test def setup @some_people_with_pet = [ Person.new(name: 'Alex', pet: nil), Person.new(name: 'Olivier', pet: nil), Person.new(name: 'Romain', pet: Pet.new('Darwin')), Person.new(name: 'Mariano', pet: nil), Person.new(name: 'Sébastien', pet: nil), Person.new(name: 'Ben', pet: nil) ] @people_with_no_pet = [ Person.new(name: 'Mariano', pet: nil), Person.new(name: 'Sébastien', pet: nil), Person.new(name: 'Ben', pet: nil) ] end def test_pet_found people = @some_people_with_pet expected_pet = Pet.new('Darwin') assert_equal expected_pet, people.find(&:pet)&.pet assert_equal expected_pet, find_map(people, &:pet) # -> people.find_map(&:pet) end def test_pet_not_found people = @people_with_no_pet assert_nil people.find(&:pet)&.pet assert_nil find_map(people, &:pet) # -> people.find_map(&:pet) end end ``` Having `#find_map` allows these benefits * The caller does not need to guard against `nil` like when `#find` returns nothing * `#find_map` would be faster than `filter_map.first` or even `lazy.filter_map.first` * It would add the parity with `filter_map`. `#find` is to `#filter` what `#find_map` is to `#filter_map` ---------------------------------------- Feature #8421: add Enumerable#find_map and Enumerable#find_all_map https://bugs.ruby-lang.org/issues/8421#change-107324 * Author: Hanmac (Hans Mackowiak) * Status: Feedback ---------------------------------------- currently if you have an Enumerable and you want to return the return value of #find you need eigther: (o = enum.find(block) && block.call(o)) || nil or enum.inject(nil) {|ret,el| ret || block.call(el)} neigher of them may be better than an directly maked method same for #find_all_map enum.lazy.map(&:block).find_all{|el| el} it may work but it is not so good -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117230] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 19 Mar '24

19 Mar '24

Issue #19057 has been updated by ioquatix (Samuel Williams). As an alternative course of action, I've released the latest head of unicorn as `unicorn-maintained` gem. You can use this instead of `unicorn` and it will work on Ruby head. https://github.com/unicorn-ruby/unicorn Anyone who wants to help contribute/maintain it, I am happy to add you to the organisation. It also includes `raindrops-maintained` as this has not been released. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107317 * Author: ioquatix (Samuel Williams) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117229] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by Eregon (Benoit Daloze) 19 Mar '24

19 Mar '24

Issue #19057 has been updated by Eregon (Benoit Daloze). > From the reaction to this ticket, it is clear that forcing the "hide all the details" approach could destroy the Ruby ecosystem. "destroy the Ruby ecosystem" seems an exaggeration if it's just `unicorn` not working, because there was no release in 2+ years. Are we going to never remove an API because one gem seems not maintained anymore and relies on it? It might even be useful if people notice unicorn is no longer maintained actively, e.g. if security issues are found there might not be a release fixing them either. Note that I would be very happy to be proven wrong about unicorn being no longer maintained. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107316 * Author: ioquatix (Samuel Williams) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117228] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by ioquatix (Samuel Williams) 19 Mar '24

19 Mar '24

Issue #19057 has been updated by ioquatix (Samuel Williams). Here is the revert PR: https://github.com/ruby/ruby/pull/10283 ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107315 * Author: ioquatix (Samuel Williams) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0