about summary refs log tree commit diff stats
path: root/mu.vim
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* 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
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-14 12:29:58 +0000