At Sat, 30 Aug 2014 10:25:53 -0700, Kevin Forchione wrote: > > On Aug 30, 2014, at 7:09 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > > > Just for the record, this is my fault for not incrementing the version > > with a change to the compiler's optimizer. > > > > I thought of the optimization as "local" and having no effect on a > > module's interface to other modules. There's no such thing, though, > > since optimizer-inferred properties of a function's body are exported > > with a function, and those properties can change with most any > > optimizer adjustment. > > > Just to fill in another hole in my swiss-cheese education, what do we > mean by “shape” with regard to procedure/structure type?
The term "shape" in the error message isn't meant as any particular, accepted concept outside the optimizer. In this context, "shape" just means information about the value that the optimizer finds worthwhile to track, such as the function's arity and whether it adjusts the continuation-mark stack. > It was the require of a class > that was producing the error, and I’ve gathered that classes are implemented > with structures. It was baffling to my why the module containing the class > compiled without error, but compiling the module requiring it failed. It was > also interesting that the module did compile fine with the latest version, > until I’d tossed the compiled folder in the trash. Running race make on the > top-level file resolved the problem, but I’m wondering why the “run” in > DrRacket didn’t do the same. By default, DrRacket compiles the files that it loads, but it compiles and uses them in "errortrace" mode (the bytecode is kept in a separate subdirectory), so that may have something to do with it. I can't say exactly how it went in your case, but things go wrong in various baroque ways when the optimizer changes and the version number doesn't. _________________________ Racket Developers list: http://lists.racket-lang.org/dev