3 ms·

> "As flexible as Lisp": I think this is proven. Yao has equivalents for both macros (keywords) and reader macros (lexing modes). First-class symbols (incl. un

> "As flexible as Lisp": I think this is proven. Yao has equivalents for both macros (keywords) and reader macros (lexing modes). First-class symbols (incl. uninterned symbols)? Classes and functions can be redefined at runtime? User-available parsing (read) and runtime compilation (compile)? Restarts? CLOS and MOP? Communication with the compiler (declarations and ClTl2 *-information)? I don't mean to sound too abrasive, but reducing Lisp flexibility to macros is a bit much. In any case, good luck with your project!

gavinhoward 2y ago
> First-class symbols (incl. uninterned symbols)? Yes. > Classes and functions can be redefined at runtime? No. > User-available parsing (read) and runtime compilation (compile)? Yes, though runtime compilation is not implemented yet. > Restarts? Yes, though they are only implemented in the runtime; the keywords don't exist yet. > CLOS and MOP? No, the object system will be more recognizable to non-Lispers. > Communication with the compiler (declarations and ClTl2 *-information)? I wasn't able to find info on these. I will keep looking, and I would appreciate pointers, but the answer is probably no. Edit: after skimming [1], the answer on declarations is probably yes, for the most part. Still searching for *-information stuff. Edit 2: After skimming [2], Yao originally didn't have any concept of stuff like the *-information functions, but those are good ideas, and I will add them. [1]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node105.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node105.html [2]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html
- BoingBoomTschak 2y ago
  Huh, thanks for replying seriously to my snark, that's more than what I expected! About CLOS, I suggest at least making method combination more flexible than C++'s override. A way to run both the parent and child methods is often needed (maybe in a specific order, maybe with a way to collect all the return values). Declarations are basically C/C++'s pragmas and __attribute__, but standardized and using a seamless syntax. The ClTl2 additions I'm talking about are ways for the compiler to give lexical information to macros: see https://github.com/Zulu-Inuoe/trivial-cltl2 https://github.com/Zulu-Inuoe/trivial-cltl2 and https://github.com/alex-gutev/cl-environments https://github.com/alex-gutev/cl-environments
  - gavinhoward 2y ago
    > Huh, thanks for replying seriously to my snark, that's more than what I expected! Quite frankly, the snark was warranted. I'm not a Lisper, but I do know more, and I should have been more precise. > About CLOS, I suggest at least making method combination more flexible than C++'s override. At least a way to run both the parent and child methods is often needed (maybe in a specific order, maybe with a way to collect all the return values). I agree with this. However, Yao will not have inheritance; instead, it will be more like Go: composition over inheritance. And interfaces. So I could be wrong, but without inheritance, I'm not sure the entire complexity of the CLOS is needed. Do correct me, though. > Declarations are basically C/C++'s pragmas and __attribute__, but standardized and using a seamless syntax. That's such a nicer description than in CLtL2. And yes, Yao will have them. > The ClTl2 additions I'm talking about are ways for the compiler to give lexical information to macros: see https://github.com/Zulu-Inuoe/trivial-cltl2 https://github.com/Zulu-Inuoe/trivial-cltl2 and https://github.com/alex-gutev/cl-environments https://github.com/alex-gutev/cl-environments If those are just for giving info to macros, Yao already has that; the lexer will tell keywords if the given token is a package, a keyword, an operator, a function, a type, etc., along with other info.
    - BoingBoomTschak 2y ago
      > However, Yao will not have inheritance; instead, it will be more like Go: composition over inheritance. And interfaces. So I could be wrong, but without inheritance, I'm not sure the entire complexity of the CLOS is needed. Do correct me, though. I'm sadly not very well versed with this alternative to OOP. But something tells me that a more "basic" and less dynamic scheme like that is probably best for performance reasons, since you'd either need a Julia-like JIT or a granular "dynamism knob" like https://github.com/marcoheisig/fast-generic-functions https://github.com/marcoheisig/fast-generic-functions to truly amortize the cost of CLOS-like dispatch and polymorphism; though magic can be done, as the "Fast generic dispatch for Common Lisp" paper shows. > if those are just for giving info to macros, Yao already has that Huh! If this includes types deduced by compiler inference and not just user declarations (since Yao seems gradually typed, to my eyes), that'd be pretty impressive. Hope you'll be able to keep your spirits high, this is a lifetime's work you seem to be looking forward to ;)

