about summary refs log tree commit diff stats
path: root/mu.vim
Commit message (Collapse)AuthorAgeFilesLines
* 6973Kartik Agaram2020-10-081-1/+1
|
* 6951 - 4 colors for Mu as wellKartik Agaram2020-10-041-1/+4
|
* 6938 - start colorizing floating-point registersKartik Agaram2020-10-031-1/+1
|
* 6697Kartik Agaram2020-08-011-1/+1
|
* 6634 - highlight bad variables in vimKartik Agaram2020-07-111-0/+2
|
* 6630 - define type signatures for SubX functionsKartik Agaram2020-07-101-1/+1
| | | | This was easier than I'd feared.
* 6412Kartik Agaram2020-05-271-1/+1
|
* 6409 - primitives for text-mode UIsKartik Agaram2020-05-271-1/+1
|
* 6399 - make mu.vim work better out of the boxKartik Agaram2020-05-241-2/+6
| | | | | | 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.
* 6398Kartik Agaram2020-05-241-2/+2
|
* 6162Kartik Agaram2020-03-231-5/+10
|
* 6137Kartik Agaram2020-03-121-1/+2
|
* 6078 - highlight hex literals in VimKartik Agaram2020-03-021-1/+1
|
* 6075Kartik Agaram2020-03-021-1/+2
|
* 6068Kartik Agaram2020-02-281-1/+1
|
* 6067Kartik Agaram2020-02-281-0/+58
| | | | Missed the file.
* 5485 - promote SubX to top-levelKartik Agaram2019-07-271-98/+0
|
* 4910Kartik Agaram2019-01-061-4/+4
|
* 4294Kartik Agaram2018-06-301-9/+9
|
* 4293Kartik Agaram2018-06-301-1/+1
|
* 4262 - literal 'null'Kartik Agaram2018-06-171-0/+1
|
* 4261 - start using literals for 'true' and 'false'Kartik Agaram2018-06-171-0/+1
| | | | | | | | | 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.
* 4214Kartik K. Agaram2018-02-211-1/+1
|
* 4165Kartik K. Agaram2017-12-271-9/+19
|
* 4164Kartik K. Agaram2017-12-271-3/+19
|
* 4163Kartik K. Agaram2017-12-241-1/+1
|
* 4134 - 'input' = 'ingredient'Kartik K. Agaram2017-12-031-2/+2
|
* 3976Kartik K. Agaram2017-08-201-1/+1
|
* 3969Kartik K. Agaram2017-07-131-1/+1
|
* 3702Kartik K. Agaram2016-12-061-1/+1
| | | | Commands like '$exit' shouldn't look like labels.
* 3569Kartik K. Agaram2016-10-231-2/+4
| | | | Update syntax highlighting to not color numeric locations like literals.
* 3568Kartik K. Agaram2016-10-231-1/+3
| | | | Fix syntax highlighting for labels after commit 3552.
* 3561Kartik K. Agaram2016-10-221-4/+4
|
* 3431Kartik K. Agaram2016-09-301-16/+13
| | | | | Improvements to syntax highlighting, particularly for Mu code in C++ files.
* 3426Kartik K. Agaram2016-09-271-1/+2
|
* 2838Kartik K. Agaram2016-04-161-1/+1
|
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-2/+2
| | | | | | | | | | | | 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.
* 2562Kartik K. Agaram2016-01-171-1/+0
| | | | | | | | | | | | 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.
* 2367Kartik K. Agaram2015-11-051-1/+1
|
* 2306 - recipe headersKartik K. Agaram2015-10-281-0/+1
| | | | | | | | | | 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!)
* 2295 - drop first-class recipes and continuationsKartik K. Agaram2015-10-281-1/+0
| | | | Making life too complex at this time.
* 2294Kartik K. Agaram2015-10-281-0/+1
| | | | Bah, sick of CALL and continuations.
* 2266 - drop experiment with genericsKartik K. Agaram2015-10-071-1/+1
|
* 2252Kartik K. Agaram2015-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 2174Kartik K. Agaram2015-09-061-1/+2
|
* 2153Kartik K. Agaram2015-09-051-1/+1
|
* 2139Kartik K. Agaram2015-09-041-0/+1
|
* 2080Kartik K. Agaram2015-08-261-0/+1
|
* 2059Kartik K. Agaram2015-08-221-1/+1
|
* 1960Kartik K. Agaram2015-08-091-2/+2
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-06-16 00:19:07 +0000