4 ms·

Yea, that's a weird statement, however a better one is that Smalltalk doesn't need macros because it has a clean syntax for lambas that remove a common use for

Yea, that's a weird statement, however a better one is that Smalltalk doesn't need macros because it has a clean syntax for lambas that remove a common use for macros, hiding boilerplate use of Lisp's lambda. Beyond that, Smalltalk isn't file based, you don't edit some version of the code that gets compiled (and macro expanded) into some runtime version of the code you can only see through introspection; rather in Smalltalk you're actually editing the runtime version in a running image. Macros simply wouldn't fit into Smalltalk in any meaningful way and Smalltalk's syntax is pretty much already ideal for building DSL's without the need to clean it up with macros. What makes both Lisp and Smalltalk interesting is that there's no difference between language and library; the constructs you create yourself are on equal footing with the ones most consider built in. Macros let you build special forms to control evaluation semantics, Smalltalk simply uses blocks [ ] to delay evaluation, and both languages are their libraries. Lisp has functions/macros, if/cond, etc; Smalltalk has objects used in a way you simply do not see in other object oriented langauges. Smalltalk has no if statement, no while statement, no reserved words beyond true, false, nil, self, super, and thisContext, everything else is library including all control flow constructs which are implemented with objects/classes/inhertance, and polymorphism. They are both "pure" languages in a sense, and that pleases some people greatly. If you haven't programmed in Smalltalk, you really have no idea what object oriented actually means at a deep level. All of the popular so called OO languages are actually just procedural languages with hundreds of special keywords that have classes, but the languages themselves aren't build from classes and objects, they're procedural and defined by the compiler writer as special forms you cannot create yourself. Having objects, and being truly object oriented all the way down, are drastically different things.

deleted 9y ago
[deleted]
teddyh 9y ago
> Smalltalk isn't file based, you don't edit some version of the code that gets compiled (and macro expanded) […] Macros simply wouldn't fit into Smalltalk in any meaningful way […] You speak as if “macros” means “macros as implemented in the C preprocessor”. Lisp macros, as I understand it, operate on the parsed syntax tree, not on the file text level, and are expanded at runtime, not compile time.
- aaron-lebo 9y ago
  The key to understanding macros is to be quite clear about the distinction between the code that generates code (macros) and the code that eventually makes up the program (everything else). When you write macros, you're writing programs that will be used by the compiler to generate the code that will then be compiled. Only after all the macros have been fully expanded and the resulting code compiled can the program actually be run. The time when macros run is called macro expansion time; this is distinct from runtime, when regular code, including the code generated by macros, runs. http://www.gigamonkeys.com/book/macros-defining-your-own.html http://www.gigamonkeys.com/book/macros-defining-your-own.htm...
  - lispm 9y ago
    This is the view of a compiled execution. Lisp can also be interpreted from source as data. Then macro-expansion time is interleaved with execution time. Each use of a macro form may trigger a macro expansion. Remember, a Lisp interpreter interprets Lisp source as data. Not byte code. Unlike Python, Java, Smalltalk, ... which all have popular implementations which compile to byte code and execute that byte code in a byte code interpreter, aka virtual machine. Let's use a Lisp interpreter, here from LispWorks: We define a primitive MY-IF macro. It expands into a simple IF use. But the macro will also count the number of macro expansions. CL-USER 46 > (defparameter *myif-counter* 0) *MYIF-COUNTER* CL-USER 47 > (defmacro my-if (c a b) (incf *myif-counter*) `(if ,c ,a ,b)) MY-IF LispWorks can trace macros, too. CL-USER 48 > (trace my-if) (MY-IF) Now a simple function which uses our macro: CL-USER 49 > (defun fac (n) (my-if (= 1 n) 1 (* n (fac (1- n))))) FAC Now we use it and we will see the trace information for the macro use: you see the incoming form and the result form. CL-USER 50 > (fac 2) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv NIL fenv ((#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv (#<Venv 275415194600 N>) fenv ((#:SOURCE-LEVEL-ENVIRONMENT-MARKER . #<COMPILER::FLET-INFO (NIL . #)>) (#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv NIL fenv ((#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv (#<Venv 275416002360 N>) fenv ((#:SOURCE-LEVEL-ENVIRONMENT-MARKER . #<COMPILER::FLET-INFO (NIL . #)>) (#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 2 Let's see how often our macro function has been used to expand code: CL-USER 51 > *myif-counter* 4
