Snap! user discussion

Jonathan50

DanFish wrote:
No offense, but why is this block in Snap?
stop [this block v]
It seems kind of useless.

Instead of

{foo :: grey} :: control hat
if <something? :: operators>
  ...
else
  ...
end

you could write

{foo :: grey} :: control hat
if <something? :: operators>
  ...
  stop [this block v]
end
...

Not yet a Knight of the Mu Calculus.

Jonathan50

DanFish wrote:
So it does the same thing as the Stop This Script block?

No, in Snap! then stop this script inside of a custom block will stop the calling script.

Not yet a Knight of the Mu Calculus.

joefarebrother

DanFish wrote:
Jonathan50 wrote:
DanFish wrote:
No offense, but why is this block in Snap?
stop [this block v]
It seems kind of useless.
Instead of
{foo :: grey} :: control hat
if <something? :: operators>
  ...
else
  ...
end
you could write
{foo :: grey} :: control hat
if <something? :: operators>
  ...
  stop [this block v]
end
...
So it does the same thing as the Stop This Script block?

It does what the “stop this script” block does in *scratch*, but in Snap the stop this script block stops the whole calling script too.

So in Snap!, the following will just say “before”

 
When gf clicked :: control hat 
Say [before] for (2) secs 
Test :: grey
Say [after] for (2) secs 

{test :: grey} :: control hat
Stop [this script v]

Whereas in Scratch, this will say before and after

 
When gf clicked 
Say [before] for (2) secs
Test :: custom  
Say [after] for (2) secs 

Define test 
Stop [this script v]

Last edited by joefarebrother (May 27, 2016 09:45:16)

And it was delicious! Play TBGs! Check out my Scheme Interpreter!
;

bharvey

Why when I do /unread on this group am I getting a blank page?

(Edit: This post seems to have fixed it.)

Last edited by bharvey (May 28, 2016 00:47:37)

Jonathan50

bharvey wrote:
Why when I do /unread on this group am I getting a blank page?

The most recent post was a deleted posts (maybe spam). But since you've posted it will now work again, until another deleted post is the most recent post.

Last edited by Jonathan50 (May 28, 2016 00:48:55)

Not yet a Knight of the Mu Calculus.

Carcovi

if would like export a project, How do I continue?

liam48D

Carcovi wrote:
if would like export a project, How do I continue?

Take a look at the file menu:

Clicking on export project will get you an XML file that you can import into Snap!, by dropping the file in.

202e-202e-202e-202e-202e UNI-CODE~~~~~

ivancr72

What's Keyboard Editing on settings?

Beautiful wallpapers

bharvey

ivancr72 wrote:
What's Keyboard Editing on settings?

It enables the ability to edit scripts just with the keyboard, selecting blocks by typing enough of their name to be unique, tabbing to fill input slots, etc. It's meant as the first step toward support for users with vision disabilities, but we have a long way to go still.

Jonathan50

Since you're differentiating between syntax and AST, does that mean Snap! macros will be hygienic, like Scheme's?

Not yet a Knight of the Mu Calculus.

bharvey

Jonathan50 wrote:
Since you're differentiating between syntax and AST, does that mean Snap! macros will be hygienic, like Scheme's?

No, I don't quite see what one has to do with the other.

I don't understand hygienic macros, and I'm not fully convinced that anyone else does either, judging by all the “I can't see how to do X with hygienic macros” posts by super KLCs on comp.lang.scheme back when I still had free access to usenet.

In any case, when I make Jens finish hybrid scope in Snap!, even non-macro code won't be hygienic, so it'd be pointless. Just plain old eval-it-twice macros are what I have in mind. (Like Berkeley Logo!)

Jonathan50

bharvey wrote:
Jonathan50 wrote:
Since you're differentiating between syntax and AST, does that mean Snap! macros will be hygienic, like Scheme's?
No, I don't quite see what one has to do with the other.

I don't understand hygienic macros, and I'm not fully convinced that anyone else does either, judging by all the “I can't see how to do X with hygienic macros” posts by super KLCs on comp.lang.scheme back when I still had free access to usenet.

In any case, when I make Jens finish hybrid scope in Snap!, even non-macro code won't be hygienic, so it'd be pointless. Just plain old eval-it-twice macros are what I have in mind. (Like Berkeley Logo!)

Huh. Then what is the difference between syntax and AST?

Not yet a Knight of the Mu Calculus.

birdoftheday

What even is a hygenic macro as opposed to non-hygenic? I never quite understood them.

Am I the only person who likes 3.0 better than 2.0, or do the people who do just not talk about it?

-Io-

Jonathan50 wrote:
bharvey wrote:
Jonathan50 wrote:
Since you're differentiating between syntax and AST, does that mean Snap! macros will be hygienic, like Scheme's?
No, I don't quite see what one has to do with the other.

I don't understand hygienic macros, and I'm not fully convinced that anyone else does either, judging by all the “I can't see how to do X with hygienic macros” posts by super KLCs on comp.lang.scheme back when I still had free access to usenet.

