Talk:Read–eval–print loop
This is the talk page for discussing improvements to the Read–eval–print loop article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
Attention needed?
[edit]What sort of attention is needed on this article exactly? — The Storm Surfer 00:28, 20 Jun 2005 (UTC)
- The attention that Fubar Obfusco already gave. --MarSch 14:03, 20 Jun 2005 (UTC)
- Thanks for the clarification :) — The Storm Surfer 18:11, 20 Jun 2005 (UTC)
I think there's a species of microtroll who go around posting "This article is inadequate" whines in little boxes all over Wikipedia.
The tragedy is, they don't seem to be capable of actually doing anything useful in their copious free time.
If there's anything wrong with this fine article, it's probably the overabundance of click-throughs for the ignorant. Anybody interested in REPL IDEs is likely to be pretty well informed on computation basics -- but don't tell the microtrolls that!
David Lloyd-Jones (talk) 06:59, 28 August 2014 (UTC)
As someone coming to this article with fresh eyes, I agree it needs attention. Why is there a "Lisp Specifics" section that's nearly half the entire article? Who cares so much about LISP in particular? Among modern readers I would expect the most familiar/useful REPL to know about would be Python, which is barely mentioned. Discussion of REPLs in other modern languages like C#, Lua, JavaScript, etc. would all merit more space than LISP -- almost nobody is coming to the REPL article to learn "how to implement a REPL in LISP"; that content belongs on a LISP page, if anywhere. As written, the article gives the impression that a REPL is primarily a feature of LISP (and yet something that you as a LISP user have to implement yourself). Wiked120521 (talk) 14:21, 23 July 2023 (UTC)
- REPL is Lisp jargon that describes a command loop that calls the Lisp functions read, eval, and print. In Lisp, it is usually literally implemented that way. The term drifted to other languages whose implementations usually work differently, but it still refers back to Lisp. 2601:644:8501:AAF0:0:0:0:9BB0 (talk) 09:23, 11 July 2024 (UTC)
External links are poor
[edit]They seem to be two rarely used implementations of REPL. --Paddy (talk) 03:37, 15 January 2008 (UTC)
History
[edit]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)
Disproportionately large listing of REPLs
[edit]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)
C# REPL?
[edit]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)
Command shells are not REPLs
[edit]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)
- 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)
- I removed the sentence which included Unix shells as an example.-- era (Talk | History) 04:38, 25 April 2017 (UTC)
Postscript REPL
[edit]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)
REPLs vs. Shells vs. CLIs vs.
[edit]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)