3 ms·

I'm not getting it. How is this different from REPL mode in python, swift, or java? (There was even a REPL for Java 1.1.) Both the javac and eclipse compiler

by w10-1 3y ago

I'm not getting it. How is this different from REPL mode in python, swift, or java? (There was even a REPL for Java 1.1.) Both the javac and eclipse compilers have incremental compilation, so they save state and do only the necessary updates -- and provide effective feedback at each step. One interesting project would be to use an incremental linker with clang/swift. For human-interactive programming, the key feature is not speed of execution (or really compilation/build), but the clarity of the feedback and code-assist. IDE's are growng by leaps and bounds in content-assist features, and shell languages have blossomed of late by supporting type-completion almost as well as IDE's. For interactive use, type-inference in the language would seem to be a key requirement, and that means a robust type system, likely reduced to a constraint solving algorithm. (Has anyone has made one of those work in an incremental mode?) Finally, for ground-up or semantic prototyping, I would think a good way to try a new language/compiler combination would be Haskell, where people are starting to support incremental compilation. Here pandoc could be an interesting code base because it interprets multiple (markup and document) languages with the same AST. (Which itself suggests the investigating implementations for DSL's...) So the article would seem to ignore longstanding work streams in this space, to focus on the wrong features, and not to consider some relevant alternatives. So... it's easy to miss the forest for the trees? I must be missing something...

chubot 3y ago
I'm not the author, but my impression is that he wanted a single compiler that both compiles fast and generates fast code. I think it's a good goal, although if you take into account total engineering effort, my suspicion is that having a separate interpreter and a compiler is an accepted (if not common) solution for that reason. I think you're saying you don't need to compile fast to be interactive, because you can just use a slow compiler on tiny snippets of code, and patch them in. That seems like a fair point. (Python doesn't count, because it doesn't run fast, but Swift probably does. As far as I know the Swift playgrounds use the compiler at runtime. Java doesn't fit the requirements based on "predictable, explainable performance". You can of course quibble with that requirement) I do wish every language had a REPL and a compiler. And the interaction with language design is definitely worth exploring. I think Java and Swift have the tech, but I never really hear about people using them interactively, maybe because the languages themselves aren't great for typing in. (as opposed to R or shell or Lisp; Python could do better here too)
crabbone 3y ago
Neither Python nor Java have REPL, or can have it in principle. The "L" in REPL stands for "loop". I.e. what you print, you should be able to feed back into R (read). This is the whole point of this concept, and that's what this acronym means. The term you are looking for is "interactive shell". There's no need to modify existing terminology -- you are only confusing yourself and others.
- dragonwriter 3y ago
  > Neither Python nor Java have REPL, or can have it in principle Python certainly can have it in principle; its true that there are structures that where __repr__() doesn't feed back — that’s true in most Lisps for certain things, like recursive structures, too — but, too the extent that is worse than Lisp, that’s not an “in principle” limit. Now, its true that the default Python interactive shell does not make it easy to distinguish between side effect printing and evaluation results, and worse yet (for use as a REPL) swallows rather than displaying None when it is a result, but “the default interactive shell is not a REPL” is very different than “Python cannot have a REPL in principle”.
  - crabbone 3y ago
    Again, Python cannot have REPL in principle because like half of the language isn't even printable... you don't have anything to attach your __repr__() to. Most Python code either doesn't produce any values worth evaluating further (i.e. None) or produces values that are impossible to convert back to executable code (a lot of the stuff in the "standard" library produces non-actionable "decoration" style renderings, eg.: >>> import socket >>> socket.socket() <socket.socket fd=3, family=2, type=1, proto=0, laddr=('0.0.0.0', 0)> You'd have to rewrite over half of the "standard" library to make it print something reasonable, and why would you at that point call the resulting language "Python"?

by w10-1 3y ago

chubot 3y ago

I'm not the author, but my impression is that he wanted a single compiler that both compiles fast and generates fast code. I think it's a good goal, although if you take into account total engineering effort, my suspicion is that having a separate interpreter and a compiler is an accepted (if not common) solution for that reason. I think you're saying you don't need to compile fast to be interactive, because you can just use a slow compiler on tiny snippets of code, and patch them in. That seems like a fair point. (Python doesn't count, because it doesn't run fast, but Swift probably does. As far as I know the Swift playgrounds use the compiler at runtime. Java doesn't fit the requirements based on "predictable, explainable performance". You can of course quibble with that requirement) I do wish every language had a REPL and a compiler. And the interaction with language design is definitely worth exploring. I think Java and Swift have the tech, but I never really hear about people using them interactively, maybe because the languages themselves aren't great for typing in. (as opposed to R or shell or Lisp; Python could do better here too)

crabbone 3y ago

Neither Python nor Java have REPL, or can have it in principle. The "L" in REPL stands for "loop". I.e. what you print, you should be able to feed back into R (read). This is the whole point of this concept, and that's what this acronym means. The term you are looking for is "interactive shell". There's no need to modify existing terminology -- you are only confusing yourself and others.

dragonwriter 3y ago
> Neither Python nor Java have REPL, or can have it in principle Python certainly can have it in principle; its true that there are structures that where __repr__() doesn't feed back — that’s true in most Lisps for certain things, like recursive structures, too — but, too the extent that is worse than Lisp, that’s not an “in principle” limit. Now, its true that the default Python interactive shell does not make it easy to distinguish between side effect printing and evaluation results, and worse yet (for use as a REPL) swallows rather than displaying None when it is a result, but “the default interactive shell is not a REPL” is very different than “Python cannot have a REPL in principle”.
- crabbone 3y ago
  Again, Python cannot have REPL in principle because like half of the language isn't even printable... you don't have anything to attach your __repr__() to. Most Python code either doesn't produce any values worth evaluating further (i.e. None) or produces values that are impossible to convert back to executable code (a lot of the stuff in the "standard" library produces non-actionable "decoration" style renderings, eg.: >>> import socket >>> socket.socket() <socket.socket fd=3, family=2, type=1, proto=0, laddr=('0.0.0.0', 0)> You'd have to rewrite over half of the "standard" library to make it print something reasonable, and why would you at that point call the resulting language "Python"?