Hi Everyone,
I'm Siyao and I want to participate in GSoC this year. I am planning to work on one of the projects on the idealist which is creating build-in blocks for commonly used functional programming operators.
One idea that comes up to me while writing the proposal is to define strictly typed data structures. The commonly used functional operators require input with a consistent type, for instance, the map operator wants to transform a list by incrementing each item by one would expect the list to be a List containing only numerical values.
The YailList and YailDictionary both allow mixed data types. We could simply catch the type errors if any occur during runtime, but having strictly typed data structures can allow users to debug ahead of runtime. Strictly typed data structures also create a more precise requirement for the functional operators that I am planning to implement. I also think there are probably other use cases of strictly typed data structures for future implementation as well.
I would love to hear your opinion on
- whether this idea is worth implementing or should we keep runtime type error check,
- if it is feasible since there might be constraints that I am not aware of,
- if it is reasonable to add this as part of creating functional operator blocks since it is technically not a part of the planned project idea,
- or any other idea related to this feature and project.
Thank you for your help! 
3 Likes
Hello! This sounds like a really cool idea! But I want to warn you, implementing parameterized types like Maps with Blockly has no built-in support 
I actually had a project where I attempted to implement this, and it turned out to be more than I could handle.
App Inventor has changed some things with Blockly (eg adding function type checks instead of just string arrays) so it may be possible to implement parameterized types. But I would definitely be cautious because it's really tricky. If you do decide to pursue this idea I would add some constraints:
- Don't worry about subtypes or super types, all types are just types
- All parameterized types are invariant (should be a consequence of the above)
- All parameterized types are homogenous (this might break existing projects)
Best of luck with your summer project! If you have any questions/need help feel free to reach out!
--Beka
3 Likes
Thank you for sharing your thoughts and experience!
I see that the implementation for types requires a lot of work and I might end up not having enough time to finish it during the summer. Since the original project idea was to implement functional programming blocks and the implementation of types is not a requirement for that, I decided to keep it as a potential future work to implement.
Also just building on @BeksOmega 's response here, App Inventor converts the blocks to YAIL, which is our own dialect of Scheme. Scheme doesn't really have a concept of generics in this sense. As far as we are concerned, a YailList or a YailDictionary can hold any other type. The idea of a more strongly typed type for App Inventor is interesting, but you will want to put some thought into how this interacts with the rest of the App Inventor ecosystem.
1 Like
@ewpatton Thanks for replying! When I was trying to come up with a potential implementation approach I also noticed that the blocks are converted to YAIL. I figured that achieving the strongly typed type will require careful design to work with the other parts of App Inventor. For now, I only have one scratch idea of how it could be done, and I have put it in the Future Work section of my proposal. If time permits I would like to try the implementation in the future.
Here's my proposal for the project Functional Operators in the Blocks Editor: Link
Although it was submitted in the GSoC application, I would still LOVE to hear more feedback on how you all think of the overall design and how to improve the implementation plan.
Thank you for your time and help! 
2 Likes
@siyaoli It is really interesting.
1 Like