Dale_Mahalko wrote:

How do I select a color and then plot a single 1-pixel point?

You have to say MOVE 1 STEPS. I think this is a misfeature and you should really say MOVE 0 STEPS, because MOVE n STEPS should draw n+1 pixels.

Actually I'm confused about the behavior. Here's MOVE 1 STEPS:

and here's MOVE 100 STEPS:

It seems to me that the former covers one pixel, from x=0 to 0, whereas the latter covers 101 pixels, .

Dale_Mahalko wrote:

When scanning the keyboard for keypresses, why can't I detect UPPERCASE, the space bar, or any symbols `~!@#$%^&*()-=_+\{}|;':",./<> ….?

You can detect the space bar – that's the default in the WHEN block and the Sensing block.

As for the others, we inherited the menu from Scratch. But it does have an “any key” item. What's missing is a reporter holding the most recent keypress. (Although, do you want to include modifier keys as keys (shift, control, etc.)? Here's the best I could do right now:


Edit: But as you noted, it doesn't work for shifted characters.

“Move 1” still plots a 2-pixel line.

But after experimenting a bit more, I found a hack solution. It can be told to move less than 1 pixel, and this then draws a 1-pixel point
Move 0.01
Change Y by 0.01
Change X by 0.01

all draw a 1-pixel point.

There is a difference in the variable watchers on the stage – the label says if it's local.

Ta

At least I can find out which variables are what scope by doing that

Having played around a bit more I can see that Snap places local vars below the global vars just like Scratch - its just missing the little line that Scratch uses to highlight the demarcation

Maybe it used to be there but has gone AWOL

Simon

SimpleScratch wrote:

Having played around a bit more I can see that Snap places local vars below the global vars just like Scratch - its just missing the little line that Scratch uses to highlight the demarcation

Hmm. Not for me. It puts the variables in the palette in order of creation.

