2 ms·

> consider CL to be a static language without horribly misunderstanding the term If you look at the file compilation spec in the standard, the compiler is allo

by lispm 8y ago

> consider CL to be a static language without horribly misunderstanding the term If you look at the file compilation spec in the standard, the compiler is allowed to inline functions and it can assume that a function in the same file can't be redefined later. -> no late binding for the calls in the file. A function declared by the developers to be inlined, makes them also no longer use late-binding for calls. Specific implementations may also remove the compiler (see Allegro CL, LispWorks and some others), parts of an interpreter and other stuff of a typical Lisp runtime from a delivered applications. Generally function calls then might no longer use late-binding. The CL standard might mention some dynamic facilities, but actual implementations might remove parts of that from a delivered application, too. Example for more static facilities were the block compilation mode of Lucid CL, IIRC CMU CL also had a block compilation mode, some compilers do their own inlining (Allegro CL), mocl/clicc (and some others) do 'static' compilation of whole-programs for a large CL subset to C applications, LispWorks has an extensive delivery system which removes various unused Lisp facilities from an application ( http://www.lispworks.com/documentation/lw71/DV/html/delivery-23.htm#64250 http://www.lispworks.com/documentation/lw71/DV/html/delivery... ) and which can drastically reduce dynamic features.

aidenn0 8y ago
While I see your point, I wonder where to draw the line. Lisp has a stronger history of implementations that limit dynamicism. Common Lisp as a standard is highly dynamic. Common Lisp as actually implemented and used is sometimes much less dynamic. Does the existence of Cython mean that Python is a static language? Most python programmers will never use it so I would argue not.
- lispm 8y ago
  The standard is not 'dynamic' - it leaves a lot up to the implementations. The CL standard is describing more 'static' options than usual for Lisp. Lexical binding is more static than Dynamic Binding. Macros are more static than Fexprs. A file compiler is more static than an interpreter. Common Lisp was already designed with support for higher-performance implementations on stock hardware. Python is not a 'language' - but for most people it is the combination of a language and its implementation. In this Python one of the main (THE main?) ways to get better performance is to write the code in C. Not so Common Lisp - it is a language and a bunch of more or less conforming implementations. There the first and most important way to get better performance always has been to use an optimizing to-C or a to-Machine-Code compiler, code hints and compiler switches (SPEED, SAFETY, DEBUG, ...). For example the developers of a large CAD system written mostly in Lisp (iCAD, PTC, ...) did not compete with Python at that time, but with C++ based CAD systems. Having a dynamic CLOS implementation is then often a burden: how many objects can be created per second? How many generic function calls are possible per second? For example LispWorks allows the slot-value function to call a generic function slot-value-using-class. This is slow. Thus by default it is shut off. Clozure CL has I/O functions over streams. By default streams are not CLOS objects / functions. One can get them as CLOS objects, but one has to do that. There are many other examples where the implementation provides a dynamic version and a more static version. The typical example in Common Lisp, the language itself: structures and CLOS classes. Structures are efficiently compiled with inline access, no slot information, no updates on structure changes, efficient access into the slot (-> no multiple inheritance with changing slot otder). CLOS classes OTOH are the opposite. More dyanamic, especially in an implementation with the Meta-object Protocol supported. Whenever you decide to use structures in your program, then you choose 'static & fast'. When you choose CLOS classes then you choose: runtime dynamism and generally slower. The standard itself does not talk about a specific implementation - the implementations in use and the needs of the developer for their application delivery determines then how 'static' the implementation can be or needs to be.

by lispm 8y ago

aidenn0 8y ago

While I see your point, I wonder where to draw the line. Lisp has a stronger history of implementations that limit dynamicism. Common Lisp as a standard is highly dynamic. Common Lisp as actually implemented and used is sometimes much less dynamic. Does the existence of Cython mean that Python is a static language? Most python programmers will never use it so I would argue not.

lispm 8y ago
The standard is not 'dynamic' - it leaves a lot up to the implementations. The CL standard is describing more 'static' options than usual for Lisp. Lexical binding is more static than Dynamic Binding. Macros are more static than Fexprs. A file compiler is more static than an interpreter. Common Lisp was already designed with support for higher-performance implementations on stock hardware. Python is not a 'language' - but for most people it is the combination of a language and its implementation. In this Python one of the main (THE main?) ways to get better performance is to write the code in C. Not so Common Lisp - it is a language and a bunch of more or less conforming implementations. There the first and most important way to get better performance always has been to use an optimizing to-C or a to-Machine-Code compiler, code hints and compiler switches (SPEED, SAFETY, DEBUG, ...). For example the developers of a large CAD system written mostly in Lisp (iCAD, PTC, ...) did not compete with Python at that time, but with C++ based CAD systems. Having a dynamic CLOS implementation is then often a burden: how many objects can be created per second? How many generic function calls are possible per second? For example LispWorks allows the slot-value function to call a generic function slot-value-using-class. This is slow. Thus by default it is shut off. Clozure CL has I/O functions over streams. By default streams are not CLOS objects / functions. One can get them as CLOS objects, but one has to do that. There are many other examples where the implementation provides a dynamic version and a more static version. The typical example in Common Lisp, the language itself: structures and CLOS classes. Structures are efficiently compiled with inline access, no slot information, no updates on structure changes, efficient access into the slot (-> no multiple inheritance with changing slot otder). CLOS classes OTOH are the opposite. More dyanamic, especially in an implementation with the Meta-object Protocol supported. Whenever you decide to use structures in your program, then you choose 'static & fast'. When you choose CLOS classes then you choose: runtime dynamism and generally slower. The standard itself does not talk about a specific implementation - the implementations in use and the needs of the developer for their application delivery determines then how 'static' the implementation can be or needs to be.