In any case, when I make Jens finish hybrid scope in Snap!, even non-macro code won't be hygienic, so it'd be pointless. Just plain old eval-it-twice macros are what I have in mind. (Like Berkeley Logo!)
Huh. Then what is the difference between syntax and AST?

From what I've understood, syntax is the rules, and AST is the result from applying the syntax.

Jonathan50

birdoftheday wrote:
What even is a hygenic macro as opposed to non-hygenic? I never quite understood them.

With unhygienic macros in Common Lisp:

(defmacro swap! (a b)
  `(let ((val ,a))
     (setq ,a ,b)
     (setq ,b val)))
(defvar foo 1)
(defvar bar 2)
(swap! foo bar) ;; works, foo is now 2 and bar is 1
(defvar val 3)
(defvar baz 4)
(swap! val baz) ;; Oh no! Nothing changes.
;;; The above expands to:
;;; (let ((val val)) ;; Val (3) is shadowed by a new variable of the same name and value
;;;   (setq val baz) ;; The innermost val is set to baz. Doesn't change the outer val.
;;;   (setq baz val)) ;; Baz is set to the inner val (which has the same value as baz). So nothing changes!

Hygienic macros prevent variables from being captured.
With hygienic macros in Scheme:

(define-syntax swap!
  (syntax-rules ()
    ((_ a b)
     (let ((val a))
       (set! a b)
       (set! b val)))))
(define foo 1)
(define bar 2)
(swap! foo bar) ;; works
(define val 3)
(define baz 4)
(swap! val baz) ;; works

This does mean that you can no longer just have macros transform normal Scheme data (normal symbols), instead macros need to transform syntax objects (identifiers, which are symbols with lexical context).

Last edited by Jonathan50 (May 30, 2016 01:22:51)

Not yet a Knight of the Mu Calculus.

bharvey

Jonathan50 wrote:
Huh. Then what is the difference between syntax and AST?

Not much, in Lisp; that's why writing a Lisp interpreter is so much easier than an interpreter for anything else.

An abstract syntax tree is a data structure (a tree, to be exact, duh

) representing procedure calls (which may not have been viewed as procedure calls in the surface language, e.g., most languages look at arithmetic 2+3 as something different from a procedure call sum(2,3), but in the end they both have to do the same thing).

Surface syntax is all that stuff with semicolons and how many spaces at the start of the line and all that other stuff that really carries no meaning. Even something like “for (start, test, next) {body};” is in the end a procedure call

(for (lambda () start) (lambda () test) (lambda () next) (lambda () body))

and that would be represented as a node in the tree, with FOR as the first part and the thunks (lambda () …) as children.

The thing about Lisp is that the same nested parentheses that represent procedure calls also represent list structure, so Lisp's surface syntax already is an abstract syntax tree! This is very cool and powerful. Not only is interpretation easy, so are debuggers and pretty-printers and so on.

In Snap!, the surface syntax is blocks, not lists. So in order to do self-reflection, such as writing Snap! in Snap! or writing a macro system, we need primitives to translate between list structure (ASTs) and surface structure (blocks and scripts).

bharvey

Jonathan50 wrote:
This does mean that you can no longer just have macros transform normal Scheme data (normal symbols), instead macros need to transform syntax objects (identifiers, which are symbols with lexical context).

Also, sometimes name capture is what you want the macro to do, and hygienic macros rule that out, so Scheme implementations generally also have a lower-level macro system that isn't hygienic but is really, really complicated to punish you for using it.

Edit: Bear in mind that I grew up at the MIT AI Lab, where I was taught to be scornful of “protecting the user against himself.” Programming was done either in Lisp, which had no type declarations, no bounds checks, etc., or in PDP-10 assembly language, which of course let you do anything including self-modifying code. So when hygienic macros came along I was not predisposed to love them.

Last edited by bharvey (May 30, 2016 01:44:11)

gdpr533f604550b2f20900645890

To make things more convenient, the first part of the s-expression is the function, so the interpreter would be able to easily tell what actions to perform when it sees the node.

That is, if I understand how interpreters work correctly. I assume that programs are evaluated from the root to the leaf, with each root evaluating its children based on the function/special form.

EDIT: This is a reply to the AST post.

Last edited by gdpr533f604550b2f20900645890 (May 30, 2016 01:41:06)

bharvey

Chibi-Matoran wrote:
That is, if I understand how interpreters work correctly. I assume that programs are evaluated from the root to the leaf, with each root evaluating its children based on the function/special form.

Yes. Certainly that's how a standard not-too-aggressive interpreter works, by recursive descent. (That's what that approach is called.) Compilers, and super optimizing interpreters, massage the AST in various ways before running it (interpreter) or emitting code (compiler). One way is to translate the program into continuation passing style, so everything is a tail call, for example. Searching for expressions that appear more than once in the code (so the value from the first time can be remembered for the next time, supposing nothing relevant has changed) is another.

gdpr533f604550b2f20900645890

Oh, I only knew the term “recursive descent” in terms of parsing, not evaluating the parse tree.

Discuss Scratch