Oh! That's brilliant! There are gazillions of places in my projects where THIS INPUTS could be used that way: all the constructors for abstract data types, for example. Thank you for teaching me about it. :~)
I love this!!
oh yeah for sure. I don't want to get too sidetracked, but even the go to x: () y: () block's definition could be changed to go to (this [inputs V]) rather than go to (list (x) (y) @delInput @addInput).
on an on-topic note, the custom speech bubble blocks (the costume part) is reporting an empty costume for me, rather than the correct one, even when I use the demo of the fraction type in the project. is it broken or just my computer?
Same thing here. It worked at first (reporting 1/2), but after I used it once, it stopped working. I'm currently building off of what @pajamaclaws21 made, so I'll keep you posted in this topic.
By the way, do you think we should make the latter part of this discussion its own topic in Share your Projects?
yeah.
oh good, it wasn't just me.
yeah unfortunately my implementation has started breaking, the division operator returns an error for some reason when it shouldn't, and there's just like loads of sometimes something won't work
I'll go back to work with mine, then.
I'm currently working on having custom types extend other custom types. That should be easy, but I'm new to metaprogramming, so it might take a little longer.
I'm also trying to implement dynamic type outputs. Theoretically, custom types will be able to adjust how they are evaluated depending on their contexts, which should reduce the number of conversions necessary per script.
How does this increase performance?
Fixed this in a test version! I will release it with the sub-subtypes and call context variations.
idk how it does, but for some reason it runs faster for me.
nice.
Also: can the blocks be updated to use scripted menus reporting all the types, and can the create custom type block, where it says name: [fraction] :: operators have an upvar to be ((name)) :[fraction] ::operators which just reports the name so that we could just use that in the conversion blocks?
the fractions in
https://snap.berkeley.edu/snap/snap.html#present:Username=pajamaclaws21&ProjectName=custom%20datatype%20tests
seem to be working again.
Yes, that's also part of the test, alongside a (type hierarchy::#526e85) reporter.
How do you mean? I understand how the (name)upvar should work, but why would it be useful for conversions? Would this come with a type dropdown for the conversion reporters (because as @pajamaclaws21 has it, there are individual reporters for each extended type)?
Oop-
I seem to be using @pajamaclaws21's old code, which uses one block to declare types, conversions, and methods....Whoops.
I guess I now have to update what I have? lol. When was this updated??
idk, but its a lot better now.
I've updated my version to match @pajamaclaws21's second test (I'll just call it pajama2 in the future because I'm too lazy to type it out lol). However, I have made their blocks more convenient, and you no longer have to reveal the input names of the rings to make them function correctly! You can also delete types, which is great for debugging them.
There is one glaring issue, though. Snap! currently has a bug where variadic input groups (what I used to make the conversion and method blocks) are not saved correctly, so upon opening the project, the blocks will be completely wrong. Because of that, you have to use the following:
It looks terrible, but everything will work well once the bug is fixed! Time to work on call context variations...
Update: the "bug" I mentioned is not really an error but more of an unintended consequence.
The slots keep getting messed up because the blocks have one more expansion label than the number of slots. However, I can't reduce the number of expansion labels because one of the labels is $nl, which only creates a new line if it is by itself and not joined with more text. So I have three options:
- Get rid of the odd formatting and just work around it.
- Try to rework the labels to get the same result but without the issue.
- Suggest that
$nlshould work alongside text in the same label.
I have wanted that too. Not high priority, alas.
I'm glad to hear that it's been considered!
By the way, is there an antonym for "continuation?" The goal of the type variations is to allow for polymorphism within the type constructors and not just their methods. Referencing your reply about editing say [] to recognize type printforms, adding a different output for constructors within those say primitives would let the printforms be managed internally. While this could be implemented easily in Snap!, I'd like to create presets. One of those presets would check for a condition relating to the previously executed portion of the script. So...is there a formal term for the opposite of a continuation?
Not that I know of. Typically what you want to know about the computation up to this point is the state in which it's left the program (values of variables and so on), rather than how it got to that state. So in a way I guess you could say the opposite of "continuation" is "state."
I just had a use for this!