I'm a huge fan of REPLs (Read-Eval-Print Loops). I always find programming languages that provide a REPL to be more friendly. A REPL is my favorite way to try out new idioms in a programming language or to explore the problem space of a new task.
ie.icn ("Icon Evaluator") and the older qei.icon aren't true REPLs but they give one much of the same feel. However, they don't work well if one wants to use Unicon extensions, such as the [: ... :] list comprehension. But the fix is simple.
Here's a simple experiment assuming ie is on your $PATH. (For the following I'll assume a Unix-like OS. Windows cmdlines should be similar):
1) First make sure there's no ._ie_tmp.icn in your working directory
2) Start ie and enter one line [: 1 to 10 :]
(Even though that is valid Unicon, ie will have generated errors. That's because it's using icont, which doesn't understand the extension.)
3) Drop into the shell and verify that there's a file named ._ie_tmp.icn. If you look in the file, you'll find the line that you entered, which icont doesn't like.
4) Try instead this command: unicon -s ._ie_tmp.icn -x
You should see the expected list.
Why doesn't /trunk/unicon/uni/progs/ie.icn have this change? Are REPLs considered too "old fashioned" to bother with?
Thanks for providing an interesting programming language,
Jonathan D Johnston
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Icon's designers were well aware of REPLs associated with pure interpreted languages, but they were power users and that feature was not a priority for them. The subset REPL's you mention can be helpful for learning and experimentation, but most serious coding happens with an edit-compile-execute loop. These are not really mutually exclusive, but REPLs that don't persist or preserve code that is written are a turn-off for me. Also, there is a perception, right or wrong, that a subset REPL is not as useful unless it supports most or all of the language.
Doing the whole Unicon language in ie.icn (should it be called ue.icn now?) would be a big job. However, ie.icn could pretty easily be extended to support a much larger subset of Unicon, and I am in favor of your suggestion in principle. Perhaps you could make the changes and send us a pull request, or sweet talk Bill Mitchell into doing it. Occasionally I can get students to do projects like this for free, but usually I have to pay them something.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good morning One and All on this beautiful spring day,
Can the debugging system be repurposed to give a full language
capability for a REPL? I suggest that the REPL could build an
appropriate file with its own main() that is then compiled by the unicon
compiler and loaded by the same processes as the debugger to give a user
experience of a "normal" REPL.
How hard would this be? What complications would we need to consider?
Especially for semantics of already run code.
regards
Bruce Rennie
Mod edit to remove some reply-to
Last edit: Brian Tiffin 2019-09-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-09-26
Thank you, Prof. Jeffery, for taking my suggestion seriously. I have done PRs (pull requests) for other projects but I don't plan to use Unicon on Windows, so I wouldn't be able to test the Windows-related changes. Besides, from other posts in this thread, you seem to have identified the needed changes -- if you can get git to cooperate. :)
I won't try to convince you that REPLs are great, but your experience with them sounds like what I remember when I first tried REPLs in the Dark Ages. Many of today's REPLs save the user input. Some (e.g., IPython) save both input and output. For those on Unix-like systems (even Cygwin, IIUC), there's rlwrap which works great with most console-based REPLs. Indeed, I use rlwrap with ie. Command-line recall & editing is almost as important as persistence for me, which most of today's REPLs (that I have tried, anyway) provide &, of course, so do those that are rlwrap'ed.
With already proven command lines saved for me, I find they're easy to extract as the core of the program that I want. But, I'm aware that REPLs aren't everybody's cup of tea.
I look forward to seeing an ie (ue?) that works with Unicon,
Jonathan D Johnston
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The monitoring facilities could be used for part of what a REPL needs.. They provide a dynamic loading capability, but they do not provide any dynamic linking and they do not turn our runtime system's data structures into (slower) extensible/dynamic data structures like you would find in a Lisp interpreter.
Using load() to write a new ue.icn based on ie.icn might be fun. That would certainly push its limits, as it was designed for a different use case.
Clint
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As far as being a "match" to LISP or Scheme, I don't think we need this.
Unicon/Icon is such a different flavour of language that a REPL would
itself be also a different flavour. As an aside and yet still relevant
to the discussion of a REPL, I have been thinking about what is needed
to provide an initialisation clause to the global declarations in
Unicon. In a sense, this would be a function that the REPL could require
and it should be feasible to incorporate any such functionality back
into the Unicon compiler.
regards
Bruce Rennie
Mod edit to remove some reply-to
Last edit: Brian Tiffin 2019-09-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An ue program would need to keep a history of variable assignments and state in a multi-tasking co-expression space, and that would likely just require keeping an active state in the temporary program with new lines added for recompilation as the session progressed. Which now having typed that, would probably be harder than it sounds to get correct, but not impossible.
Have good, make well,
Blue
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bill Mitchell sez (ha ha) that "it should be a snap" to go into ie.icn and find the places where icont is being invoked and replace them with unicon. I looked, and he might be right. I went ahead and popped it in and it worked fine for simple examples anyhow. I would commit the changes but git is giving me nonsensical error messages, so I will have to defer, sorry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Git wouldn't let me push because I was out of date, so I did a pull, but the pull failed with some message about my terminal being too dumb, and now I am in some kind of limbo with an unfinished merge, where I don't know what is needing to merge or how to merge it. Can't see diffs, can't pull, can't commit, etc. Too busy to look into it much.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have deleted my previous git clone of unicon/ and re-cloned from scratch, which was a very quick operation. However, I neglected to save my modified version of ie.icn, I will regenerate it when I get around to it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found this really cool project for creating repls out of compiled languages and managed to get it working with Unicon here https://github.com/BenBrock/reple . While it's not the best solution, it is one that is satisfactory for me
👍
1
Last edit: Margret 2022-04-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm a huge fan of REPLs (Read-Eval-Print Loops). I always find programming languages that provide a REPL to be more friendly. A REPL is my favorite way to try out new idioms in a programming language or to explore the problem space of a new task.
ie.icn("Icon Evaluator") and the olderqei.iconaren't true REPLs but they give one much of the same feel. However, they don't work well if one wants to use Unicon extensions, such as the[: ... :]list comprehension. But the fix is simple.Here's a simple experiment assuming
ieis on your $PATH. (For the following I'll assume a Unix-like OS. Windows cmdlines should be similar):1) First make sure there's no
._ie_tmp.icnin your working directory2) Start
ieand enter one line[: 1 to 10 :](Even though that is valid Unicon,
iewill have generated errors. That's because it's usingicont, which doesn't understand the extension.)3) Drop into the shell and verify that there's a file named
._ie_tmp.icn. If you look in the file, you'll find the line that you entered, whichicontdoesn't like.4) Try instead this command:
unicon -s ._ie_tmp.icn -xYou should see the expected list.
Why doesn't
/trunk/unicon/uni/progs/ie.icnhave this change? Are REPLs considered too "old fashioned" to bother with?Thanks for providing an interesting programming language,
Jonathan D Johnston
Icon's designers were well aware of REPLs associated with pure interpreted languages, but they were power users and that feature was not a priority for them. The subset REPL's you mention can be helpful for learning and experimentation, but most serious coding happens with an edit-compile-execute loop. These are not really mutually exclusive, but REPLs that don't persist or preserve code that is written are a turn-off for me. Also, there is a perception, right or wrong, that a subset REPL is not as useful unless it supports most or all of the language.
Doing the whole Unicon language in ie.icn (should it be called ue.icn now?) would be a big job. However, ie.icn could pretty easily be extended to support a much larger subset of Unicon, and I am in favor of your suggestion in principle. Perhaps you could make the changes and send us a pull request, or sweet talk Bill Mitchell into doing it. Occasionally I can get students to do projects like this for free, but usually I have to pay them something.
Good morning One and All on this beautiful spring day,
Can the debugging system be repurposed to give a full language
capability for a REPL? I suggest that the REPL could build an
appropriate file with its own main() that is then compiled by the unicon
compiler and loaded by the same processes as the debugger to give a user
experience of a "normal" REPL.
How hard would this be? What complications would we need to consider?
Especially for semantics of already run code.
regards
Bruce Rennie
Mod edit to remove some reply-to
Last edit: Brian Tiffin 2019-09-17
Thank you, Prof. Jeffery, for taking my suggestion seriously. I have done PRs (pull requests) for other projects but I don't plan to use Unicon on Windows, so I wouldn't be able to test the Windows-related changes. Besides, from other posts in this thread, you seem to have identified the needed changes -- if you can get git to cooperate. :)
I won't try to convince you that REPLs are great, but your experience with them sounds like what I remember when I first tried REPLs in the Dark Ages. Many of today's REPLs save the user input. Some (e.g., IPython) save both input and output. For those on Unix-like systems (even Cygwin, IIUC), there's
rlwrapwhich works great with most console-based REPLs. Indeed, I userlwrapwithie. Command-line recall & editing is almost as important as persistence for me, which most of today's REPLs (that I have tried, anyway) provide &, of course, so do those that arerlwrap'ed.With already proven command lines saved for me, I find they're easy to extract as the core of the program that I want. But, I'm aware that REPLs aren't everybody's cup of tea.
I look forward to seeing an ie (ue?) that works with Unicon,
Jonathan D Johnston
Bruce,
The monitoring facilities could be used for part of what a REPL needs.. They provide a dynamic loading capability, but they do not provide any dynamic linking and they do not turn our runtime system's data structures into (slower) extensible/dynamic data structures like you would find in a Lisp interpreter.
Using load() to write a new ue.icn based on ie.icn might be fun. That would certainly push its limits, as it was designed for a different use case.
Clint
Good eveing Clinton,
As far as being a "match" to LISP or Scheme, I don't think we need this.
Unicon/Icon is such a different flavour of language that a REPL would
itself be also a different flavour. As an aside and yet still relevant
to the discussion of a REPL, I have been thinking about what is needed
to provide an initialisation clause to the global declarations in
Unicon. In a sense, this would be a function that the REPL could require
and it should be feasible to incorporate any such functionality back
into the Unicon compiler.
regards
Bruce Rennie
Mod edit to remove some reply-to
Last edit: Brian Tiffin 2019-09-17
There is a small
loadbasedevalfunction experiment in the UP docs, http://btiffin.users.sourceforge.net/up/programs.html#evalMixed with the
readlinetweak to the currentie, http://btiffin.users.sourceforge.net/up/programs.html#ie-modified-for-readline anueREPL could be quite handy. It would cover almost 100% of the compile-link-go features available to unicon, and have a pleasant intepreter command line recall.An
ueprogram would need to keep a history of variable assignments and state in a multi-tasking co-expression space, and that would likely just require keeping an active state in the temporary program with new lines added for recompilation as the session progressed. Which now having typed that, would probably be harder than it sounds to get correct, but not impossible.Have good, make well,
Blue
Bill Mitchell sez (ha ha) that "it should be a snap" to go into ie.icn and find the places where icont is being invoked and replace them with unicon. I looked, and he might be right. I went ahead and popped it in and it worked fine for simple examples anyhow. I would commit the changes but git is giving me nonsensical error messages, so I will have to defer, sorry.
What error are you getting?
Git wouldn't let me push because I was out of date, so I did a pull, but the pull failed with some message about my terminal being too dumb, and now I am in some kind of limbo with an unfinished merge, where I don't know what is needing to merge or how to merge it. Can't see diffs, can't pull, can't commit, etc. Too busy to look into it much.
I have deleted my previous git clone of unicon/ and re-cloned from scratch, which was a very quick operation. However, I neglected to save my modified version of ie.icn, I will regenerate it when I get around to it.
I found this really cool project for creating repls out of compiled languages and managed to get it working with Unicon here https://github.com/BenBrock/reple . While it's not the best solution, it is one that is satisfactory for me
Last edit: Margret 2022-04-26