gavinhoward 2y ago

> First-class symbols (incl. uninterned symbols)? Yes. > Classes and functions can be redefined at runtime? No. > User-available parsing (read) and runtime compilation (compile)? Yes, though runtime compilation is not implemented yet. > Restarts? Yes, though they are only implemented in the runtime; the keywords don't exist yet. > CLOS and MOP? No, the object system will be more recognizable to non-Lispers. > Communication with the compiler (declarations and ClTl2 *-information)? I wasn't able to find info on these. I will keep looking, and I would appreciate pointers, but the answer is probably no. Edit: after skimming [1], the answer on declarations is probably yes, for the most part. Still searching for *-information stuff. Edit 2: After skimming [2], Yao originally didn't have any concept of stuff like the *-information functions, but those are good ideas, and I will add them. [1]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node105.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node105.html [2]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html

BoingBoomTschak 2y ago
Huh, thanks for replying seriously to my snark, that's more than what I expected! About CLOS, I suggest at least making method combination more flexible than C++'s override. A way to run both the parent and child methods is often needed (maybe in a specific order, maybe with a way to collect all the return values). Declarations are basically C/C++'s pragmas and __attribute__, but standardized and using a seamless syntax. The ClTl2 additions I'm talking about are ways for the compiler to give lexical information to macros: see https://github.com/Zulu-Inuoe/trivial-cltl2 https://github.com/Zulu-Inuoe/trivial-cltl2 and https://github.com/alex-gutev/cl-environments https://github.com/alex-gutev/cl-environments
- gavinhoward 2y ago
  > Huh, thanks for replying seriously to my snark, that's more than what I expected! Quite frankly, the snark was warranted. I'm not a Lisper, but I do know more, and I should have been more precise. > About CLOS, I suggest at least making method combination more flexible than C++'s override. At least a way to run both the parent and child methods is often needed (maybe in a specific order, maybe with a way to collect all the return values). I agree with this. However, Yao will not have inheritance; instead, it will be more like Go: composition over inheritance. And interfaces. So I could be wrong, but without inheritance, I'm not sure the entire complexity of the CLOS is needed. Do correct me, though. > Declarations are basically C/C++'s pragmas and __attribute__, but standardized and using a seamless syntax. That's such a nicer description than in CLtL2. And yes, Yao will have them. > The ClTl2 additions I'm talking about are ways for the compiler to give lexical information to macros: see https://github.com/Zulu-Inuoe/trivial-cltl2 https://github.com/Zulu-Inuoe/trivial-cltl2 and https://github.com/alex-gutev/cl-environments https://github.com/alex-gutev/cl-environments If those are just for giving info to macros, Yao already has that; the lexer will tell keywords if the given token is a package, a keyword, an operator, a function, a type, etc., along with other info.
  - BoingBoomTschak 2y ago
    > However, Yao will not have inheritance; instead, it will be more like Go: composition over inheritance. And interfaces. So I could be wrong, but without inheritance, I'm not sure the entire complexity of the CLOS is needed. Do correct me, though. I'm sadly not very well versed with this alternative to OOP. But something tells me that a more "basic" and less dynamic scheme like that is probably best for performance reasons, since you'd either need a Julia-like JIT or a granular "dynamism knob" like https://github.com/marcoheisig/fast-generic-functions https://github.com/marcoheisig/fast-generic-functions to truly amortize the cost of CLOS-like dispatch and polymorphism; though magic can be done, as the "Fast generic dispatch for Common Lisp" paper shows. > if those are just for giving info to macros, Yao already has that Huh! If this includes types deduced by compiler inference and not just user declarations (since Yao seems gradually typed, to my eyes), that'd be pretty impressive. Hope you'll be able to keep your spirits high, this is a lifetime's work you seem to be looking forward to ;)