Custom Reporter Speech Balloon Formatting (and Custom Types)

[blockpointstudios]

I noticed that I tended to use script variables ((foo type)) set [foo type V] to (type [foo]@delInput : @verticalEllipsis@addInput:: #526e85) a lot to create local types, so I decided to add script type ((foo)):@verticalEllipsis@addInput ::#526e85. It's proven useful so far!

Also, type names have been replaced with identifiers. I don't know why I didn't think of this for 1.1, but using list reference comparisons, you can check if a value is of a certain custom type!

For fun, I've repurposed my fraction type to show that supposedly identical values of the "same" type are not equal because of their identifiers! In this crazy-looking example, map creates the fraction type twice, and thus they are not the same. My usage of call here isn't really practical, though. If you were to compare types, then you'd probably create them outside of a call or run primitive. I'm using call here for a more simplistic result pic.

[sathvikrias]

@blockpointstudios

It's proven useful so far

maybe make the variadic input static? seems strange compared to the script variables ((a)) @addInput block.

@blockpointstudios

list reference comparisons,

of course!

[blockpointstudios]

@sathvikrias

maybe make the variadic input static?

Oh, I did that for the script tags block but not the script type block because you need to enter parameters for types (hence why it says "type" and not "types"). I should've shown this:

Compare that to the reporter:

Those are unlike...

...whose only parameter is stored within the dropdown.

[sathvikrias]

that makes more sense. is 2.0 anywhere near release?

[blockpointstudios]

@sathvikrias

is 2.0 anywhere near release?

The features I've shown are very close to being finished. I could release them separately if you'd like to try 'em out.

However, I've also promised to add...

@blockpointstudios

...constraints, functors...linear types, custom errors, monads (with non-local exit)...and easier parallel type computations.

...which I haven't even started implementing lol.

[blockpointstudios]

I've added the ability to create a type construction script from types themselves! This will be useful for my version conversion library. If you made a project using 1.1 (which I don't think anyone did), you will be able to port it. I'm keeping TYOT 1.1 as a separate project, so if you ever revisit it, you can save your progress.

[bh]

@blockpointstudios

All items can be tested for equality.

I'm pretty sure this is not the case for procedures in Scheme. I could've sworn it wasn't in Snap! either, but that seems to have changed:


I guess it works by comparing the SPLIT BY BLOCKS lists? Because it falsely reports True when the two functions have the same form but different relevant environment variables:

I hereby declare this a bug, although I'm not sure Jens will agree. This sort of thing is the reason why Scheme just always says two procedures that aren't EQ? aren't EQUAL? either even if they compute the same function.

Your rational number comparison doesn't work either:

[blockpointstudios]

@bh

I could've sworn it wasn't in Snap*!* either, but that seems to have changed:

That's weird. When I was testing contextual variations, I found that procedures were considered equal even if they had different inputs. I'll try to reproduce it.

@bh

Your rational number comparison doesn't work either:

But it does! You may debate me on this, but while 2/5 and 4/10 are mathematically equal, they are not identical. I know I'm testing for "equality," but the identities of the two values are different. If you really wanted to check if they were mathematically equal, you could convert them to the primitive number type and then check for equality.

Looking at them a bit differently, “fractions” could refer to the result of a divided by b. One could argue that fractions, as represented by the type, are not unevaluated computations but rather simple vectors intended for similar usage. In that case, my “fraction” type would not actually match my definition, but it would fulfill the requirements of equality for first-class citizens.

Actually, there's a different mistake in that fourth example. I said that types were first-class, not the values (though they are too). The script pic really should've been this:

[blockpointstudios]

Constraints are almost done. (They’re easy to implement, but I’ve just been fixing existing tag functionality.) Then, I’ll focus on some other type tag quirks required to create functors (see below).

I have thought a lot about functors, applicatives, and monads. I’ve concluded that a Haskell-style implementation wouldn’t be very intuitive. I’m keeping the same terms and names (for now), but functors will use another new feature that I'll likely share soon.

I'm also trying to reduce clutter in the palette. I keep rereading Bringing "No Ceiling" to Scratch, and I'm always impressed by how many capabilities were added with so few blocks. TYOT's Type Construction category is as long as the original Type Creation category, but the Tag Management category is full of shortcuts for features I feel users might be confused about.

global type tag, global block tag: Not necessary. I could possibly condense 'em into one block.
tag constructor, contents of, subtags of: The first was added because I kept getting annoyed with script variables lol. The last two could be condensed.
script tags, add to, remove from, clear: These are the essentials. I wish I could just reuse the equivalent list primitives, but I'm avoiding modifying primitives in case I have to reset the palette.
proprietary conditions, distribution: I had trouble with the wording. These are supposed to add requirements to tags; the first allows items in, and the second modifies items that made it in. I'll probably adjust the labels.
palette type tag, add to palette, clear palette: I believe the first is fine, but the last two are just redundant. If I were to get rid of these, I'd add their functionality to the add to and clear blocks. It's a bit tricky, though, since I would have to add special cases for the palette.
tag construction script: Not necessary, but it'll be useful in the future for porting to other versions.
reset TYOT tags, stabilize block tag: The first is nice to have since the native tags can easily get messed up. The second could be created by the user, but I thought it would be good to add. If I had to remove any other blocks, this would probably be my first choice. (If you're wondering what it does, it takes a block tag and evaluates all of its block conditions so that it no longer dynamically updates.)

Tell me what you think! If you have any other ideas or feedback, please share!

[blockpointstudios]

Type parameter constraints are done! I've also completed tag requirements and distribution.