4 ms·

I’ve always been curious about this. If you are not writing out the state of the program is there some convenient way to output parts of it? The article descr

I’ve always been curious about this. If you are not writing out the state of the program is there some convenient way to output parts of it? The article describes adding functions and refactoring data types but if you are doing that I’d assume you’d want those changes back in your source files.

rvense 4y ago
The REPL and editor are connected. You have a key command in your editor that sends the form you want to evaluate to the REPL, which is in a separate window or pane.
- medo-bear 4y ago
  when i write cl that is precisely what i do. i imagine this is the case with everyone - ie write code into the source file and send new bits to the repl
- mikelevins 4y ago
  Right, except that the repl isn't in another pane; a repl prompt is. Part of the confusion on this point is thinking that the prompt is the repl. It isn't. It's a UI for the repl. The repl is the process that reads, evaluates, and prints, then loops back to do it again. Nothing about a repl requires there to be a prompt, and not all UIs for repls have them. Interlisp and Smalltalk have relied mainly on promptless UIs for their repls since the 1970s. When working with Common Lisp, the main UI I use is an Emacs editor buffer and the key bindings that send input directly to the repl (bypassing the prompt). Typing at the prompt is the exception rather than the rule, and I could get along fine if I didn't bother to load the slime-repl contrib that provides it.
  - xkriva11 4y ago
    Yes, the evaluation of the code needs to be possible from everywhere. From the REPL window, the code editor, the debugger, and the inspector... Any code you select should be possible to evaluate in place. It is more than four decades old obvious basic idea, and I do not understand why almost everybody ignores it.
dunefox 4y ago
> I’d assume you’d want those changes back in your source files Not an expert, but your changes never 'leave' your source files. You iterate by changing the code in the file, sending it to the image/compiler, and repeat. There's no need for "getting code back into the files".
mikelevins 4y ago
They always were in my source files. Nearly all of the text I type in a Lisp project is in a source file that is managed by a revision-control system. That's the way I've worked with Lisp systems for more than thirty years. I send my changes to the repl with the stroke of a key. Working with a repl doesn't necessarily mean typing text at a prompt. The prompt isn't the repl; it's just a particular UI for the repl. Smalltalk systems do tend to store edits in the memory image (though they also write them automatically to a changes file and a sources file, so they aren't lost if you blow away your working image). Smalltalkers generally prefer to work in the image and treat text files as a serialization format for exchanging code and data. But normally there's no question of getting "changes back in your source file" because they were always in your source file, or its equivalent, from the start.
igouy 4y ago
> … is there some convenient way to output parts of it? The old ways — "Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users. … The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file." 1984 Smalltalk-80 The Interactive Programming Environment page 461 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... The somewhat less old way — https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=envy+developer&printsec=frontcover https://www.google.com/books/edition/Mastering_ENVY_Develope...

rvense 4y ago

The REPL and editor are connected. You have a key command in your editor that sends the form you want to evaluate to the REPL, which is in a separate window or pane.

medo-bear 4y ago
when i write cl that is precisely what i do. i imagine this is the case with everyone - ie write code into the source file and send new bits to the repl
mikelevins 4y ago
Right, except that the repl isn't in another pane; a repl prompt is. Part of the confusion on this point is thinking that the prompt is the repl. It isn't. It's a UI for the repl. The repl is the process that reads, evaluates, and prints, then loops back to do it again. Nothing about a repl requires there to be a prompt, and not all UIs for repls have them. Interlisp and Smalltalk have relied mainly on promptless UIs for their repls since the 1970s. When working with Common Lisp, the main UI I use is an Emacs editor buffer and the key bindings that send input directly to the repl (bypassing the prompt). Typing at the prompt is the exception rather than the rule, and I could get along fine if I didn't bother to load the slime-repl contrib that provides it.
- xkriva11 4y ago
  Yes, the evaluation of the code needs to be possible from everywhere. From the REPL window, the code editor, the debugger, and the inspector... Any code you select should be possible to evaluate in place. It is more than four decades old obvious basic idea, and I do not understand why almost everybody ignores it.

dunefox 4y ago

> I’d assume you’d want those changes back in your source files Not an expert, but your changes never 'leave' your source files. You iterate by changing the code in the file, sending it to the image/compiler, and repeat. There's no need for "getting code back into the files".

mikelevins 4y ago

They always were in my source files. Nearly all of the text I type in a Lisp project is in a source file that is managed by a revision-control system. That's the way I've worked with Lisp systems for more than thirty years. I send my changes to the repl with the stroke of a key. Working with a repl doesn't necessarily mean typing text at a prompt. The prompt isn't the repl; it's just a particular UI for the repl. Smalltalk systems do tend to store edits in the memory image (though they also write them automatically to a changes file and a sources file, so they aren't lost if you blow away your working image). Smalltalkers generally prefer to work in the image and treat text files as a serialization format for exchanging code and data. But normally there's no question of getting "changes back in your source file" because they were always in your source file, or its equivalent, from the start.

igouy 4y ago

> … is there some convenient way to output parts of it? The old ways — "Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users. … The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file." 1984 Smalltalk-80 The Interactive Programming Environment page 461 https://rmod-files.lille.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr... The somewhat less old way — https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=envy+developer&printsec=frontcover https://www.google.com/books/edition/Mastering_ENVY_Develope...