about summary refs log tree commit diff stats
path: root/053recipe_header.cc
Commit message (Collapse)AuthorAgeFilesLines
* 3752 - fix a couple of segfaultsKartik K. Agaram2017-03-021-3/+21
| | | | Thanks Ella Couch for running into these.
* 3744Kartik K. Agaram2017-02-071-1/+1
| | | | | | Undo 3743. Really any time we create new instructions from whole cloth during rewriting or transform, the whole notion of 'original name' goes out the window. Pointless trying to fight that fact of life.
* 3743Kartik K. Agaram2017-02-071-1/+1
| | | | | | | | One way to ensure we always set old_name is to create a method to initialize names as opposed to just assigning them. Still not ideal because we still assign directly most of the time, so it's easy to forget.
* 3657 - better error messageKartik K. Agaram2016-11-101-0/+10
| | | | Thanks Ella Couch for reporting this.
* 3656Kartik K. Agaram2016-11-101-13/+13
| | | | | | | | | | | | | | Periodic cleanup to replace 'reply' with 'return' everywhere in the repo. I use 'reply' for students to help reinforce the metaphor of function calls as being like messages through a pipe. But that causes 'reply' to get into my muscle memory when writing Mu code for myself, and I worry that that makes Mu seem unnecessarily alien to anybody reading on Github. Perhaps I should just give it up? I'll try using 'return' with my next student.
* 3598 - 'use before set' errors were too crypticKartik K. Agaram2016-10-271-1/+1
|
* 3587Kartik K. Agaram2016-10-241-0/+9
| | | | Another CI fix.
* 3576Kartik K. Agaram2016-10-231-0/+28
| | | | More helpful messages when people forget 'load-ingredients'.
* 3555Kartik K. Agaram2016-10-221-1/+1
|
* 3554 - flag unexpected header for recipe 'main'Kartik K. Agaram2016-10-221-0/+43
| | | | | | As long as Mu operates atop Unix, we need to make these assumptions. Thanks Ella Couch for finding this loophole.
* 3541Kartik K. Agaram2016-10-211-3/+1
|
* 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-20/+20
|
* 3437Kartik K. Agaram2016-10-041-0/+1
| | | | | | | | Drop an ancient case of premature optimization: skipping transform for recipes without bodies. These days recipes also have headers that need transforming. Thanks Caleb Couch for running into this issue.
* 3393Kartik K. Agaram2016-09-171-3/+2
|
* 3390Kartik K. Agaram2016-09-171-1/+1
|
* 3389Kartik K. Agaram2016-09-171-2/+2
|
* 3385Kartik K. Agaram2016-09-171-37/+37
|
* 3379Kartik K. Agaram2016-09-171-2/+2
| | | | Can't use type abbreviations inside 'memory-should-contain'.
* 3341Kartik K. Agaram2016-09-121-0/+22
| | | | | | | Process type abbreviations in function headers. Still a couple of places where doing this causes strange errors. We'll track those down next.
* 3324 - completely redo type abbreviationsKartik K. Agaram2016-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The old approach with '&' and '@' modifiers turned out to be a bad idea because it introduces notions of precedence. Worse, it turns out you want different precedence rules at different times as the old test alluded: x:@number:3 # we want this to mean (address number 3) x:address:@number # we want this to mean (address array number) Instead we'll give up and focus on a single extensible mechanism that allows us to say this instead: x:@:number:3 x:address:@:number In addition it allows us to shorten other types as well: x:&:@:num type board = &:@:&:@:char # for tic-tac-toe Hmm, that last example reminds me that we don't handle abbreviations inside type abbreviation definitions so far..
* 3120Kartik K. Agaram2016-07-211-4/+4
| | | | | | | | Always show instruction before any transforms in error messages. This is likely going to make some errors unclear because they *need* to show the original instruction. But if we don't have tests for those situations did they ever really work?
* 3062Kartik K. Agaram2016-06-191-0/+4
|
* 2990Kartik K. Agaram2016-05-201-6/+6
| | | | | | | | | | 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/+492