Hello. As the title states, I wanted to suggest custom speech balloon formatting for reporters and predicates (when clicked in the editor). Like Scratch, the balloon can display a text string or number. However, Snap*!* has first-class lists, blocks, and objects—all of which can be shown in a balloon. Two-dimensional lists can even appear as tables! I don't have any issues with these, but they can be restrictive if you are trying to implement foreign data structures or would just like to display the content differently (for convenience). Additionally, custom formatting could be used in variables, lists, and even sprite speech balloons if made first-class.
For example, I have recently been interested in non-imperative paradigms, and I am trying to implement aspects of declarative programming. Since Snap*!* is imperative, I am using lists to represent each fact and rule (via a custom reporter). The list content has to be purely functional because it is being parsed by other reporters, and extra words would just be syntactic sugar. Other users could probably infer what the list outputs mean, but it would be really nice if I could represent rules as A ⇒ B (alongside representations for other structures).
I think one way this could be added is through set [speech balloon V] of block ((. . .)::ring) to (. . .), but it might be difficult to create image-based displays (that would allow more flexibility). Another way would be through the make-a-block screen, but then it might not be accessible from the definition (if you wanted to create dynamic speech balloons). My preference is the former (with a possible editor that aids with the creation of displays).
yes, I agree that would be awesome, and we've talked about it. Now with the latest additions of data objects customizable "print" / "display" formats would be really nice. On my list, but don't hold your breath...
Imho the custom formatting should be associated, not with specific blocks, but with a custom (abstract) data type. The paradigmatic example is exact rational numbers, implemented as a two-item list (numerator and denominator), but displayed as "n/d" rather than as (list n d). Instances of an abstract type would include a type tag as well as the value.
The reason types not blocks is that, in this example, every block that reports a number would be able to report a (properly formatted) rational number.
I agree that the formatting should be associated with custom data types, but the reason why I suggested the formatting be set for each block is that it would let the creator of the block determine when each type should be used.
Using your example (but with my set-for-each-block argument), every reporter that performs a mathematical operation would include the "determination" as a script within its definition. Since all blocks that require such operations must include the mathematical reporters, they indirectly inherit the abstract type as a possible output. In this case, no manual typecasting is needed.
Oh, and now that we've brought up abstract types...
You could add typecast rings like ([type name here V][]) for non-list and non-costume types. They wouldn't be practical for the current built-in scalars, but it would let Jens remove Booleans being typecast into integers...
Going back to the rational number example, Snap! would also have to let custom types alter what they report depending on the context. If someone tries adding 1/2 (list of 1 and 2) and another constant (or list) normally, it will try applying the operation to each term.
We inherit this behavior from Javascript, whose Booleans are integers. I don't think there's any danger of us changing it, especially because a lot of APL idioms depend on it.
I think it's I who didn't like it, but I've changed my mind because of APL.
Nah, that runs the risk of forgetting one of them, square root or something. The math functions should be above the exact-rational abstraction barrier. There should be a function MAKE RATIONAL (num) (den) that reports a type-tagged rational number, and you're not allowed to ask for ITEM 1 OF it, even if below the abstraction barrier it's implemented with a list. (Instead the abstraction provides functions NUMERATOR and DENOMINATOR that take an exact rational as input. If you make a list of exact rationals, it's a vector, not a matrix. (That is, RANK OF the list will report 1, not 2. RANK OF a rational number, as for any scalar, is 0.)
Then maybe the "number" type could inherently support rational expressions, though it would be a pain to stop it from returning them when you don't want it to...Ehh, I see what you mean.
If the implementation of abstract types is hidden behind the abstraction barrier, then there should be a way to deconstruct the barrier to deal with these types via traditional means. Maybe a (deconstruct ()) reporter would suffice, but I don't know if there is a formal term for this.
I get your point, but if an exact-rational type were implemented, wouldn't it be best for Snap! to provide more generic functions to not clog the palette with blocks for each type (not including blocks for custom types)? If I'm misunderstanding you, how would the NUMERATOR and DENOMINATOR functions be provided?
And on the same topic, the shape pedagogy used to represent different types would be disrupted by custom types. (I don't think custom shapes would be a great idea, but that's just me.) I assume that custom types would be implemented as reporters.
In terms of format, yes—what you showed would be a possibility of the custom formatting system. But no, I am not suggesting that a compare lists @list @list @delInput @verticalEllipsis @addInput::lists reporter custom block should inherently display "Calculating X position and comparing..."
Now that this discussion has extended to custom types, I think it's safe to do away with my old custom formatting proposal, but I will leave it in the original post.
(How did you get that result pic, by the way? Is that edited?)
No, I'm imagining that they'd all be Object type for input-slot purposes. I think having a zillion input slot shapes would be counterproductive. Visual symbols (vs. text) are effective as long as there aren't too many of them to remember.
