Adding some more colors will improve the experience, but the choices depend
on colorscheme, and first impressions should at least not seem to have
degraded things.
They uncovered one bug: in edit/003-shortcuts.mu
<scroll-down> was returning 0 for an address in one place where I
thought it was returning 0 for a boolean.
Now we've eliminated this bad interaction between tangling and punning
literals.
I'm dropping all mention of 'recipe' terminology from the Readme. That
way I hope to avoid further bike-shedding discussions while I very
slowly decide on the right terminology with my students.
I could be smarter in my error messages and use 'recipe' when code uses
it and 'function' otherwise. But what about other words like ingredient?
It would all add complexity that I'm not yet sure is worthwhile. But I
do want separate experiences for veteran programmers reading about Mu on
github and for people learning programming using Mu.
We want to use the type 'recipe' for recipe *variables*, because it
seems nicer to say `recipe number -> number` rather than recipe-ordinal,
etc. To support this we'll allow recipe names to be mentioned without
any type.
This might make a couple of places in this commit more brittle. I'm
dropping error messages, causing them to not happen in some situations.
Maybe I should just bite the bullet and require an explicit
:recipe-literal. We'll see.
Once a student has gotten used to recipes and ingredients using the
staged 'next-ingredient' approach there's no reason to avoid
conventional function headers. As an added bonus we can now:
a) check that all 'reply' instructions in a recipe are consistent
b) deduce what to reply without needing to say so everytime
c) start thinking about type parameters for recipes (generic functions!)
I can't easily use generic containers without needing some syntax for
generic recipes:
push:number a:number, l:list:number
which would be implemented as:
T <- next-type
a:T <- next-ingredient
etc.
Another concern: how to represent map<string, list<number>>?
map::address:array:character::list:number
where the '::' is just silently turned into ':'.
Agh, all this is so baroque. All this while I've been trying to avoid
getting into language design. All I want is some lightweight way to
avoid security holes and memory corruption. But now it seems like I need
facets to control compile-time activities and so on.
Kartik Agaram