about summary refs log tree commit diff stats
path: root/052tangle.cc
Commit message (Collapse)AuthorAgeFilesLines
* 3675Kartik K. Agaram2016-11-151-2/+2
|
* 3552Kartik K. Agaram2016-10-221-2/+1
| | | | | | | | | | | | | | | | | | Stop requiring jump instructions to explicitly provide a ':label' type for jump targets. This has been a source of repeated confusion for my students: a) They'd add the ':label' to the label definition rather than the jump target (label use) b) They'd spend time thinking about whether the initial '+' prefix was part of the label name. In the process I cleaned up a couple of things: - the space of names is more cleanly partitioned into labels and non-labels (clarifying that '_' and '-' are non-label prefixes) - you can't use label names as regular variables anymore - you can infer the type of a label just from its name
* 3549Kartik K. Agaram2016-10-221-12/+16
| | | | | | | | | | | | | | | | | | More consistent definitions for jump targets and waypoints. 1. A label is a word starting with something other than a letter or digit or '$'. 2. A waypoint is a label that starts with '<' and ends with '>'. It has no restrictions. A recipe can define any number of waypoints, and recipes can have duplicate waypoints. 3. The special labels '{' and '}' can also be duplicated any number of times in a recipe. The only constraint on them is that they have to balance in any recipe. Every '{' must be followed by a matching '}'. 4. All other labels are 'jump targets'. You can't have duplicate jump targets in a recipe; that would make jumps ambiguous.
* 3539Kartik K. Agaram2016-10-211-0/+10
| | | | | | | | | | | | | Always check if next_word() returned an empty string (if it hit eof). Thanks Rebecca Allard for running into a crash when a .mu file ends with '{' (without a following newline). Open question: how to express the constraint that next_word() should always check if its result is empty? Can *any* type system do that?! Even the usual constraint that we must use a result isn't iron-clad: you could save the result in a variable but then ignore it. Unless you go to Go's extraordinary lengths of considering any dead code an error.
* 3522Kartik K. Agaram2016-10-191-6/+6
|
* 3392Kartik K. Agaram2016-09-171-2/+7
| | | | Bugfix for the "remaining bug" mentioned in commit 3391.
* 3385Kartik K. Agaram2016-09-171-56/+56
|
* 3108Kartik K. Agaram2016-07-101-1/+0
|
* 3001Kartik K. Agaram2016-05-241-4/+8
|
* 2990Kartik K. Agaram2016-05-201-4/+4
| | | | | | | | | | Standardize quotes around reagents in error messages. I'm still sure there's issues. For example, the messages when type-checking 'copy'. I'm not putting quotes around them because in layer 60 I end up creating dilated reagents, and then it's a bit much to have quotes and (two kinds of) brackets. But I'm sure I'm doing that somewhere..
* 2987Kartik K. Agaram2016-05-201-0/+448
|
* 2971Kartik K. Agaram2016-05-171-448/+0
| | | | | | Long-overdue reorganization to support general 'dilated' reagents up front. This also allows me to move tests that are really about unrelated layers out of layers dealing with parsing.
* 2883 - another warning in the spirit of 2882Kartik K. Agaram2016-04-281-0/+31
| | | | | | All code to be tangled at a label should be defined between two calls to transform_all(). This property is trivially satisfied if a production run only ever has one call to transform_all().
* 2872 - tangle directive spurious errors fixedKartik K. Agaram2016-04-271-7/+8
|
* 2773 - switch to 'int'Kartik K. Agaram2016-03-131-5/+5
| | | | This should eradicate the issue of 2771.
* 2735 - define recipes using 'def'Kartik K. Agaram2016-03-081-13/+13
| | | | | | | | | | | | 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.
* 2712Kartik K. Agaram2016-02-261-4/+4
|
* 2680Kartik K. Agaram2016-02-201-4/+4
| | | | Delete all the [] that has crept in since 2377 in November.
* 2678Kartik K. Agaram2016-02-201-1/+1
| | | | | | | Start using type names from the type tree rather than the property tree in most places. Hopefully the only occurrences of 'properties.at(0).second' left are ones where we're managing it. Next we can stop writing to it.
* 2611Kartik K. Agaram2016-01-271-1/+1
|
* 2557 - type-check most ingredients ahead of timeKartik K. Agaram2016-01-121-6/+0
|
* 2494Kartik K. Agaram2015-11-281-1/+1
| | | | | Some more structure to transforms, and flattening of dependencies between them.
* 2383 - new concern: idempotence of transformsKartik K. Agaram2015-11-061-2/+2
| | | | | I'd not paid any attention to it so far, but I need to do so from now on.
* 2379 - further improvements to map operationsKartik K. Agaram2015-11-061-6/+6
| | | | | | | Commands run: $ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) != [^.]*\.end()/contains_key(\1, \2)/g' 0[^0]*cc $ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) == [^.]*\.end()/!contains_key(\1, \2)/g' 0[^0]*cc
* 2377 - stop using operator[] in mapKartik K. Agaram2015-11-061-4/+4
| | | | | | | | | | | | | | | | I'm still seeing all sorts of failures in turning on layer 11 of edit/, so I'm backing away and nailing down every culprit I run into. First up: stop accidentally inserting empty objects into maps during lookups. Commands run: $ sed -i 's/\(Recipe_ordinal\|Recipe\|Type_ordinal\|Type\|Memory\)\[\([^]]*\)\] = \(.*\);/put(\1, \2, \3);/' 0[1-9]* $ vi 075scenario_console.cc # manually fix up Memory[Memory[CONSOLE]] $ sed -i 's/\(Memory\)\[\([^]]*\)\]/get_or_insert(\1, \2)/' 0[1-9]* $ sed -i 's/\(Recipe_ordinal\|Type_ordinal\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]* $ sed -i 's/\(Recipe\|Type\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]* Now mu dies pretty quickly because of all the places I try to lookup a missing value.
* 2360Kartik K. Agaram2015-11-041-2/+2
| | | | | | | | | More flailing around trying to come up with the right phase ordering. I've tried to narrow down each transform's constraints wrt transforms in previous layers. One issue that keeps biting me is the Type map containing empty records because of stray [] operations. That's gotta be important.
* 2358 - starting to tackle the phase ordering problemKartik K. Agaram2015-11-041-3/+3
| | | | | | | A new externality is starting to make its presence felt. Until I sort this out it's going to be hard to finish making duplex-list generic.
* 2357Kartik K. Agaram2015-11-041-1/+1
|
* 2306 - recipe headersKartik K. Agaram2015-10-281-2/+4
| | | | | | | | | | 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!)
* 2283 - represent each /property as a treeKartik K. Agaram2015-10-261-1/+1
|
* 2258 - separate warnings from errorsKartik K. Agaram2015-10-061-7/+7
| | | | | | | At the lowest level I'm reluctantly starting to see the need for errors that stop the program in its tracks. Only way to avoid memory corruption and security issues. But beyond that core I still want to be as lenient as possible at higher levels of abstraction.
* 2149Kartik K. Agaram2015-09-051-2/+2
|
* 2138 - warn on jump to an ambiguous labelKartik K. Agaram2015-09-041-41/+172
| | | | | | | | | | | | | | | | | | | | This seemingly simple goal uncovered a little nest of bugs: it turns out I've been awash in ambiguous labels until now. My baseline recipes in edit.mu were clean, but they introduced duplicate <waypoints> -- and *those* waypoints contained +jump-targets. Result: duplicate jump targets, so that I wasn't jumping where I thought I was jumping. Somehow I happened to be picking one of the alternatives that magically kept these issues quiescent. My first plan to fix this was to mangle names of all labels inside before/after fragments, keep the jump targets private to their fragment. But the labels also include more waypoints! Mangle those, and I can't tangle to them anymore. Solution: harden the convention that jump targets begin with '+' and waypoints are surrounded by '<>'. Mangle jump targets occurring inside before/after fragments to keep them private to their lexical fragment, but *don't* mangle waypoints, which must remain globally accessible.
* 2095Kartik K. Agaram2015-08-281-4/+0
| | | | | | | | | | | | Finally terminate the experiment of keeping debug prints around. I'm also going to give up on maintaining counts. What we really need is two kinds of tracing: a) For tests, just the domain-specific facts, organized by labels. b) For debugging, just transient dumps to stdout. b) only works if stdout is clean by default. Hmm, I think this means 'stash' should be the transient kind of trace.
* 1945Kartik K. Agaram2015-08-061-19/+68
| | | | | | Turns out it is indeed useful to insert code at multiple duplicate labels within a single (long) recipe. Like handle-keyboard-event in edit.mu.
* 1939 - allow nested tanglingKartik K. Agaram2015-08-051-30/+49
| | | | However, you can't have duplicate labels within a single recipe.
* 1938 - warn on unused before/after fragmentsKartik K. Agaram2015-08-051-0/+27
|
* 1870Kartik K. Agaram2015-07-281-0/+198