Scratch

bharvey wrote:

OldCodger wrote:

This fact disqualifies Lisp from being a functional language.

It certainly disqualifies Lisp from being a purely functional language, yes.

But, you know, Haskell was invented in 1990, 40 years after the functional programming style was invented in Lisp.  I really don't want to have to defend Lisp.

Nor should you defend Lisp because it has proved itself over and over again. The study of programming languages is an interesting and rewarding one. The divergence in AI languages is interesting: Lisp in the USA and Prolog in Europe. For a while it seemed that Prolog was dead but it has made a comeback in Constraint Logic languages.

I mentioned that the first language I learned was Forth. Forth, and stack languages generally are also functional in style. Some might like to check out Factor which, although it's appearance is a little hard to get used to is a very interesting language. Some of the ideas in Factor might translate into Snap!

joefarebrother wrote:

in order to support macros we'll probably need a quasiquote block (and unquote, and unquote-splicing, of course).

Yeah.  Not hard to implement, but it'll take some care to work out what quotation means in a blocks language, let alone backquote.

bharvey wrote:

Off topic would be, you know, Lord of the Rings. 

And who started that discussion? 

bharvey wrote:

Read Gödel, Escher, Bach.

Isn't that about consciousness...? (I received a copy for Christmas. It's huge!)

blob8108 wrote:

bharvey wrote:

Read Gödel, Escher, Bach.

Isn't that about consciousness...? (I received a copy for Christmas. It's huge!)

Nah, it's medium-size.  LOTR is huge.

joefarebrother wrote:

in order to support macros we'll probably need a quasiquote block (and unquote, and unquote-splicing, of course).

And a gensym block as well.

bharvey wrote:

blob8108 wrote:

bharvey wrote:

Read Gödel, Escher, Bach.

Isn't that about consciousness...? (I received a copy for Christmas. It's huge!)

Nah, it's medium-size.  LOTR is huge.

Especially in terms of reading time.
@Hardmath123 Do you have a LOTR all-three-in-one type book?

Last edited by technoboy10 (2013-01-16 14:10:13)

nXIII wrote:

How would you call the block you'd defined?

It'd be added to the palette!

What would the empty inputs do?

Sorry, I uploaded the wrong picture.  Read the message again.

How would you define inputs between block labels?

Geez, I dunno, "move %n steps"?  When the time comes, Jens will invent something wonderful.

Last edited by bharvey (2013-01-16 17:57:32)

Hmm.  This "edit" feature is really getting our conversation confusingly out of order. 

nXIII wrote:

So there would be no way to use it later in the same run (without hot-swapping it in)?

The deep question here is about whether there are limits to the self-reflection capability of visual programming.  It already comes up with variables, let alone blocks.  Do we need the ability to type text into the pulldown in SET?

In Berkeley Logo I compromised on your specific question, reparsing at the next command line after a dynamic procedure definition, so you could use it in the same run but not on the same line.

bharvey wrote:

In Berkeley Logo I compromised on your specific question, reparsing at the next command line after a dynamic procedure definition, so you could use it in the same run but not on the same line.

The problem is that there's no such thing as an "interactive shell" in a block-based language (the closest you can come is just assembling a script, running it once, and disassembling it). I suppose there's nothing wrong with having blocks which should only be run while making programs rather than executing them…

The deep question here is about whether there are limits to the self-reflection capability of visual programming.  It already comes up with variables, let alone blocks.  Do we need the ability to type text into the pulldown in SET?

I think the problem is that we have no way of putting together blocks in our code—we can only make static lambdas. If we could, e.g., dynamically create a variable reporter blob at runtime, we could pass that into <set () to ()> and it would work perfectly. The same goes for running blocks, and even defining them: we need a way of assembling blocks from their labels and arguments, and scripts from their blocks.

Yes, I guess so, although in Logo I just refrained from making non-gensym names of the form Gnnnnn.  You want us to make noninterned symbols?  Or you want us to have a DEFINED? predicate and skip over ones that are in use?

I was writing a response, but I realized that (I think) we could just return a quoted local variable block (the name doesn't matter). That way, the variable is guaranteed to be unique and (once reporter-<set () to ()> works) we can both get and set it. For example:

Last edited by nXIII (2013-01-16 18:31:07)

bharvey wrote:

But your sentence starting "If..." may not be right.  We used to have the feature of dragging a variable blob onto SET but it didn't mean to set that variable, which is what everyone expected it to mean.  It meant "look at the value of the variable in the blob, and use that as the name of the variable to set."  So everyone got burned by that, and we disabled dropping blobs onto SET.

Sorry, that was a little confusing. I meant one could create a variable blob at runtime and return that. Whatever you put in the first slot of the <set () to ()> block would be evaluated normally and return the variable blob it got from gensym; <set () to ()>ing that would set the variable pointed to by that variable blob (as it does in BYOB 3.x).

Yeah, that's the uninterned symbol solution.

Oh, OK. I thought by uninterned symbol you meant a name for a variable that couldn't otherwise be created, e.g., a name starting with a NUL character.

Last edited by nXIII (2013-01-16 19:32:40)

Hardmath123 wrote:

@bharvey: How about an (environment []) block that returns whatever the string argument's value is bound to? That way you can test for and call arbitrary variables and functions (like in JS's window.*). Am I missing something here?

That's not what window does. Window is (in the context of a browser) a synonym for the global object (1, eval)('this'). Accessing its properties allows access to global variables. Unless I'm misunderstanding you, <environment ()> would allow access to local variables in the lexical scope of its caller, more akin to eval('typeof name == "undefined" ? undefined : name').

More on-topic, I would love to be able to construct blocks from their labels/inputs/shapes/categories, and with that ability we wouldn't really need any additional facility for variable variables.

EDIT: How about this: We have a block getter <block () () …>. The first and second inputs would look just like Brian's slots above:

The rest of the inputs would be of type any, but they would have a plus-sign editor instead of add/subtract buttons. Clicking a plus sign would bring up an input editor dialog, but instead of inserting slots and labels, it would insert any-type arguments with constant values for labels, and reporters of the form <() input = ()>, <() input list>, or <upvar> (three new operators blocks that construct input slots; the first argument to the first two is a dropdown with Number, Object, etc.) for inputs. You could drag string reporters for variable labels, and slot reporters for variable slots. You could also drag a list into the <block () () …> block containing the parts of the target block, and it would change into a <block () () with parts ()> block.

The <block () () …> block would return a closure in the sprite/stage's global scope wrapping the block described by its arguments. If the category were Variables and the shape were Reporter, it would return a closure in the local scope wrapping the variable blob.

We could also include in the tool package a block that took a list of lists, each describing a block and its arguments, and evaluated it as a script, e.g., [[<set () to ()>, foo, 1], [<say ()>, [<foo>]]]. This could just be implemented using <call ()>/<run ()>

You could use <set () to ()> with a <block () () …> block in the first slot and a closure in the second to define or redefine a block (however, if the block were a variable reporter, it would set the variable, not the block), and you could <call ()> or <run ()> it to evaluate it.

Sorry if that's a bit confusing—mockups coming soon 
Also, I'm aware of all the special-casing for variables, but it's kind of required because variable blobs don't even follow the normal convention of one block for one function, i.e., there are multiple variable blocks that all perform the same function—getting a variable.

Last edited by nXIII (2013-01-16 21:09:27)

LETHAL BUG: Customly renamed upvar names in scripts aren't stored properly, so loading an XML snap file with upvar blocks revert to the default name. This totally wreck scripts that use upvars.