mm
if I create in this order
A (for all sprites)
B (for all sprites)
C (for all sprites)
D (for this sprite)
E ((for this sprite)
F (for all sprites)

I get this order
D
E
A
B
C
F

And I've just noticed that Snap has reversed what Scratch does - it puts the locals first and the globals second - xkcd927

I find variable order of creation incredibly annoying and disorganized. How can I alphabetize the variable list?

Due to the lack of identification of one variable type from another, plus no built-in way to do constants, I have just accepted that I need to do all the labeling myself in the naming, and I can make it work the way I want anyway regardless of the clunky user interface.

Global variable: G.*
Local Sprite variable: LS.*
In-script Local variable: L.*

Global Constant: GC.*
Local Sprite Constant: LSC.*
In-script Local Constant: LC.*

I can also do fake object oriented design, just because things are easier to read that way. I suspect that this is probably what people did before object oriented programming officially existed, and someone then decided to formalize it into a real thing that the compiler understands.

GC.Game.MapData
GC.Game.SpriteList
GC.Game.PointsList

And this helps with the problem that you cannot pass variables to sprites when you send messages to them to do something, so there needs to be a way to separate out these message passing global variables from everything else.

Global sprite message: GSM.*

Messages sent between sprites are named this way.
Variable data being sent between sprites are named this way.

SimpleScratch wrote:

And I've just noticed that Snap has reversed what Scratch does - it puts the locals first and the globals second

Oh, right, that didn't even occur to me as something to test for.

Dale_Mahalko wrote:

And this helps with the problem that you cannot pass variables to sprites when you send messages to them to do something, so there needs to be a way to separate out these message passing global variables from everything else.

Whoa! In Snap! you don't have to ask a sprite to do something with BROADCAST. You do this:

The first input to OF, if it's a fixed command as in this example, has to be explicitly ringified. The second input can be a sprite name, as here, or a computed actual sprite (e.g., an item of MY NEIGHBORS). The 2nd (and more if needed) input(s) to RUN can be any expression, which will be computed in the context of the calling sprite. (An expression with variables in the first input to OF will be computed in the called sprite in 4.1.)

I think you're thinking too much about syntax, rather than semantics. We can do OOP, it just doesn't use the syntax to which you're accustomed.

As for variables, once you start down that road of squeezing syntax into their names, there's no stopping. How about LS.INTEGER.foo? But, whatever floats your boat.

Um, well, it looks like this language is basically your baby. You are the architect, and if you're not going to do anything to obviously show the difference between the variable types then it falls on me to do something to make it more obvious to myself, because right now this user interface offers me nothing.

A fake identifier for integers or longs has no purpose because there's no way to define that. I have no clue how to make a string-only variable, and there is no useful reason to go this far because casting isn't possible anyway, and the language does it automatically.

Constants are a fundamental enough concept that they can be identified as I am doing, even if the language offers no direct support, because you don't need to do anything with it except don't modify it once it is created, which is how constants normally work.

Dale_Mahalko wrote:

Um, well, it looks like this language is basically your baby. You are the architect, and if you're not going to do anything to obviously show the difference between the variable types then it falls on me to do something to make it more obvious to myself, because right now this user interface offers me nothing.

If you ever have a feature idea that you think is really critical, the most helpful thing you can do is submit a pull request. Solving problems yourself lets you do things on your own timeline, rather than someone else's.

Well, I don't yet know Javascript well enough to offer a direct change to this code for how the UI works. Though I'd probably just extend the outer “variable name bubble” to the left a bit and stick these letter prefixes into the bubble to the left of the editable variable name.

https://i.imgur.com/4owHysv.png

I see that constants can also be named in the more typical all-uppercase naming manner.. that works also without any explicit support for it.

Dale_Mahalko wrote:

Um, well, it looks like this language is basically your baby.

Much more Jens's than mine.

Probably we should bring back the dividing line between globals and sprite-locals in the palette. Or maybe have captions “Global variables:” and “Sprite-local variables:” (or maybe “For all sprites” and “For this sprite only” to match the radio button text). And probably no captions if there are no sprite variables in this sprite.

By the way, Jens reminds me that variable names aren't resolved until the script is running, so a name that represented a global variable at birth could be a sprite-local or procedure-local variable by the time it's used. That argues against putting visual scope information in variable blobs in scripts. There are good reasons why you might want to shadow a global variable in a particular sprite, and have common procedures do the right thing when used in other sprites (the var is global) and in this sprite (the var is local).

By the way, I think we have a pretty good record of taking user suggestions seriously. But I confess that we're not so interested in suggestions that seem to be based on the idea that however Java (or maybe C++) does things is The Right Way. For instance, our OOP system for sprites in 4.1 is prototype-based, not class/instance based. We think class/instance is okay for a compiled language, but in an interactive system like ours, users want to be able to play with an example of some kind of object directly, and then clone it, using the old one as the prototype for the new one. (Javascript, by the way, makes things way too complicated by having a required object called foo.prototype for every object foo. What they really mean is for foo to be a class, but they read somewhere that prototyping is cool, so they distort prototyping to look exactly like class/instance.)

We took Nathan's suggestion on how to implement a multi-branched conditional. (See the library with that name.) We've taken user suggestions about the music blocks. I'm spacing on other examples, but they do exist; I'm just old and tired.

That “Run (Ring of (command)) on Sprite with Inputs” block is weird. I see that it works to send whatever command blocks you want to a sprite, but then the next question is how to get input back from those sprites.

Apparently I cannot read what the mouse cursor is touching, from a main script that is inside the stage.

Can this be made to work without touch scripts placed inside the external sprites, reporting their state back via global variables?
http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=External%20Sprite%20Control

Dale_Mahalko wrote:

but then the next question is how to get input back from those sprites.

Oh, you use CALL instead of RUN, and put a ringed reporter in the first slot.

We have library blocks TELL (for RUN) and ASK (for CALL) that hide the OF business. But it really does make sense; OF reports a script or an expression that's tied to the other sprite, and RUN or CALL evaluates it.

I don't completely understand what you're trying to do, but does CALL/ASK solve the problem?

bharvey wrote:

We can do OOP, it just doesn't use the syntax to which you're accustomed.

IMHO, object oriented design is overrated. I prefer the ML/Haskell like approach where you create lots of small immutable data types and use functions to transform them into the result you need.

BookOwl wrote:

IMHO, object oriented design is overrated.

No argument here; I much prefer functional programming for most purposes. But as a teacher, I want to be able to give students the experience of using OOP so they have more than one string to their bow, and that means that the programming language we use has to support OOP.

bharvey wrote:

BookOwl wrote:

IMHO, object oriented design is overrated.

No argument here; I much prefer functional programming for most purposes. But as a teacher, I want to be able to give students the experience of using OOP so they have more than one string to their bow, and that means that the programming language we use has to support OOP.

Fair enough. I still wish Snap! had algebraic data types and pattern matching though.

Does anyone know how (if you are able to) use Objects as inputs for a custom block?

I tried, but I just get the turtle icon. I can't drag a sprite onto it or click on it to select from a list.

In the Snap! reference manual it says this feature is to come in version 4.1 but I don't think this is released yet. Just curious if anyone has done this … such as a custom block to sense if sprite1 is touching sprite2 or sprite3. Something like this.

Thank you,
Brendan

ToBookOwl

Brian Harvey has got a worldwide reputation , particularly as the author of the reference book of Computer science: “Simply Scheme-Introducing computer Science.”Computer science does not mean just “to learn programming” , but to know all the scientific and theoretical basis of Computer Science, you see the difference? By grand-son is attending at Imperial College of London the course of Computer Science and Artificial Intelligence. He is just starting to learn Lisp. Although no programmer today will ever write an application with Lisp (*) . Anyway it is a “passage obligé” for Computer science students. All major day-to-day programming languages like Javascript have been invented by Computer scientists, not by “C” programmers ! The same, of course, for the revolutionary “artificial intelligence”. In fact Snap! is “just” a brillant modern adaptation of Scheme language. You like it or you leave it ! No need to say that Brian know very well all means of tackling "object programming. This has been already discussed at length here for years, and believe me, Brian has very strong reasons for having implemented in Snap! his OOP way.

* I've offered him the book of Brian to start with.