lispm 9y ago
> Beyond that, Smalltalk isn't file based, you don't edit some version of the code that gets compiled (and macro expanded) into some runtime version of the code you can only see through introspection; rather in Smalltalk you're actually editing the runtime version in a running image. That's not really true. Smalltalk is text-based, too, but hides it behind an integrated source management system. When you edit a method in a Smalltalk IDE, then you edit TEXT. The text then gets compiled to typically some byte code which gets interpreted by the Smalltalk virtual machine (which also might have some way to convert it to machine code). If the text of the source code is not available, then Smalltalk needs to disassemble the byte code. But the disassembled byte code is not equal to the original source. The sources are EXTERNALLY kept as text, outside the running system. Just download your favorite Squeak and check out the contents. There is a huge sources file and there is a changes file. Those are text files with the sources and its changes. This is actually different from some Lisp system, where the source actually is data inside the running Lisp and the Lisp interpreter runs this data. If you edit this code, Lisp then presents you a structure editor, which works on this data - not on text. It's not what a typical Lisp system does today, but it is still a possibility. Xerox' Interlisp used to use a structure editor for Lisp source code as data and a source code management system based on that. This is different from Smalltalk, where the 'Interpreter' runs compiled byte-code and the byte code is generated from source code, which is actually text and stored outside the Smalltalk image. The Smalltalk image has then source code management data, like an index in each method which points to its external source. Typical Lisp systems are doing the same. They record the source code location for functions and other things. If you edit the source for a method in a typical Smalltalk environment, it will retrieve the text for the method and in a text editor you can edit the text then. In a typical Lisp environment, the Lisp system will present you the whole text file and just jump to the definition using the editor...
- brudgers 9y ago
  GNU-Smalltalk is not just text based, but file based. http://smalltalk.gnu.org/ http://smalltalk.gnu.org/
- gnaritas 9y ago
  I'm well aware, I've programmed in Pharo daily for a decade; I Smalltalk for a living. What I said it true practically speaking, you're getting into implementation details that don't make a practical difference. Lisp and Smalltalk are both image based systems, but Smalltalk'ers actually work on the running live image all of the time, they aren't ever booting from the sources file nor are they ever editing it manually (excluding the one file based GNU Smalltalk), it's pared with a changes file to enable the IDE to expose the current source of a method but those are hidden implementation details whereas I'm talking about the abstraction presented to the programmer. Lispers "can" do this as well, and sometimes do, but Lisp has a much more standard general workflow of editing files that are then read and launched to create/patch a runtime image it's not the normal worflow to work entirely in the REPL which is essentially what Smalltalk'ers do. Consider the difference, what Smalltalker's see in their code browsers is a text version of what's actually running; if they had macros, which are nothing more than code generators, they'd be seeing is the macro expansion rather than the original source call to the macro. Certainly Lispers "can" do this as well, they can macro expand something to see what's actually running but as their primary mode is editing the original source they're accustomed to seeing the macro unexpanded, they might define an accessor like (name :accessor person-name :initform 'bill :initarg :name) And from experience know that an accessor is a getter, setter, and backing instance variable but they don't see those things in their editors, they just know they'll exist at runtime; whereas a Smalltalker is accustomed to looking at the runtime where he actually sees the getter, setter, and and backing instance variable. Macros just don't fit into Smalltalk; they've been added before, people keep trying it, and it just doesn't fit and so doesn't catch on.

deleted 9y ago

[deleted]

teddyh 9y ago

> Smalltalk isn't file based, you don't edit some version of the code that gets compiled (and macro expanded) […] Macros simply wouldn't fit into Smalltalk in any meaningful way […] You speak as if “macros” means “macros as implemented in the C preprocessor”. Lisp macros, as I understand it, operate on the parsed syntax tree, not on the file text level, and are expanded at runtime, not compile time.

