When I evaluate a reporter expression in the script area I get a pop-up balloon with the result value. If there was a way (by some UI gesture) for me to make that value a persistent and 1st class thing on the GUI, I could drag it into another expression, and so on. Reporter results that are Snap's 2D lists already have an Open In Dialog option that persists the list / table in the GUI, but I cannot then drag n' drop or otherwise use that value, just look & close.
Example showing persisted table & un-persisted popup, neither of which can be further used.
REPLs support such exploratory use by naming each value so you can subsequently use that name. In Snap's GUI the equivalent might be to allow the user to persist some values on the GUI, and then drag them to use them further. Ideally such a value would show some visual connection to the expression that spawned it, at least when it is selected.
(Alternately Snap could automatically create REPL-like variables, but that would get confusing without a REPL's linear flow).
Today's solution is to duplicate the spawning expression & drag that around instead. Or you could manually create a variable. It works, but you wouldn't want a REPL where that was your only option.
[Further out: persisting such values might in the future enable other interactive operations on them, like drill-down].
Desmond, I'm getting tired of saying "we aren't teaching HtDP and we aren't implementing Racket."
Having said that, @cycomachead has talked about making it possible to drag things out of balloons. (I think "first class" is not technically what you mean here.)
This suggestion was just to further ease expression-oriented usage and FP, which Snap already does and which I think you & Jens broadly agree with. Nothing to do with HtDP or Racket, and no worries if it does not fit in with the Snap vision.
One elaboration: due to side effects, dragging a balloon result into an input slot is semantically different from duplicating the expression into that slot & executing it again (though this is not my main motivation).
I'll admit I want kids to experience more of the incredible liveness of my (ancient) Symbolics Lisp Machine & (less ancient) Smalltalk days, where everything was clickable & inspectable anytime. It's why I like Snap.
Yup, Jens will agree with this. It's less of a principle for me, especially since there's a high cost: having to reinvent DOM features in Morphic. It took forever to get copy and paste in text boxes, and the current such problem is that it's taking forever to get screen reader support.
But I agree that I often want to use the result of a computation in another computation. And, as I said, Michael has suggested that he's interested in implementing it.
What I want that's related is the ability to drag script pics and result pics into comments, to enable better help screens for custom blocks.
Sorry for side-track, but ... How is that manual written / built? In particular, is there a way to get it into GitHub for easier PRs? I could not find it and was interested in trying to get the pdf TOC properly nested / indented.
Same question for help on custom blocks. If the XML for custom blocks was on GitHub, then could PRs be used to grow the help? My guess is the community will pitch in.
Ugh, this is problematic. It's written in MS Word, and the source lives on my laptop, although when there's a new release the .docx is now in the repo as well as the .pdf. Unfortunately, my old computer died, and the new computer can't run my old copy of Word, and the new version of Word that it can run has changed in ways that totally mess up the document -- pictures in the wrong place, etc. So it's going to take some struggle to get to where even I can edit it, let alone other people.
Additionally, people want a searchable HTML version, and I haven't even started thinking about that yet. And also, I wish I'd started in TeX rather than Word, although when I started, I didn't have access to a WYSIWYG environment for TeX and it was a royal pain to get pictures positioned as wanted. I wish it both because it's free software and because in the final analysis it provides much finer control over positioning, e.g., with respect to widows. (I keep wishing I could say \goodbreak in Word!) And because TeXInfo would solve the HTML problem.
And, to be honest, I've instinctively been a little propertarian about the manual; I kinda want to write every word of it. But of course keeping it up to date would be much easier with a Github repo.
I'm a week behind on everything, but eventually I'll get this whipped into shape.
I emailed you a zip with a Lyx / TeX file I made from the docx. I used pandoc to extract the images embedded in the docx into a separate folder & re-link docx to them, then imported the result into Lyx. Most images came across, some did not, though I have not examined the result closely. LyX ~ WYSIWYG TeX
