Scratch

"Personally I think that's a great decision for lowering the threshold for kids and beginners, and I do hope that our decision to abandon these special-cased list variables in favor of first-class lists doesn't put too much of a strain on our target audience."
I totally approve your view. In Byob the coexistence of "named" lists and "first-class" lists was the result of historyical "sedimentation".

What I mean with my example iis  that in some custom blocks like "map over" "append" etc you need to set (not declare) the "script variable" resul to a void list. If you forget to do so, your block does not work, but you also you don't get any error message. As I said it in a previous msg, it took me hours to find this "error". But now I know it. Such a problem is not an issue, and is a part of the "learning process" that each programmer has to go through, whichever the language is. Many previous msg above that there are others comparable cases. It will be easy - in the futureSnap! documentation  (perfect as we know brian) -to undeline such cases.

@ bharvey "LENGTH, should be combined into one, or maybe both exist but take both kinds of inputs. "
Similarly I've been caught with this type of error, where inavertently I'd selected the "green" LENGTH instead of the "brown" one. I give you a low profile suggestion " avoid to give the same name for LENGTH of list and LENGTH of word. But anyhow it's the game of test-and-learn process.

I think we should have an error popup at the source block:

and highlight all the custom-block calls that lead to it in red.

Presently, when I SET test to "toto" and tries to run ITEM 1 OF test I get he following error message "Problem : type error Object toto has no method "at". I think it is enough !
The same with Byob gives a "blank"

Hardmath123 wrote:

I've got a question for you computer gods: what's a "class"? [...] I do know that they're files you add to a project. [...]

Well, the only god around here is Jens (coincidentally, he and I have been arguing about just this godhood question recently  ), but I'll give it a stab anyway.

There's no necessary connection between classes and files, although it's convenient to name a file after a class.  But often a program has a zillion tiny class definitions and it'd be overkill to have one per file.  (I wouldn't be surprised, I guess, to learn that some particular language I don't use requires one per file.)

In a class/instance language, a class is a kind of object, and an instance is a particular one.  So, for example, there could be a class Point with an instance (3,4).  BYOB/Snap! and JS are both prototyping OOP languages, in which there is no class/instance distinction, just a hierarchy of parents and children.

(Class/instance languages, typically compiled rather than interpreted, are good for large team projects, in which the entire object hierarchy is planned out before any code is written.  Prototyping languages, often interpreted and therefore interactive, are good for one-person seat-of-pants tinkering, in which you design an object interactively and incrementally, then when you like it you say "give me six more like this one" (but can still go on tinkering with the parent and have the changes reflected in the children).)

One of the central hallmarks of object oriented programming is that an object is both a data structure and a collection of methods.  (Arguably, a method is just a procedure-valued datum.)  It's typical, but not required, that the class contains the methods and the instances contain the non-method data.  For example, each instance of Point will have its own x-coordinate and y-coordinate (data), but the distance-from-origin method is the same for all points and therefore lives in the class.

(Exceptions are possible both ways.  Instance-specific methods are rare -- not allowed in many OOP languages -- but class variables aren't so uncommon.)

I think the above is what's confusing you.  Some classes, because of their particular purpose, will be very method-heavy, and an instance will have relatively little specific data.  (In the extreme case, you occasionally see a class that's meant to have only one instance, which has no data at all, just to collect a bunch of procedures in one place.)  Other classes, for different purposes, will have a ton of instance-specific data and not so many methods.  But these are positions on a continuum, not an either-or duality.

Does that help, or am I misunderstanding the question?

Last edited by bharvey (2011-12-16 22:38:35)

MathWizz wrote:

I'm assuming that [Debug] would return the call stack much like squeak does, am I right?

Basically, but there's a lot of information to present (the calling blocks, the values of local variables, the object (sprite/stage) that's running this block, its variables...  We have to invent palatable ways to give the user access to all that without just blasting it all onto the screen at once.

A debugger should also be able to single-step, to set breakpoints, maybe to run in slow mode (what Scratch calls single stepping), maybe even to run backwards (having kept a lot of snapshot information).

xly wrote:

Presently, when I SET test to "toto" and tries to run ITEM 1 OF test I get he following error message "Problem : type error Object toto has no method "at". I think it is enough !
The same with Byob gives a "blank"

No, it's not enough -- this is what I meant about not going out of our way to make errors obscure.  What you're seeing is a Javascript message for the benefit of Jens, not the intended message for users.  In this case the error should be "toto isn't a list."  Maybe even "Did you mean (orange variable blob named toto)?"

