Re: Anonymous records
Antero Mejr
(30 Sep 2024 02:45 UTC)
|
Re: Anonymous records
Marc Nieper-Wißkirchen
(30 Sep 2024 06:02 UTC)
|
Re: Anonymous records
Daphne Preston-Kendal
(30 Sep 2024 07:08 UTC)
|
Re: Anonymous records
Marc Nieper-Wißkirchen
(30 Sep 2024 07:30 UTC)
|
Re: Anonymous records Daphne Preston-Kendal (30 Sep 2024 07:46 UTC)
|
Re: Anonymous records
Antero Mejr
(30 Sep 2024 19:26 UTC)
|
Re: Anonymous records
Daphne Preston-Kendal
(30 Sep 2024 20:12 UTC)
|
Re: Anonymous records
Sergei Egorov
(30 Sep 2024 21:07 UTC)
|
Re: R7RS large primitives [was: Re: Anonymous records]
Antero Mejr
(02 Oct 2024 22:28 UTC)
|
Re: R7RS large primitives [was: Re: Anonymous records]
Sergei Egorov
(02 Oct 2024 23:17 UTC)
|
Re: Anonymous records
Wolfgang Corcoran-Mathe
(01 Oct 2024 00:58 UTC)
|
Re: Anonymous records
Antero Mejr
(01 Oct 2024 03:24 UTC)
|
Re: Anonymous records
Arthur A. Gleckler
(01 Oct 2024 03:46 UTC)
|
Scheme meetups [was: Re: Anonymous records]
Peter Bex
(01 Oct 2024 19:20 UTC)
|
Re: Anonymous records
Retropikzel
(07 Oct 2024 16:14 UTC)
|
Re: Anonymous records
Peter Bex
(07 Oct 2024 18:01 UTC)
|
Re: Anonymous records
Arthur A. Gleckler
(07 Oct 2024 19:57 UTC)
|
On 30 Sep 2024, at 04:44, Antero Mejr <xxxxxx@antr.me> wrote: >> That said, even if not adopted into R7RS – or even if ‘records’ of this >> type build a completely different system from that supported by the R7RS >> record system* – this idea is intriguing. > > It would not be a good fit for Large, if what you're going for is a full > object system like CLOS. Anonymous records would be going in the > "smaller" direction. The R6RS record system includes a bunch of over-engineered features which I personally wish we could do without, but is still at core a record system, not an object system. It has only accessors and no methods. It has single inheritance, but this extends the list of fields in a record type only, like declaring a struct in C with the same initial n fields as some other struct and then adding more on top of them. Because there are no methods, there is no multiple dispatch, no advice, etc. etc. Though I occasionally threaten to make CLOS the record system of R7RS Large whenever someone starts requesting more and more features be added, this is only a joke. ;-) It is a fine base upon which to build something like CLOS, though. As I said in my email above, since our record system can’t accommodate everyone’s wishes, we can only encourage experimentation in building more powerful abstractions on top of it. *That’s* the spirit of Scheme! >> In any case, to be accepted into the fascicle on records would require >> support from at least 3 notable Scheme implementations by around this >> time next year. > > An aside: I think this rule is bad governance, like an appeal to > authority. It may be better to formalize the evaluation process for > features. Have a process for analyzing how new features would fit into > the larger Scheme world, with all the different shapes and sizes of > implementations and users. > > When citing N=3, Chez/Guile/Gambit are often used as justification. But > they have corporate/nonprofit/academic sponsorship, seem pretty > unbounded in terms of scope, and are R6RS. Most implementations do not > have those resources. And I don't think they reflect how many > programmers see and use Scheme. I am not sure why you picked those three implementations, and I am sure their maintainers would all be amused at the idea that their sponsorship is so good. All those implementations are very mature and have acquired features and optimizations slowly over a time period of *decades*. Chez and Gambit are older than me! It’s similar for other implementations we often look at, including Chibi (over 15 years old), Chicken (nearly 25 years), etc. *All* current Scheme implementations are fundamentally volunteer efforts. (Chez was the exception, but is no longer a commercial product, and it’s not clear to me that Cisco is really paying anyone to work on it.) Some volunteers in some communities (mostly Racket and Gambit) are also working on those implementations as part of academic projects which result in some papers being published on how such-an-implementation was used to try out such-an-idea. Thus it has ever been: Scheme is still an academic language for the most part, although it has picked up a strong hobbyist contingent in the last 20 years. The fact that implementers are still largely volunteering their efforts means we have to be careful about scope. The N=3 rule is *one* of the tools we have to reduce scope to keep implementability within reach. But, yes, the Large language will be a large language, suitable for the needs of mainstream software development. You don’t crank out an implementation of Python, Go, or Haskell overnight, either. Loko shows that new implementations of a language on the scale of R6 are possible (admittedly, Gwen Weinholt is also a deity-level programmer), and the core of the Foundations is a cleaned-up R6. If you want something you can really implement in a few days to a few weeks, the small language is there for a reason. > IMO the governance of Scheme is very opaque overall: there's stuff going > on at ICFP, on Codeberg, on SRFI, with the WG/Steering Committee (if > they are still active?). I personally don't like it, IDK what others > think. It doesn't make me feel comfortable about dedicating myself to > Scheme as a language. I am happy to respond to constructive, actionable criticism of our processes, but ‘I don’t like it’ is neither constructive nor actionable. I have no idea what you mean with the reference to ICFP. There is an annual one-day track of talks about Scheme there (the ‘Scheme Workshop’). Historically – by which I mean over 20 years ago now – the current governance structure for the Scheme reports originates in a business meeting held at the Scheme Workshop, but has been independent since then. Also, Arthur has presented occasional updates on the state of the SRFI process there, and it may be that I present at some point on the status of the R7RS Large process there. Apart from that, it is just a conference about our language, not too different from PyCon or GopherCon and so on for their respective languages. (But inherently a bit more academic because Scheme is still largely an academic language.) The WG discusses issues mainly on Codeberg, because it’s easier to find discussions and keep records of what we have decided on an issue tracker. By the charter, proposals we accept as the WG usually have to come from the SRFI process. The Steering Committee oversees the WG (with a very light touch). I am really not sure what we can do to make the process more ‘transparent’. But it’s especially hard to know when people apparently have ideas such as that ICFP is somehow part of the process. Daphne