Scratch

Hardmath123 wrote:

And if that returns an error, why can't Snap?

Yeah, it can and should.  We just haven't gotten to error handling yet.

Page 200! 

bharvey wrote:

blob8108 wrote:

So "23" + "10" = "2310", but 23 + 10 = 33. Is that an improvement?

Yeah, it's better, I suppose.  What does "23" + 10 do?

Throws an error.

The new ring things look nice!    Empty reporters should report nil/NULL/None, I think. (I'm not sure which "null" is/would be in Snap...)

scimonster wrote:

bharvey wrote:

blob8108 wrote:

So "23" + "10" = "2310", but 23 + 10 = 33. Is that an improvement?

Yeah, it's better, I suppose.  What does "23" + 10 do?

Also "2310".

Not in Python 

scimonster wrote:

blob8108 wrote:

scimonster wrote:

Also "2310".

Not in Python 

It does in other languages.   

javascript is evil 
but THAT is really a bad thing to do...

roijac wrote:

javascript is evil 

Hey, at least it has a real lambda, unlike a certain other language that will remain nameless because I'm an adult and way too mature to start a flame war.

blob8108 wrote:

In some situations, is it not more useful to report nothing than to throw an error?

At the risk of sounding Clintonian, I'm not sure whether you mean "report 'nothing'" or "not report anything."  If the former, you don't need a special feature; you can use the word "nothing" (or "NULL" if you prefer), or False, or 0, or whatever floats your boat.  If the latter, all that would happen is that the enclosing block, the one to which you're not reporting anything, will throw a less meaningful error.

I'm not convinced that it's a good idea to blur the distinction between these two possibilities.

But I do think it's useful to be able to have a block that sometimes does and sometimes doesn't report a value.  Then, for example, we could have a single block for RUN and CALL, which basically do the same thing.  The block would report iff its input block reports.  Sadly, the otherwise-really-valuable Scratch block shapes don't allow for that.

Flame war aside, I'm now just really intrigued — to which language do you refer?

Python!  It has a sort-of lambda, but very restricted.

bharvey wrote:

Hardmath123 wrote:

Ok, but will you have NULL in Snap! anyway? It's a useful procedure error.

I'm not sure I understand this.  Do you mean "it's useful for a custom block to have a conventional value to report to indicate a user error"?  I'd rather have an ERROR block that takes a text string as input and gives that error message.

Well, I guess a parallel would be how some example functions in JS tutorials return "-1" for errors in factorial scripts if the input is negative. Except, NULL is easier to stretch to other operations. For example, getting item N of a list of size N-1 could return NULL. Similarly, an empty ring reporter could return NULL (did I say that already?). NULL can also be a reporter block, so I can do something like this:

if <(item (n) of [list v]) = (NULL)>
say [Oops!]
end

Also, can I have references to variables in Snap!? For example, can I write an "increment" function that takes in a variable and returns the variable + 1, while changing the value of the variable by 1 (i.e. i++)? If a variable is an input to a procedure, the procedure automatically makes a duplicate of it, rather than allowing me to change the original value...

You can do this in BYOB:

http://i1172.photobucket.com/albums/r57 … rement.png

It doesn't seem to quite work in Snap! yet, but Jens will fix it. 

Ah. I was trying something similar in Snap!, so that was the problem.

I know arrays are automatically treated as references in Snap!, but how about numbers and strings? How can I reference those?

Numbers and strings are not mutable, so there's no point in having a reference to one, in the way I think you're thinking.

Of course, as in any Lisp dialect, really everything is a reference; the only data type is "pointer."  But if the underlying value isn't mutable, there's no way to know that.

I had to read that a couple of times before realizing I couldn't possibly understand it. How can the only data type be a pointer? A pointer's gotta point to something, the only something left is data...

I never really understood pointers. In C, a pointer's something to do with memory locations. So I guess a variable is a value, a pointer is the location at which the value is stored. Have I got that right, or is there scope for further confusion?

Last edited by Hardmath123 (2012-04-25 13:56:31)

bharvey wrote:

You can do this in BYOB:



It doesn't seem to quite work in Snap! yet, but Jens will fix it. 

Yup, I sure did! Check it out (and make sure to flush your browser's cache before you do)!

Last edited by Jens (2012-04-25 17:26:38)

Hardmath123 wrote:

NULL can also be a reporter block, so I can do something like this:

if <(item (n) of [list v]) = (NULL)>
say [Oops!]
end

Sorry for the delayed response; I had to put some attention into the stuff I actually get paid for.

I think you can't have it both ways.  If you want NULL to mean "I'm reporting that I'm not reporting a value," then you can't equality-test it to something, or use it in any other value-expecting context.  If it doesn't mean that, if NULL is just a value like true or false, I'd rather throw an error than expect users to put a million tests for it after calling your block.  I know they teach you in computer science class to check explicitly for errors, but it makes your code really hard to read, because the parts that do actual work are buried in error-testing parts.  This NULL business got started because C doesn't have a way to throw or catch errors; I think it's an idea whose time has passed.

I had to read that a couple of times before realizing I couldn't possibly understand it. How can the only data type be a pointer? A pointer's gotta point to something, the only something left is data...

I never really understood pointers. In C, a pointer's something to do with memory locations. So I guess a variable is a value, a pointer is the location at which the value is stored. Have I got that right, or is there scope for further confusion?

Thanks to roijac for the Python example.  Did it help?

The term "variable" as understood by a programming languages specialist is a little different from what lay people (including me) mean by it.  So, first, here is the technical definition:  A variable is a location in memory that contains a pointer to a value.  ("Pointer": the memory address of something, the thing it points to.)  Note that in this definition a variable does not have a name!  There is something else called a binding that associates a name with a variable.

For certain purposes it really is useful to make this distinction.  But unless you're writing a compiler (or a PhD thesis about programming languages), it's good enough to say that a variable is the combination of a name and a value.  Or, as non-Lisp programmers put it, a variable has a name, but is a particular place in memory (that might have a value in it).

Lisp programmers think the same thing, except that the value of a variable is always a pointer.  Yes, the pointer points to some other kind of thing, such as an integer or a text string, but the variable itself has as its value the address of that integer or text string.

(Footnote: As an efficiency hack, most real-world compilers, even for Lisp, cheat and handle positive integers smaller than the lowest possible memory address of data by putting the actual integer in the variable, but they make sure there's no way the user can find that out.)

As roijac points out, this becomes important when the underlying value is mutable.  Then you need to know whether the language puts the underlying value in the variable (so that assigning the value to another variable makes a copy) or puts a pointer in the variable (so that assigning the value to another variable makes a copy of the pointer).  But there are other reasons for considering all variables to be of type "pointer."

Namely, there is a big difference between languages that require you to specify the type of a variable (e.g., C, Java) and languages that have untyped variables (e.g, Lisp, Snap!).  In the latter, it's not that there aren't different kinds of data.  Rather, instead of associating a type with a variable, these languages associate the type with a specific value.  So, the value 3 isn't just a single computer word containing the bits 00...011, but a structure including both that computer word and a type tag, i.e., a small integer: 1=integer, 2=list, 3=textstring, etc.  This is why we have to put a pointer in the variable uniformly, even for non-mutable data.  But the advantage is that it's much easier in these languages to deal with heterogeneous data, such as a list containing many different kinds of items.  (The more-than-a-word-ness of typed data is the reason for the footnote above about cheating for small integers, for which the type is implicit.)

The above is probably more than you really wanted to know, sorry.  Here's the bottom line:  If the value of every variable is a pointer, then we don't have to make the pointers explicitly visible to the user.  When you use a variable, we dereference the pointer (i.e., look in the memory location that the pointer addresses) and the user just sees the value pointed to.  In C, where some variables directly contain the underlying value (namely the ones that fit in a computer word) while other variables contain pointers, the pointers have to be explicit in the language and users have to think about them.

Last edited by bharvey (2012-04-25 18:33:05)

Hi Xavier,

the CALL/CC block has a command ring inside because it needs to accepts commands, especially the REPORT block. In the unlikely case that you would like to actually reify a reporter block in there you can exchange the default command ring against a reporter ring yourself! (This is actually easier now than it used to be before we had rings).

the OF block is certainly in the pipeline, but I'm not telling dates 

yeah, this outputs are really confusing^^ 

@jens, what about putting the rings in the right-click menu on the palette?

clean up
make a block
rings -> (the three rings in a sub menu)

joefarebrother wrote:

Also, I think an empty ring should report the identity function.

Ah, this is a really sensible idea, undoubtedly The Right Thing, but I'm a little scared -- does it apply to the rings automatically provided in Procedure-type input slots?  If so, people who accidentally leave out the function will get a result instead of an error message.  Maybe that's okay -- it's certainly the Scratch Way, but I'm afraid it'll make debugging harder.  Votes?  Thoughts?