bharvey wrote:

Hardmath123 wrote:

I've got a question for you computer gods: what's a "class"? [...] I do know that they're files you add to a project. [...]

Well, the only god around here is Jens (coincidentally, he and I have been arguing about just this godhood question recently  ), but I'll give it a stab anyway.
[...]
Does that help, or am I misunderstanding the question?

I think I got it, thanks for the explanation. Here's how I see it now:
(I'm taking JS as prototype based and Objective-C for Class/instance-based language examples.)
A JavaScript function or object declared as "var foo = new String("blah");" is like an Objective C class initializer (It's like NSString *foo = [[NSString alloc] initWithString:@"blah"];). So a JavaScript function declared as "function foo() {}" is in fact a sort of class initializer which can initialize (and control) an object, or just do something and return an "empty" object.
Assuming that bit is correct, I think the "proper" way to create a JavaScript function would be the "function(arg) {}" syntax, which is like "-(returnType)function:(type)arg {}" Objective-C code.
Is that how it is?

EDIT: Truncated your quote, fixed a smiley glitch...
EDIT: Still couldn't fix the smiley glitch...

Last edited by Hardmath123 (2011-12-17 03:20:47)

It might get a bit annoying if every error stops the script. What if there was a block called (ignore errors in () ) which will evaluate it's input but if there is an error (such as trying to divide by 0) it just returns a blank string. Even better there could be a try/catch exeption mechanism  like in many programming languages. It will look like

and will run the input in the try part but if there is an error it will terminate and set the upvar exeption to the error message and run the catch part. There will also be a |show error message ()| block to display an errormessage in a red dialogue box and a |throw error message ()| block to throw errors. An error message will be a list and will be displayed as every item in the list seperated by new lines so you could put in a short dispcription of the error (such as "procedure called without reporting") followed by the block that caused the error and then the script that caused the error and the sprite it was in. This try/catch mechanism could be used to create the (ignore errors in ()) block like this:

{(ignore errors in (unevaluated input))}
try {
  report (call(unevaluated input))
}
catch (exeption) {
  report ()
}

xly wrote:

Instead of assigning strict types "beforehand" to data we can control the variable type when it is needed.
Take the example of "divide by zero error". If needed one can write a reporter block NONUL to avoid a division by zero.

Sure, but that isn't a type error.  A type error would be more like trying to divide by a string or a list.

This isn't just a quibble about terminology; if you're dividing by zero it's almost certainly because you're dividing by a variable, and that variable's value is of the correct type (i.e., number), but unexpectedly came out zero.  So the real error is earlier in the program when that value was computed.  But if you're dividing by a string, it's because you did something incoherent right at that point in the program, putting an expression in the divisor slot that couldn't possibly come out right.

So it makes sense for us to handle different kinds of errors differently, maybe.

But also, I don't think we should make it the expectation that everyone surround every input expression with a domain check.  That would be a huge distraction from actually writing the program you want to write!

Is it possible for a Snap! programmer to know afterhand , if needed, that such variable is a number, a string, a list, a word, a script, a letter , a sprite, a costume etc ?

In the Operators menu there's a IS ___ A ___? block, where the second slot is a pulldown of types.

In the Operators menu there's a IS ___ A ___? block, where the second slot is a pulldown of types.
Indeed ! It's perfect !

14God wrote:

might be nice if object ancestry was handled by the IS__A__? block... and by ancestry I mean checking if a object is a child of another, of course objects are a ways off for snap.

We do (in BYOB 3.1) have the ATTRIBUTE [PARENT] and ATTRIBUTE [CHILDREN] capability, so you can find out the ancestry of an object.  The IS/A block presents a disjoint and complete list of basic types, so everything is exactly one type for IS/A purposes.  Objects' abstract types are complicated; the predicate you want should return True about the object's grandparents, etc., too.

I was thinking about trying to implement one of my favorite programming constructs, call-with-current-continuation, in BYOB. For those that don't know this is a block that takes a procedure A and calls A with a procedure B. B, when called, will jump back into the original context and return the value it was called with to wherever call-with-current-continuation was originally. Anyway, I thought about how to capture the whole local environment, especially sprites' local variable values. I think an elegant addition to BYOB which would allow this would be an analog to sprite(all sprites); attribute(all attributes) which would return a list of all variable values, x position, etc.. of a sprite.