Scratch

nXIII wrote:

BYOB needs pointers.
Think: you can't make true linked lists without pointers.

No, not true.  The items in a list are already pointers!  You make pairs as (Scratch) lists of length two, where the first item is the element, and the second item is (a pointer to) the rest of the list (another pair, or the empty list).  There's no need to make that pointer explicit; it only confuses the issue and makes the code unreadable.  (In a real first-class-data environment, pointers are in effect the only data type, so the list (foo 27 (x y) ) has a pointer to the string foo, a pointer to the number 27, and a pointer to the list (x y) as its elements.  But since everything is a pointer, you never have to talk about pointers; the dereferencing happens automatically.)

You can't pass variables to be changed within a block.

Ah, here you are pointing (sorry) to a real problem, but I think you have the wrong solution.  You are asking BYOB programmers to think at a very low level of abstraction.  What we need (Jens, on the 3.n list) is downvars, which are like upvars only backwards.  In the custom block's picture in the palette is an empty orange blob, and the only thing you can drag onto it is an actual variable blob (or just maybe we'd allow an [ITEM n OF list] block), and inside the block's definition that input has a name, but whenever that name is used in the script, either in getter or setter form, it really refers to the outer variable.

But I have to say that as a functional programmer I would deplore such programming practice, so maybe it should go on the 3.99 list... 

It would be a simple, yet extremely powerful addition to BYOB.

It would be simple enough to implement, but to use it would take an intellectual leap that I think is about as high as the one for first class functions, or at least the one for recursive functions, and with much less payoff.

Last edited by bharvey (2010-08-03 18:45:44)

2.995.008, this time for sure...

Jens wrote:

after a long night of debugging, optimizing and frenzied testing a follow-up to yesterday's "final beta", this release sweeps up a minor (but awfully hard to track down) bug in the list setter code that prevented Brian's "streams" project to run to completion in this week's previous beta releases. Turns out fixing this bug and tweaking a few other things also and again speeds up some list operations, so now "streams" and "ttt" /does/ run a little faster again.

xly wrote:

What about "nested" sprites ? Is it a new BYOB feature ? How can we use it ?

Ah, that reminds me that I'm behind on documentation. Nested sprites have been introduced since BYOB2, and they are roughly explained in this document.

Jens wrote:

xly wrote:

What about "nested" sprites ? Is it a new BYOB feature ? How can we use it ?

Ah, that reminds me that I'm behind on documentation. Nested sprites have been introduced since BYOB2, and they are roughly explained in this document.

Ha! That nested sprite feature is cool!

sorting by awesomeness, I love it, thanks, fullmoon!

bharvey wrote:

2.995.008, this time for sure...

Jens wrote:

after a long night of debugging, optimizing and frenzied testing a follow-up to yesterday's "final beta", this release sweeps up a minor (but awfully hard to track down) bug in the list setter code that prevented Brian's "streams" project to run to completion in this week's previous beta releases. Turns out fixing this bug and tweaking a few other things also and again speeds up some list operations, so now "streams" and "ttt" /does/ run a little faster again.

The last release of the beta? Am I reading this right?

Jens wrote:

markyparky56 wrote:

bharvey wrote:

2.995.008, this time for sure...

The last release of the beta? Am I reading this right?

Yup, that's right. Preparing the full release now...

That's what you said last time 

I found a bug:
When you try to delete a section of a custom block's title text, it gives you an error. And after that error, you can't edit the block anymore.

Another glitch: if you do something like

say (call(the script[say [Hello!] ]) )

then the sprite would say 'Hello!' forever. It does this as long as there isn't a [report[]] block inside the script.
Also, the (the script[]) block inside the (call()) block can't have the grey outline.

Another glitch (it's amazing how many glitches you always find right before the deadline, isn't it? :) )

If you set a variable to a script, and if that script has a [report[]] block in it, when you do <is (that variable) a [command/reporter/predicate]> it will result in false.

Last edited by rubiks_cube_guy238 (2010-08-05 13:16:00)

rubiks_cube_guy238 wrote:

I think there should be an (argument # () of [a block]) block in the BYOB3 final.

Way too late for 3.0 feature proposals!  Maybe 3.1 or something.

bharvey wrote:

I think you have the wrong solution.  You are asking BYOB programmers to think at a very low level of abstraction.  What we need (Jens, on the 3.n list) is downvars, which are like upvars only backwards.

I would not call pointers a "very low level of abstraction"...

It would be a simple, yet extremely powerful addition to BYOB.

bharvey wrote:

It would be simple enough to implement, but to use it would take an intellectual leap that I think is about as high as the one for first class functions, or at least the one for recursive functions, and with much less payoff.

Much less payoff? It's an important programming concept and you want to ignore it?!

Jens wrote:

bharvey wrote:

nXIII wrote:

You can't pass variables to be changed within a block.

Ah, here you are pointing (sorry) to a real problem

But yes, you can pass a LIST to be changed within a block!

Which shouldn't be.
Why would you want to pass variables by value and lists by reference? It's inconsistent, and I think BYOB programmers should learn that they need to pass by reference to change an object sent.

Last edited by nXIII (2010-08-05 18:25:16)

Wow! Almost to the finally release!!! w00t!