3 ms·

> At the very least, you can just write the code the macro would expand into Whenever you write code, you could just write the function it calls. One purpose

by lispm 4y ago

> At the very least, you can just write the code the macro would expand into Whenever you write code, you could just write the function it calls. One purpose of macros is to create descriptive notations. That's one way to create very readable, maintainable code, ... Lisp itself uses macros in the language everywhere: to define functions, to define classes, to define namespaces, to provide control structures, ... the core special operators are at a minimum and the large amount of syntactic operators are written as macros. As a developer I can use the same power to shape the operators of my domain, beyond what functions offer me and with compile time efficiency & syntactic control/abstraction.

kerkeslager 4y ago
> Whenever you write code, you could just write the function it calls. This is overly-glib. Calling a function doesn't come with the risk that calling a macro does, which I'm sure someone named "lispm" is aware of. > Lisp itself uses macros in the language everywhere: to define functions, to define classes, to define namespaces, to provide control structures, ... the core special operators are at a minimum and the large amount of syntactic operators are written as macros. As a developer I can use the same power to shape the operators of my domain, beyond what functions offer me and with compile time efficiency & syntactic control/abstraction. This just shows you don't understand the power/responsibility argument you're responding to. As a developer I don't have the resources to design and test my code to the extent that the language creators do. Lisp itself uses direct memory access to define the garbage collector, and you could use the same power to shape the memory usage of your domain, beyond what garbage collection offers and with compile time efficiency. But surely we can agree that's a terrible idea in most cases.
- lispm 4y ago
  There is a lot of irrational fear of macros. > As a developer I don't have the resources to design and test my code to the extent that the language creators do. Sure you could wait many years for the 'language designer' to provide you with new syntactical support or just write it in an afternoon yourself. It's the same crazy idea as writing a new class with its methods, instead just using the pre-made class hierarchy from the language or library designer. Surprise: programming macros can be learned and it does not hurt. > But surely we can agree that's a terrible idea in most cases. Not sure who this we is, but it is not me. It's exactly what the Lisp Machine did: you could use the same power to shape the memory usage of your domain. It had a bunch of different garbage collectors working side by side and a programmable memory management. All that was written in Lisp itself.
  - kerkeslager 4y ago
    > There is a lot of irrational fear of macros. I'm just going to copy from my other post: Land Of Lisp[1] has a section titled "Macros: Dangers and Alternatives". The elisp docs[2] contain a section on "Common Problems Using Macros". Paul Graham's On Lisp[3] contains a chapter on variable capture which consists mostly of sections on avoiding variable capture problems, followed by a chapter called Other Macro Pitfalls. I suppose it's possible that the authors of Lisp dialects are being irrational... > Sure you could wait many years for the 'language designer' to provide you with new syntactical support or just write it in an afternoon yourself. It's the same crazy idea as writing a new class with its methods, instead just using the pre-made class hierarchy from the language or library designer. Given all the work that has been done in modern languages to avoid the pitfalls of classes such as multiple inheritance, this is a better example of my point than you think it is. > Not sure who this we is, but it is not me. > It's exactly what the Lisp Machine did: you could use the same power to shape the memory usage of your domain. It had a bunch of different garbage collectors working side by side and a programmable memory management. All that was written in Lisp itself. The Lisp Machine is not "most cases". It's unsurprising that an attempt to run Lisp directly on hardware would need to do some direct memory access, but it's also absurd to extrapolate that to claim that this is something that is a good idea in most cases. Your average Lisp program does not and should not directly manage memory, and claiming otherwise is obviously just trying to win a silly point. I don't believe for a second that you do direct memory access in your Lisp programs on a regular basis, unless you're writing some very low-level stuff like hardware or a Lisp compiler/interpreter, and again, that's not "most cases". You're simply making a disingenuous argument here. [1] https://www.oreilly.com/library/view/land-of-lisp/9781593272814/ch18s03.html https://www.oreilly.com/library/view/land-of-lisp/9781593272... [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Problems-with-Macros.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr... [3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/lisp/onLisp/ https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...
    - lispm 4y ago
      > Macros: Dangers and Alternatives here is a simple LispWorks program using macros to provide manual memory management: CL-USER 17 > (defresource rarray (size) :constructor (make-array size) :initial-copies 0) RARRAY The above macro form defines a new manually managed resource named RARRAY. There is a constructor for allocating new RARRAY objects. Here the constructor just allocates an array of a certain size. CL-USER 18 > (using-resource (ra rarray 10) (setf (aref ra 3) 10) (incf (aref ra 3) 32) (aref ra 3)) 42 The above USING-RESOURCE macro looks up an array of size 10 from the resource pool. If there is none, it allocates one. In the context of the macro form, the array is marked in the pool as used and provided to the code. Upon leaving the dynamic context of USING-RESOURCE, the array will be returned to the pool and marked as unused. Bonus: DEFRESOURCE, USING-RESOURCE, SETF and INCF are all macros.

