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.
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.
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/9781593272...
[2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...
[3] https://redirect.cs.umbc.edu/courses/331/fall10/resources/li...