Talk:Read–eval–print loop

message: What sort of attention is needed on this article exactly? — The Storm Surfer 00:28, 20 Jun 2005 (UTC)
replies: text: The attention that Fubar Obfusco already gave. --MarSch 14:03, 20 Jun 2005 (UTC)
replies: text: Thanks for the clarification :) — The Storm Surfer 18:11, 20 Jun 2005 (UTC)
thread_title:  Attention needed? 

message: They seem to be two rarely used implementations of REPL. --Paddy (talk) 03:37, 15 January 2008 (UTC)
thread_title: External links are poor

message: Has anyone got any historical links or information for REPLs? Who wrote the first REPL?   — Preceding unsigned comment added by 94.245.127.12 (talk) 09:20, 20 October 2011 (UTC)
thread_title: History

message: One solution would be to link to Rosetta Code's relevant task demonstrative task, where a list and demonstration of REPL environments may be found. Disclaimer: Rosetta Code is my site, so I can't really make that addition with a full appearance of neutrality. However, I think it would help clean up the listing. (Paddy's an active member, too, but I don't think that happened until about mid-2009. Funny seeing him here, though. :)) --Short Circuit (talk) 22:33, 11 January 2010 (UTC)
thread_title: Disproportionately large listing of REPLs

message: One could argue that the immediate window in Visual Studio is an example of a REPL.  Does this count?  —Preceding unsigned comment added by BrentRockwood (talk • contribs) 19:22, 1 February 2010 (UTC)
thread_title:  C# REPL? 

message: I think the list is too long for the simple reason that command shells are not, in general, REPLs. The defining characteristics of a REPL are,
primarily, that what you type is an expression to be evaluated and what gets printed is the resulting value, and
secondarily, that the REPL is an interface to a programming language's execution engine. That's the semantic model.
In a command shell, otoh, what you type is a command which the shell executes, and what it prints is whatever output the command produced, if any.
A shell is a command intepreter. You don't think of it as an "interface to the shell's language execution engine" (though technically it is that, of course).
The distinction is semantic, but significant.
I also feel that the list should be divided to distinguish between "native" REPL environments (such as in Lisp) and those cases where REPL functionality is available via an add-in (such as in C#).  —Preceding unsigned comment added by 65.218.84.25 (talk) 13:58, 29 July 2010 (UTC)
replies: text: A shell, such as bash can easily be thought of as having an "execution engine" that takes your input and decides whether to execute some internal code to produce an output, or, can find an executable on disc and call that. Input 'ls' and the bash internal command will do its thing; input '/bin/ls' and the external binary will be executed to do its thing. I am not sure if it is standard in Tcl, but I have been in a few Tcl REPL's that would also execute external commands if given an internal command that it did not recognize. I would not want to hive-off what you would call command shells as a separate category. --Paddy (talk) 05:56, 30 July 2010 (UTC)
replies: text: I removed the sentence which included Unix shells as an example.-- era (Talk | History) 04:38, 25 April 2017 (UTC)
thread_title: Command shells are not REPLs

message: I believe Postscript interactive executive is a sort of REPL (not merely a shell), maybe more a "REL" (REPL with no Print) : You type a PS construct and the result is pushed on the operand stack, without being displayed. Displaying the result implies popping it with the '=' or '==' operators. The entire stack can be also be displayed, undisturbed ('pstack' or 'stack').  — Preceding unsigned comment added by 151.66.124.73 (talk) 23:12, 7 July 2011 (UTC)
thread_title:  Postscript REPL 

message: A REPL is a special type of shell, a form of an interactive toplevel. It is usually not line oriented, thus it is not a command line interface. Lisp is not line oriented. S-expressions are are not delimited by lines, but by a start and end parenthesis. The typical Lisp REPL does not read lines from input, but it reads s-expressions from input.
Let's look at the first paragraph:
A read–eval–print loop (REPL), also known as an interactive toplevel or language shell, is a simple, interactive computer programming environment that takes single user inputs (i.e. single expressions), evaluates them, and returns the result to the user; a program written in a REPL environment is executed piecewise. The term is most usually used to refer to programming interfaces similar to the classic Lisp machine interactive environment. Common examples include command line shells and similar environments for programming languages, and is particularly characteristic of scripting languages.[1]
A REPL does not need to be interactive (!). The first Lisp from McCarthy took expressions from punch cards as a batch job, read every expression, evaluated it, printed it to I/O and did that again until end of input. That's basically what every modern Lisp does, when it loads a Lisp file.
A REPL also does not need to be simple. Many Lisp systems have sophisticated REPLs with error handling, integrated debugger with multi-level debugger REPLs.
The term REPL in the Lisp world also does not usually refer to a classic Lisp Machine environment. Many Lisp systems had a typical REPL before and after Lisp Machines existed - Interlisp, Maclisp, ..., CLISP, SBCL, ...
Command line shells are usually not a REPL. A REPL is also not a characteristic of scripting language. Scripting languages often have interactive toplevels, but since most of them are not homoiconic, they don't use Read/Eval/Print like Lisp, where the REPL/toplevel reads a data structure and prints a datastructure.
Joswig (talk) 17:05, 12 October 2015 (UTC)
thread_title:  REPLs vs. Shells vs. CLIs vs.