shadow_7283 wrote:
Those are pretty limiting factors...
I think the one about these variable being separate from Scratch-type variables is actually a feature, not a bug. You want this because you're going to use computer-generated names. You're not going to computer-generate the name of a particular, fixed Scratch-type variable; you'll just use its orange blob. And this way, you don't have to worry about accidental conflicts in which the program happens to generate a name that you're using elsewhere in the program.
And if you want temporary variables, you just do this:
SCRIPT VARIABLES <old-dictionary> SET <old-dictionary> TO <dictionary> SET <dictionary> TO [NEW DICTIONARY] ... SET <dictionary> TO <old-dictionary>
where the "..." is the rest of your script.
The above isn't perfect because you can't use REPORT or STOP BLOCK/SCRIPT/ALL inside the script without restoring the old dictionary first. I guess we're still missing a few Logo features, namely macros and CATCH/THROW, that could be used to fix that. But it's just a matter of convenience; you can do the job by putting a SET <dictionary> TO <old-dictionary> in front of every REPORT and STOP.
Last edited by bharvey (2010-09-05 16:56:01)
Offline
@ bharvey
If you have a collection of 2 dozens of sprites each with 8 properties, you can store these data into a list (of list) and write 2 functions to SETSP and READSP the nth item of the nth line. This Operator reporter function then can be used in any script. This Global list acts like a kind of intersprite shared memory.
Offline
bharvey wrote:
The above isn't perfect because you can't use REPORT or STOP BLOCK/SCRIPT/ALL inside the script without restoring the old dictionary first.
I would write a block wrapper ("variable wrap (the (Block) block )" or something) which inserts a new dictionary, CALLs the block, restores the old dictionary, and returns the result of the call.
Last edited by nXIII (2010-09-05 21:21:21)
Offline
nXIII wrote:
I would write a block wrapper...
Yes, that'll work, but it requires two blocks per block, the one that calls your wrapper and the one that does the actual work. What you really want is a c-shaped wrapper... Oh! Duh!... No, wait, although that would currently work, it works because of a bug! You really want REPORT and STOP to end the block in which they appear, even if they're in the C-slot of a custom block. Consider the case of
FOR <i> = <1> TO <10>
IF [some condition on <i>]
REPORT <i>
REPORT [FALSE]
You don't want that little two-line inner script to report a value to FOR, and you don't want FOR to report a value to the custom block whose definition this is. You want the custom block to report the value.
I suppose we could have a right arrow at the end of the REPORT and STOP BLOCK blocks that would expand into a dropdown like the CALL//RUN ones with choices "from outer script" (the default) and "from innermost script" -- but I think that would confuse people. Instead we need CATCH and THROW, and you'd be able to CATCH stop and report in the wrapper block.
This exact subject came up for me just the other day! The sample FOR script above is a slight simplification of something I actually did in that hash table project posted earlier, and it didn't work, because the REPORT didn't end the block I was writing. (It does work if you STOP or REPORT in the C-slot of a primitive control block.) Then Shadow came up with a need that could be solved by not fixing the bug -- I did work that out earlier and then forgot that it applied to your version too -- so I filed a revised bug report asking for CATCH and THROW. Or maybe just CAREFULLY, which has two C-slots:
CAREFULLY
do-this
AND THEN
do-this-afterward-even-if-the-first-errors-or-stops
So then Shadow could
SET <old-dictionary> TO <dictionary>
SET <dictionary> TO [NEW DICTIONARY]
CAREFULLY
do-whatever
AND THEN
SET <dictionary> TO <old-dictionary>
and even if the do-whatever STOPs or REPORTs the right thing will happen.
Offline
bharvey wrote:
CAREFULLY
do-this
AND THEN
do-this-afterward-even-if-the-first-errors-or-stops
But I don't think "CAREFULLY ... AND THEN ..." is the right primitive. What if you want to know WHAT occurred during the "CAREFULLY" and do something with it? What if you want to do two different things depending on whether or not you got an error? What if you want to throw your OWN error?
Offline
nXIII wrote:
What if you want to do two different things depending on whether or not you got an error? What if you want to throw your OWN error?
Yeah, that's what CATCH and THROW do for you; they're more general than CAREFULLY. But they're also a bit harder to understand. I don't want to lose the Scratch audience over this!
Offline
bharvey wrote:
nXIII wrote:
What if you want to do two different things depending on whether or not you got an error? What if you want to throw your OWN error?
Yeah, that's what CATCH and THROW do for you; they're more general than CAREFULLY. But they're also a bit harder to understand. I don't want to lose the Scratch audience over this!
I know, but why not have CATCH and THROW in an obscure place (at the bottom) and put CAREFULLY in the tool package?
@fullmoon{ errors }
Last edited by nXIII (2010-09-06 13:54:10)
Offline
nXIII wrote:
@fullmoon{ errors }
Strings? Instances of some sort of Error/Exception primitive? I'm concerned because if you want to do anything more advanced than get the type of error, you would need to throw some sort of object to hold information such as a stack trace or a reference to another object. Of course, everybody could write their own Error classes, but that seems stupid to me
OH! What if you could do something like this:
throw "Can't Find My Toothbrush" with inputs "Reach","Magenta","Last Tuesday"
Then the catch clause could pick it up like this:
{ try { look for my toothbrush }catch (error) with arguments (brand)(color)(last use) <> { pop (2) Tic-Tacs and hope no one notices }
So the throw[] block lets you pass arguments the same way run[] does, and the catch clause of the try/catch construct lets you receive those arguments the same way the "the script" block does. However the problem is still sort of there if we can expect to catch more than one thing:
try { look for my toothbrush find matching socks }catch (error) with arguments (brand)(color)(last use) <> { say "Oh, no, I "+error+"!" if(error == "Can't Find My Toothbrush"){ pop (2) Tic-Tacs and hope no one notices } if(error == "Don't Have Any Matching Socks"){ stay in and watch ["QVC"] } }
I'll make a mockup if this is confusing...
I also think that we could probably find better names for try/catch/throw. They don't really make a lot of sense to begin with. I like Ruby's "rescue" clause, for instance.
Last edited by fullmoon (2010-09-06 15:49:02)
Offline
fullmoon wrote:
What exactly would be caught and thrown? Anything we want?
The basic idea of CATCH and THROW is that they take a text string input -- a bit like BROADCAST and WHEN I RECEIVE. CATCH is a C-shaped block, so it catches a use of the corresponding THROW within the script in the C-slot.
But CATCH <error> is recognized as a special case; in effect, any error condition does an implicit THROW <error> and only if the throw isn't caught do you get an error message or red halo or whatever.
And I think we'd also have CATCH <stop> that would catch both STOP BLOCK and REPORT.
Berkeley Logo has two more special cases: THROW <toplevel> is equivalent to STOP SCRIPT, and THROW <system> quits the program altogether.
But (@nXIII) in order to use these to implement CAREFULLY, we also have to invent macros -- a special kind of block that outputs a script that is then run in place of the call to the macro, in the caller's context. We need this so that CAREFULLY can catch a STOP or REPORT, carry out the exit script, and then redo the STOP or REPORT in place of the call to CAREFULLY.
I didn't boggle at putting all that control mechanism into Berkeley Logo, but there the design goal was definitely more "high ceiling" than "low floor" -- the target audience was high school and up.
We're almost at the point where I'd consider moving all our new blocks to a separate BYOB palette; then I wouldn't mind any level of complexity. In retrospect I think we turned a corner by inventing upvars, and then special forms. Before then, we didn't do anything that wasn't an automatic necessary consequence of having lambda and LIST, but we put in upvars and special forms to solve syntactic problems -- that is, we could have expressed the same computations without them, but not in the form that users expected (first FOR and then reporter IF/ELSE). Once you're playing the syntax game, CATCH/THROW and macros are obvious next steps. (Obvious, I mean, to someone familiar with Lisp history; you're not meant to feel bad if they don't seem obvious to you.)
Offline
fullmoon wrote:
I also think that we could probably find better names for try/catch/throw. They don't really make a lot of sense to begin with.
We're overlapping each other now...
CATCH and THROW do make sense if you consider the ordinary case in which it's a kind of signal that's being caught and thrown. The general purpose is nonlocal exit. For example, you're writing a video game and you're seven levels of procedure call deep when you discover that the user has won or lost. So you want to unwind all those calls and get back to the top level procedure that says "play again?"
REPEAT
CATCH <gameover>
PLAY GAME
ASK <play again?> AND WAIT
WHILE [[ANSWER] = <yes>]
For catching errors, we'd have an ERROR reporter that would report a list with various useful pieces of information about the most recent error. This could indeed be generalized, as you suggest, to allow optional inputs to THROW that could be retrieved after the CATCH.
Offline
bharvey wrote:
fullmoon wrote:
@bharvey
Now I feel like I need to try some Lisp! This should be fun.You can take my class online!
*looks at lessons*
4.4 hours
o_o
Offline
Lucario621 wrote:
4.4 hours
That's six separate lectures you're looking at! If you click on the little triangle, that category (functional programming) expands into six smaller categories -- not one per lecture; some of them are 5 minutes long and others 1.5 hours further subdivided.
Each actual lecture is 50 minutes long, and there are about 40 of them in the semester. (Three per week, 15 weeks, but there are holidays.)
EDIT: I'm not saying there isn't a lot there. My UCB students spend 3 hr/wk in lecture, 1.5 hr/wk in lab, 1.5 hr/wk in discussion, and an average (mode) of 4 hr/wk on homework = 10 hr/wk total. Just right, when you consider that being a full-time student is a full-time job (40 hr/wk) and the typical student takes four courses in a semester.
But if fullmoon wants to start with something easier he could always just read my online book written to be an easier "prequel" to SICP, the textbook for my course, the best CS book in the world.
Last edited by bharvey (2010-09-07 00:20:32)
Offline
Hi developers of BYOB!
You may of noticed I am creating a website called MOD share. It will basically be just like scratch but Mod projects can be uploaded! This means anyone can share a project that has been made with their favourite mod. At the momment that is impossible, at least not an instant upload, but with MOD share it is possible to share any project made with any mod. The website is not finished yet but will be in the next month or so. Since BYOB is so popular I would love to include it so I would just like to ask for your permision to list it and allow the upload and sharing of BYOB projects. Is this okay with you?
Offline
bharvey wrote:
4 hr/wk on homework
toooo muchhhh wooorrrkkkkkk lol
jk
But as far as the part above of multiple lectures, then that makes sense ^_^
Offline
Daffy22 wrote:
I would just like to ask for your permision to list it and allow the upload and sharing of BYOB projects. Is this okay with you?
Doesn't this involve more than listing it? We'd have to add the necessary code to upload to your site, right? I'm not against the idea in principle but would like to understand better just what we're agreeing to.
P.S. There has been some talk among the Scratch Team about finding a way to allow mod-project uploads without people getting confused about what runs in what. So far this is in the batting-ideas-around stage, but it might happen.
Offline
bharvey wrote:
Daffy22 wrote:
I would just like to ask for your permision to list it and allow the upload and sharing of BYOB projects. Is this okay with you?
Doesn't this involve more than listing it? We'd have to add the necessary code to upload to your site, right? I'm not against the idea in principle but would like to understand better just what we're agreeing to.
P.S. There has been some talk among the Scratch Team about finding a way to allow mod-project uploads without people getting confused about what runs in what. So far this is in the batting-ideas-around stage, but it might happen.
No it wouldn't mean any extra code in BYOB there will be an online upload form!
I just thought it would be polite to ask before I listed it as a supported mod.
Offline
fullmoon wrote:
Argh! No bookstores seem to carry it around here...
The good news: The Cal bookstore has it.
The bad news: It costs $86.
(You can get an old first edition cheaper if you work at it, but trust me, you want the second edition.)
EDIT: If you're not in a hurry, you can usually find used copies at the end of our semester, Dec 16.
Last edited by bharvey (2010-09-08 11:35:47)
Offline
bharvey wrote:
Daffy22 wrote:
No it wouldn't mean any extra code in BYOB there will be an online upload form!
I just thought it would be polite to ask before I listed it as a supported mod.Oh. Knock yourself out!
Oh and theres one other thing I would like to kindly ask you:
Could you add this code either in the forum or the website?
HTML code: <a href="http://www.mod-share.webs.com/"> <IMG src="http://www.mod-share.webs.com/share.png"> </a> BB code: [url=http://www.mod-share.webs.com/][img]http://www.mod-share.webs.com/share.png[img][/url]
It is so your users know they can upload and share BYOB projects! Thanks!
Offline