On Tue, Mar 30 2021, Atharva Raykar wrote: > On 29-Mar-2021, at 15:38, Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: >> On 28/03/2021 13:40, Atharva Raykar wrote: >>> On 28-Mar-2021, at 08:46, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: >>>> The "define-?.*" can be simplified to just "define.*", but looking at >>>> the tests is that the intent? From the tests it looks like "define[- ]" >>>> is what the author wants, unless this is meant to also match >>>> "(definements". >>> Yes, you captured my intent correctly. Will fix it. >>>> Has this been tested on some real-world scheme code? E.g. I have guile >>>> installed locally, and it has really large top-level eval-when >>>> blocks. These rules would jump over those to whatever the function above >>>> them is. >>> I do not have a large scheme codebase on my own, I usually use Racket, >>> which is a much larger language with many more forms. Other Schemes like >>> Guile also extend the language a lot, like in your example, eval-when is >>> an extension provided by Guile (and Chicken and Chez), but not a part of >>> the R6RS document when I searched its index. >>> So the 'define' forms are the only one that I know would reliably be present >>> across all schemes. But one can also make a case where some of these non-standard >>> forms may be common enough that they are worth adding in. In that case which >>> forms to include? Should we consider everything in the SRFI's[1]? Should the >>> various module definitions of Racket be included? It's a little tricky to know >>> where to stop. >> >> If there are some common forms such as eval-when then it would be good to include them, otherwise we end up needing a different rule for each scheme implementation as they all seem to tweak something. Gerbil uses 'def...' e.g def, defsyntax, defstruct, defrules rather than define, define-syntax, define-record etc. I'm not user if we want to accommodate that or not. > > Yes, this is the part that is hard for me to figure out. I am going by > two heuristics: what Scheme communities in other places would generally > prefer, and what patterns I see happen more often in scheme code. > > The former is tricky to do. I posted to a few mailing lists about this, > but they don't seem active enough to garner any responses. > > The latter is a little easier to measure quickly. I did a GitHub search, > where I filtered results to only consider Scheme files (language:scheme). > > Some armchair stats, just for a broad understanding: > > Total number of scheme files: 529,339 > No. of times a construct is used in those files: > define and its variants : 431,090 (81.4%) > def and its variants : 18,466 ( 3.5%) > eval-when : 3,375 ( 0.6%) > > There was no way for me to quickly know which of these uses are at the top > level, but either way of the more structural forms that do show up in Scheme > code, define and its variants seem like a clear winner. I am not sure if > it's worth adding more rules to check for def and its variants, given that > they are not nearly as common. In those cases we should veer on the side of inclusion. The only problem we'll have is if "eval-when" is a "setq"-like function top-level form in some other scheme dialect, so we'll have a conflict. Otherwise it's fine, programs that only use "define" won't be bothered by an eval-when rule.
