Hey thaddeus, the main issue I run into with something like this is that sessions are very resource-intensive on the server side. As it stands I get to reclaim session resources right when people leave, and still Try Arc gets overloaded and requires manual restart about once every two weeks.
Ah, but the solution seems so straightforward now: just put sessions to sleep. Every session can be stored efficiently as a list of expressions, and then re-awakened by running the expressions through a new REPL before showing it to the user.
If the REPL session takes any input, including by measuring timings or generating random numbers, it won't be deterministically recreated by a list of commands. And what if I want a fresh REPL?
When I go to Try Arc, I imagine there's a single REPL per window/tab, which goes away as soon as I leave the page. So I think it would be cool to be able to copy out transcripts (without spurious hyphens showing up :-p ) and load/paste Arc libraries, but that's all the power I hope for.
If you're looking for more of a server-side challenge (and more of a productivity site rather than a tutorial :-p ), it would be awesome to have a user account system that lets me paste a bunch of Arc utilities and load them automatically every time I start a REPL.
I'm still a bit suspicious about abstraction leaks in the concept of "save this session." I'd prefer to think in terms of a library pastebin, where I may choose to turn my REPL session into a library but I'm not misled into thinking it'll preserve more about my session than the raw code I entered.
For what it's worth, managing user logins and passwords is a very easy business with WordPress! The challenge would be figuring out how to interface those WordPress user accounts with REPL functionality.
If implemented like HN x-id's you could just refresh or reload the page in order to get a new session. And like HN one could just expire a stored session after x minutes without being used.
Note though: Originally when I posted the session-id idea I was thinking tryarc was only one session with many threads, where each session-id would really just point to its own namespace. Had this been the case it would just be the functions and variables being stored in memory. And then threads/session-ids/namespaces (whatever) could be spun up or down and managed in a myriad of ways.
You: "If implemented like HN x-id's you could just refresh or reload the page in order to get a new session."
That's the behavior I expect, but then I also expect to get a new session if I navigate somewhere and click the back button. If the back button case does not give me a new REPL, I don't see why refreshing the page would.