by lispm 4y ago

kerkeslager 4y ago

> Whenever you write code, you could just write the function it calls. This is overly-glib. Calling a function doesn't come with the risk that calling a macro does, which I'm sure someone named "lispm" is aware of. > Lisp itself uses macros in the language everywhere: to define functions, to define classes, to define namespaces, to provide control structures, ... the core special operators are at a minimum and the large amount of syntactic operators are written as macros. As a developer I can use the same power to shape the operators of my domain, beyond what functions offer me and with compile time efficiency & syntactic control/abstraction. This just shows you don't understand the power/responsibility argument you're responding to. As a developer I don't have the resources to design and test my code to the extent that the language creators do. Lisp itself uses direct memory access to define the garbage collector, and you could use the same power to shape the memory usage of your domain, beyond what garbage collection offers and with compile time efficiency. But surely we can agree that's a terrible idea in most cases.

lispm 4y ago
There is a lot of irrational fear of macros. > As a developer I don't have the resources to design and test my code to the extent that the language creators do. Sure you could wait many years for the 'language designer' to provide you with new syntactical support or just write it in an afternoon yourself. It's the same crazy idea as writing a new class with its methods, instead just using the pre-made class hierarchy from the language or library designer. Surprise: programming macros can be learned and it does not hurt. > But surely we can agree that's a terrible idea in most cases. Not sure who this we is, but it is not me. It's exactly what the Lisp Machine did: you could use the same power to shape the memory usage of your domain. It had a bunch of different garbage collectors working side by side and a programmable memory management. All that was written in Lisp itself.
- kerkeslager 4y ago
  > There is a lot of irrational fear of macros. I'm just going to copy from my other post: Land Of Lisp[1] has a section titled "Macros: Dangers and Alternatives". The elisp docs[2] contain a section on "Common Problems Using Macros". Paul Graham's On Lisp[3] contains a chapter on variable capture which consists mostly of sections on avoiding variable capture problems, followed by a chapter called Other Macro Pitfalls. I suppose it's possible that the authors of Lisp dialects are being irrational... > Sure you could wait many years for the 'language designer' to provide you with new syntactical support or just write it in an afternoon yourself. It's the same crazy idea as writing a new class with its methods, instead just using the pre-made class hierarchy from the language or library designer. Given all the work that has been done in modern languages to avoid the pitfalls of classes such as multiple inheritance, this is a better example of my point than you think it is. > Not sure who this we is, but it is not me. > It's exactly what the Lisp Machine did: you could use the same power to shape the memory usage of your domain. It had a bunch of different garbage collectors working side by side and a programmable memory management. All that was written in Lisp itself. The Lisp Machine is not "most cases". It's unsurprising that an attempt to run Lisp directly on hardware would need to do some direct memory access, but it's also absurd to extrapolate that to claim that this is something that is a good idea in most cases. Your average Lisp program does not and should not directly manage memory, and claiming otherwise is obviously just trying to win a silly point. I don't believe for a second that you do direct memory access in your Lisp programs on a regular basis, unless you're writing some very low-level stuff like hardware or a Lisp compiler/interpreter, and again, that's not "most cases". You're simply making a disingenuous argument here. [1] https://www.oreilly.com/library/view/land-of-lisp/9781593272814/ch18s03.html https://www.oreilly.com/library/view/land-of-lisp/9781593272... [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Problems-with-Macros.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr... [3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/lisp/onLisp/ https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...
  - lispm 4y ago
    > Macros: Dangers and Alternatives here is a simple LispWorks program using macros to provide manual memory management: CL-USER 17 > (defresource rarray (size) :constructor (make-array size) :initial-copies 0) RARRAY The above macro form defines a new manually managed resource named RARRAY. There is a constructor for allocating new RARRAY objects. Here the constructor just allocates an array of a certain size. CL-USER 18 > (using-resource (ra rarray 10) (setf (aref ra 3) 10) (incf (aref ra 3) 32) (aref ra 3)) 42 The above USING-RESOURCE macro looks up an array of size 10 from the resource pool. If there is none, it allocates one. In the context of the macro form, the array is marked in the pool as used and provided to the code. Upon leaving the dynamic context of USING-RESOURCE, the array will be returned to the pool and marked as unused. Bonus: DEFRESOURCE, USING-RESOURCE, SETF and INCF are all macros.