about summary refs log tree commit diff stats
path: root/mu.vim
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* 1903Kartik K. Agaram2015-07-301-0/+5
|
* 1868 - start using naked literals everywhereKartik K. Agaram2015-07-281-0/+2
| | | | First step to reducing typing burden. Next step: inferring types.
* 1780 - now we always reclaim local scopesKartik K. Agaram2015-07-131-1/+1
| | | | | | But still no difference in either memory footprint or in running time. This will teach me -- for the umpteenth time -- to optimize before measuring.
* 1774Kartik K. Agaram2015-07-131-1/+1
|
* 1771Kartik K. Agaram2015-07-131-1/+2
|
* 1646Kartik K. Agaram2015-06-251-1/+1
|
* 1555 - mu.vim: distinguish control-flow from constantsKartik K. Agaram2015-06-121-5/+7
| | | | We also do this in regular C++ now.
* 1506Kartik K. Agaram2015-05-281-1/+1
|
* 1432 - contrast scenarios and recipesKartik K. Agaram2015-05-231-2/+3
|
* 1410Kartik K. Agaram2015-05-201-1/+2
|
* 1378Kartik K. Agaram2015-05-151-0/+1
|
* 1333Kartik K. Agaram2015-05-101-3/+11
|
* 1331Kartik K. Agaram2015-05-101-2/+4
|
* 1327 - better error handling in chessboardKartik K. Agaram2015-05-101-1/+1
| | | | | Also a bugfix in break to label, because I noticed the screen wasn't being cleaned up on quit.
* vim highlighting for labelsKartik K. Agaram2015-04-181-1/+2
|
* 1093 - little more vim support for the old arc versionKartik K. Agaram2015-04-171-0/+2
|
* 1048Kartik K. Agaram2015-04-111-5/+5
|
* 1025 - switch syntax highlighting to support c++ versionKartik K. Agaram2015-04-061-6/+5
|
* 561 - vim hackKartik K. Agaram2015-01-131-4/+7
|
* 548 - hacky vim filetype for muKartik K. Agaram2015-01-131-0/+37