Re: [racket-users] Historical note.
> On Nov 8, 2020, at 2:58 PM, Hendrik Boom wrote: > >> On Sun, Nov 08, 2020 at 12:47:11PM -0800, unlimitedscolobb wrote: >> The idea of having structs whose fields contain functions has never occurred >> to me ... > > Historical note: > > I first encountered structures containing function in the source code for > OS/360 way back in the late 60's. In assembler. > > -- hendrik > Structures with fields containing functions has never occurred to me before, either, at least not in those terms. However isn’t that exactly one of the key design principles behind how device-drivers are implemented and installed into an OS? And also how classes and objects were initially added to C as some pretty hairy #define macros and function pointers? This design pattern insight would have been beneficial to me sooner - doh! — Kieron -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/ADDB8BD2-9A4B-478E-B296-7EF44392466A%40gmail.com.
[racket-users] Historical note.
On Sun, Nov 08, 2020 at 12:47:11PM -0800, unlimitedscolobb wrote: > Thank you for you answer! I'll need to think more about it. The idea of > having structs whose fields contain functions has never occurred to me, but > it may actually fit my relatively simple use case (and the planned > migration to Typed Racket). Historical note: I first encountered structures containing function in the source code for OS/360 way back in the late 60's. In assembler. -- hendrik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20201108215826.sxdlxmult3teo6a3%40topoi.pooq.com.
[racket-users] Re: Generics vs. Classes?
Thank you for you answer! I'll need to think more about it. The idea of having structs whose fields contain functions has never occurred to me, but it may actually fit my relatively simple use case (and the planned migration to Typed Racket). - Sergiu On Sunday, November 8, 2020 at 8:22:16 PM UTC+1 jackh...@gmail.com wrote: > The typical use case for classes in Racket is writing GUIs, and that's > mostly because the GUI framework is class based. > > For most other use cases, generics are a better choice than classes. > They're simpler and have a less intrusive effect on your API surface. If > you don't need to support arbitrary user implementations, you can avoid > generics and classes altogether and use structs whose fields contain > functions. > > On Sunday, November 8, 2020 at 6:12:37 AM UTC-8 unlimitedscolobb wrote: > >> Hi, >> >> A general knowledge question: what would be the typical use cases of >> Racket generics vs. the typical use cases of Racket classes? >> >> Am I correct in assuming that I can do everything with classes what I >> could do with generics, and that generics have made their way into the >> language before the classes? >> >> - >> Sergiu >> >> P.S. I'm reading the section on classes in the updated Typed Racket >> reference, and I'm very happy to see this new functionality! Very good job >> the Typed Racket Team! >> > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/dccc148b-6f20-42c0-a5bf-c5a7f42b3bd2n%40googlegroups.com.
[racket-users] Re: Generics vs. Classes?
The typical use case for classes in Racket is writing GUIs, and that's mostly because the GUI framework is class based. For most other use cases, generics are a better choice than classes. They're simpler and have a less intrusive effect on your API surface. If you don't need to support arbitrary user implementations, you can avoid generics and classes altogether and use structs whose fields contain functions. On Sunday, November 8, 2020 at 6:12:37 AM UTC-8 unlimitedscolobb wrote: > Hi, > > A general knowledge question: what would be the typical use cases of > Racket generics vs. the typical use cases of Racket classes? > > Am I correct in assuming that I can do everything with classes what I > could do with generics, and that generics have made their way into the > language before the classes? > > - > Sergiu > > P.S. I'm reading the section on classes in the updated Typed Racket > reference, and I'm very happy to see this new functionality! Very good job > the Typed Racket Team! > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/dc76fceb-9829-4356-a2fe-0d340fef9c43n%40googlegroups.com.
[racket-users] Re: Compiler Construction (CC) 2021 - Call for Papers
ACM SIGPLAN 2021 International Conference on Compiler Construction (CC 2021) Co-located with CGO, HPCA and PPoPP Tue 2 - Wed 3 March 2021 https://conf.researchr.org/home/CC-2021 CALL FOR PAPERS The International Conference on Compiler Construction (CC) is interested in work on processing programs in the most general sense: analyzing, transforming or executing input that describes how a system operates, including traditional compiler construction as a special case. The abstract and full paper submission is now November 13, 2020. = IMPORTANT DATES = Abstract & Full Paper Submission: November 13, 2020 Author Response Period: December 7 - 9, 2020 Author Notification: December 22, 2020 Artifact Submission: January 5, 2021 AE Notification: January 20, 2021 Final Papers due: January 22, 2021 Conference: March 2 - 3, 2021 Original contributions are solicited on the topics of interest which include, but are not limited to: - Compilation and interpretation techniques, including program representation, analysis, and transformation; code generation, optimization, and synthesis; the verification thereof - Run-time techniques, including memory management, virtual machines, and dynamic and just-in-time compilation - Programming tools, including refactoring editors, checkers, verifiers, compilers, debuggers, and profilers - Techniques, ranging from programming languages to micro-architectural support, for specific domains such as secure, parallel, distributed, embedded or mobile environments - Design and implementation of novel language constructs, programming models, and domain-specific languages CC is an ACM SIGPLAN conference, and implements guidelines and procedures recommended by SIGPLAN (https://www.sigplan.org). Prospective authors should be aware of SIGPLAN’s Copyright policies. Proceedings will be made available online in the ACM digital library from one week before to one week after the conference. Full CfP: https://conf.researchr.org/track/CC-2021/cc-research-papers ARTIFACT EVALUATION Authors of accepted papers will be invited to submit their artifacts for the Artifact Evaluation (AE). The Artifact Evaluation process begins after the acceptance notification, and is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. To ease the organization of the AE committee, we kindly ask authors to indicate at the time they submit the paper, whether they are interested in submitting an artifact. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers are encouraged, but not required, to make these materials publicly available upon publication of the proceedings, by including them as “source materials” in the ACM Digital Library. CC AE web page: https://conf.researchr.org/track/CC-2021/research-artifacts ORGANIZERS General Chair: Aaron Smith - Microsoft / University of Edinburgh Program Chairs: Delphine Demange - Univ Rennes, Inria, CNRS, IRISA Rajiv Gupta - UC Riverside Artifact Evaluation Chairs: Bruno Bodin - Yale-NUS College Michel Steuwer - University of Glasgow Web Chair: Martin Lücke - University of Edinburgh Steering Committee: Björn Franke (Chair) - University of Edinburgh Jose Nelson Amaral - University of Alberta Christophe Dubach - University of Edinburgh Sebastian Hack - Saarland University Manuel Hermenegildo - IMDEA Software Institute and T.U. of Madrid (UPM) Alexandra Jimborean - University of Murcia Milind Kulkarni - Purdue University Louis-Noël Pouchet - Colorado State University Peng Wu - Futurewei Technologies Jingling Xue - UNSW Sydney Ayal Zaks - Intel Corporation and Technion Program Committee: Guillaume Baudart - IBM Research Walter Binder - University of Lugano Simone Campanoni - Northwestern University Albert Cohen - Google Caroline Collange - Inria, Univ Rennes, CNRS, IRISA Huimin Cui - Institute of Computing Technology, CAS Christophe Dubach - McGill University Benoît Dupont de Dinechin - Kalray Bernhard Egger - Seoul National University Christine Flood - Red Hat Laure Gonnord - University of Lyon and LIP Myoungsoo Jung - KAIST Andrew Kennedy - Facebook Dongyoon Lee - Stony Brook University Christian Lengauer - University of Passau Xavier Leroy - Collège de France and Inria Yun Liang - Peking University Toby Murray - University of Melbourne and Data61 Biswabandan Panda - Indian Institute of Technology Kanpur Santosh Pande - Georgia Tech Louis-Noël Pouchet - Colorado State University Gabriel Rodríguez - Universidade da Coruña Jan Vitek - Northeastern University Jingling Xue - UNSW Sydney Zhijia Zhao - UC Riverside -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe
[racket-users] Generics vs. Classes?
Hi, A general knowledge question: what would be the typical use cases of Racket generics vs. the typical use cases of Racket classes? Am I correct in assuming that I can do everything with classes what I could do with generics, and that generics have made their way into the language before the classes? - Sergiu P.S. I'm reading the section on classes in the updated Typed Racket reference, and I'm very happy to see this new functionality! Very good job the Typed Racket Team! -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/e992ac74-4aed-4b3f-a160-193bd7fb6026n%40googlegroups.com.
