谢谢你，萨蒂什 李，
感谢您提供了最优秀的逐步解释。请原谅延迟回复，我一直在研究。
如果我能解释一下我从你上面的教程中理解的内容；我们创建两个相同的列表，并将其中一个向右移动，因为其最后一个项目被复制并设置到第一个位置（cons），然后逐个配对列表，直到短列表全部用完（mapcar），结果列表传递给grdraw以显示为连接的顶点。对
好奇的问题：GRVEC是否需要类似的列表操作？
史蒂夫
不客气；无需赦免
只有一个列表被分配给变量“l”：矩形的四个有序顶点的列表-该列表不包含任何重复项。
这四个顶点的列表作为mapcar表达式的第二个列表参数传递。
最后一个函数将检索该列表中的最后一项，cons函数将最后一个函数返回的值“推”到列表的前面，返回一个包含五项的列表（第一项等于最后一项）。
然后将这五个项目的列表作为mapcar表达式的第一个列表参数传递。
然后，将每个列表参数中的每个项作为参数传递给lambda函数-列表不会以任何方式“合并”，并且在将这些项提供给mapcar表达式的函数参数之前，不会创建新列表。
然后，mapcar将返回一个列表，其中包含其函数参数（在这种特殊情况下为lambda函数）每次求值的结果。
首先，我要注意的是，我的示例演示的列表操作对于程序的成功运行来说根本不是必需的（如您所知，因为您的原始代码也会表现得同样好）；使用mapcar只会使代码更加简洁，重复的表达式更少。
有许多方法可以编写AutoLISP表达式，同时仍能实现相同的最终结果：一些算法可能更优雅或简洁，另一些可能更高效。根据应用程序的不同，最优雅的路由可能会导致效率低下（尤其是对于某些递归解决方案），而对于其他应用程序，最有效的路由可能会导致代码无法管理。
GRVEC的使用可以替代现有代码中的grdraw，并以完全相同的方式编写，或者可以编写为多个GRVEC表达式，或者编写为具有多个参数的单个GRVEC表达式-不一定只有一个“正确”答案。
似乎我过于简单化了。感谢您的善意更正和进一步澄清。
现在清楚多了。
干杯
史蒂夫
页:
1
[2]