aaron-lebo 9y ago
The key to understanding macros is to be quite clear about the distinction between the code that generates code (macros) and the code that eventually makes up the program (everything else). When you write macros, you're writing programs that will be used by the compiler to generate the code that will then be compiled. Only after all the macros have been fully expanded and the resulting code compiled can the program actually be run. The time when macros run is called macro expansion time; this is distinct from runtime, when regular code, including the code generated by macros, runs. http://www.gigamonkeys.com/book/macros-defining-your-own.html http://www.gigamonkeys.com/book/macros-defining-your-own.htm...
- lispm 9y ago
  This is the view of a compiled execution. Lisp can also be interpreted from source as data. Then macro-expansion time is interleaved with execution time. Each use of a macro form may trigger a macro expansion. Remember, a Lisp interpreter interprets Lisp source as data. Not byte code. Unlike Python, Java, Smalltalk, ... which all have popular implementations which compile to byte code and execute that byte code in a byte code interpreter, aka virtual machine. Let's use a Lisp interpreter, here from LispWorks: We define a primitive MY-IF macro. It expands into a simple IF use. But the macro will also count the number of macro expansions. CL-USER 46 > (defparameter *myif-counter* 0) *MYIF-COUNTER* CL-USER 47 > (defmacro my-if (c a b) (incf *myif-counter*) `(if ,c ,a ,b)) MY-IF LispWorks can trace macros, too. CL-USER 48 > (trace my-if) (MY-IF) Now a simple function which uses our macro: CL-USER 49 > (defun fac (n) (my-if (= 1 n) 1 (* n (fac (1- n))))) FAC Now we use it and we will see the trace information for the macro use: you see the incoming form and the result form. CL-USER 50 > (fac 2) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv NIL fenv ((#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv (#<Venv 275415194600 N>) fenv ((#:SOURCE-LEVEL-ENVIRONMENT-MARKER . #<COMPILER::FLET-INFO (NIL . #)>) (#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv NIL fenv ((#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 0 MY-IF > ... >> COMPILER::FORM : (MY-IF (= 1 N) 1 (* N (FAC (1- N)))) >> COMPILER::ENVIRONMENT : #<Augmented Environment venv (#<Venv 275416002360 N>) fenv ((#:SOURCE-LEVEL-ENVIRONMENT-MARKER . #<COMPILER::FLET-INFO (NIL . #)>) (#:FUNCTOR-MARKER . #<COMPILER::FLET-INFO (# # # #)>)) benv NIL tenv NIL decl NIL> 0 MY-IF < ... << VALUE-0 : (IF (= 1 N) 1 (* N (FAC (1- N)))) 2 Let's see how often our macro function has been used to expand code: CL-USER 51 > *myif-counter* 4

lispm 9y ago

> Beyond that, Smalltalk isn't file based, you don't edit some version of the code that gets compiled (and macro expanded) into some runtime version of the code you can only see through introspection; rather in Smalltalk you're actually editing the runtime version in a running image. That's not really true. Smalltalk is text-based, too, but hides it behind an integrated source management system. When you edit a method in a Smalltalk IDE, then you edit TEXT. The text then gets compiled to typically some byte code which gets interpreted by the Smalltalk virtual machine (which also might have some way to convert it to machine code). If the text of the source code is not available, then Smalltalk needs to disassemble the byte code. But the disassembled byte code is not equal to the original source. The sources are EXTERNALLY kept as text, outside the running system. Just download your favorite Squeak and check out the contents. There is a huge sources file and there is a changes file. Those are text files with the sources and its changes. This is actually different from some Lisp system, where the source actually is data inside the running Lisp and the Lisp interpreter runs this data. If you edit this code, Lisp then presents you a structure editor, which works on this data - not on text. It's not what a typical Lisp system does today, but it is still a possibility. Xerox' Interlisp used to use a structure editor for Lisp source code as data and a source code management system based on that. This is different from Smalltalk, where the 'Interpreter' runs compiled byte-code and the byte code is generated from source code, which is actually text and stored outside the Smalltalk image. The Smalltalk image has then source code management data, like an index in each method which points to its external source. Typical Lisp systems are doing the same. They record the source code location for functions and other things. If you edit the source for a method in a typical Smalltalk environment, it will retrieve the text for the method and in a text editor you can edit the text then. In a typical Lisp environment, the Lisp system will present you the whole text file and just jump to the definition using the editor...

brudgers 9y ago
GNU-Smalltalk is not just text based, but file based. http://smalltalk.gnu.org/ http://smalltalk.gnu.org/
gnaritas 9y ago
I'm well aware, I've programmed in Pharo daily for a decade; I Smalltalk for a living. What I said it true practically speaking, you're getting into implementation details that don't make a practical difference. Lisp and Smalltalk are both image based systems, but Smalltalk'ers actually work on the running live image all of the time, they aren't ever booting from the sources file nor are they ever editing it manually (excluding the one file based GNU Smalltalk), it's pared with a changes file to enable the IDE to expose the current source of a method but those are hidden implementation details whereas I'm talking about the abstraction presented to the programmer. Lispers "can" do this as well, and sometimes do, but Lisp has a much more standard general workflow of editing files that are then read and launched to create/patch a runtime image it's not the normal worflow to work entirely in the REPL which is essentially what Smalltalk'ers do. Consider the difference, what Smalltalker's see in their code browsers is a text version of what's actually running; if they had macros, which are nothing more than code generators, they'd be seeing is the macro expansion rather than the original source call to the macro. Certainly Lispers "can" do this as well, they can macro expand something to see what's actually running but as their primary mode is editing the original source they're accustomed to seeing the macro unexpanded, they might define an accessor like (name :accessor person-name :initform 'bill :initarg :name) And from experience know that an accessor is a getter, setter, and backing instance variable but they don't see those things in their editors, they just know they'll exist at runtime; whereas a Smalltalker is accustomed to looking at the runtime where he actually sees the getter, setter, and and backing instance variable. Macros just don't fit into Smalltalk; they've been added before, people keep trying it, and it just doesn't fit and so doesn't catch on.