Open schanzer opened 5 months ago
For item 3, highlighting error locations, see: https://github.com/brownplt/code.pyret.org/pull/502
A couple other topics:
The current Pyret blocks are mostly expression-oriented, while Pyret has for loops and multi-line statement contexts that don't seem to be supported yet in blocks. I assume there's some work on our side to tell Snap which holes support that and to add more block types?
Hiding Pyret syntax: the blocks environment ends up not looking a lot like Pyret syntax (there's no end
, quotation around strings is omitted, etc.). So it seems like there are a few options:
As an aside, note that Pyret for
loops are not actually statements! They're genuine expressions. E.g.:
squares = for map(i from range(0, 5)): i * i end
check:
squares is [list: 0, 1, 2 * 2, 3 * 3, 4 * 4]
end
In Pyret, for
is just a very fancy and roundabout way of writing lambda
, sorry-not-sorry. (-:
Of course, and thank you for the callout as I was being very imprecise with my language.
What I mean to say is not about semantics but instead:
Lexical syntax As expressions get longer, Blocks world shows them on a single line until it runs out of space, at which point it breaks the line and indents just enough to leave the expression inside the circle of its parent:
The question here is whether this automatic line breaking is sufficient and understandable to the intended audience as you make more and more complex nested expressions for things like the flag assignment.
Syntax:
But more importantly, each of the "holes" today only accepts a single expression, and there is no equivalent of Scheme's begin
(which is implicit in many contexts in Pyret), so making local definitions and then using them is impossible, whereas it is frequently used in Pyret:
This problem maybe does not arise: is blocks for a subset of Pyret that doesn't need nested definitions or the other cases where you want implicit begin
?
--
PS: incidentally, two other things that may need adding: today in blocks world, functions can only take a single argument and there is no support for infix operators like is
.
Adam, I so appreciate your thoughtful approach to design. A few responses:
(3a - keep in mind that it's always easier to add a feature than remove or change it, so I decided to punt on adding Pyret syntax for the first release.)
Emmanuel sent over this file as a benchmark for all the bits of Pyret that need to work in blocks world for it to be demoable.
I spent some time tonight auditing everything in that file and figuring out which bits of it do and don't work in blocks today, so we have a checklist on what is left to figure out.
image-url
scale(n, img)
else if
, and don't allow alignment, so they're not quite as easy to understand as the text)
use context shared-gdrive
: this seems to work, but locally I can't access files on real gdrive.
shared-drive
to work even when its arguments start with digitsload-spreadsheet
(it relies on that file)cat_row = row-n(...)
). I think this might be straightforward to add to the language definition.var["key"]
, which the sample file does a lot (e.g. r["species"] == "dog"
)load-table
: all args are treated as strings, which is not what we need.
"a, b, c"
), whereas we actually want a list of symbols (a, b, c
). (I think this is fixable in the language definitions.)
This block is translated into the below code:
load-table: "a, b, c"
source: "b".sheet-by-name("a", true)
end
image-scatter-plot
and other of the image functions have a similar issue where arguments are interpreted as strings rather than values, so you can't refer to variables. (I think this is fixable in the language definition.) This block is translated into the below code:
image-scatter-plot("a","b","d",animal-img)
row-n
and many other functions are available in the sidebar globally, even though they aren't defined unless you use the right context file. In a perfect world, perhaps we would detect the context file and its exports and only show the blocks for functions that are actually available. For now, do we want any kind of handling, like nicer error messages, if you pull out one of the sidebar blocks but it isn't defined in the context you loaded?transpile.xml
? I'm not sure if I should edit those directly or if they're auto-generated and I should edit them from elsewhere.If you want to deploy I'm happy to merge to horizon
and you can test with the Google keys + setup at https://pyret-horizon.herokuapp.com
@asolove from inside the snap submodule, you should be able to run a (full-featured) snap instance without Pyret at all. Dragging transpile.xml
into the block palette will load the transpiler, and you can edit, add, or remove features as you see fit. Once you're done, you'll want to export the blocks back to XML.
I found it most useful to keep the original file open in one window, then compare it to the exported transpiler and manually copy over what I wanted. There are some subtleties to the machine-generated XML that will bite you if you replace the file whole-cloth. ;)
Happy to sit down on Zoom with you, if you like!
Now that the pcardune-blocks branch has been merged into horizon, we need a tracking issue to keep tabs on the remaining work.