Meeting weekly 2012 08 28 - nejucomo/rust GitHub Wiki
Agenda
Overloaded extern (pcwalton)
Universal equality (pcwalton)
Method call syntax (nmatsakis)
Enum refinements (nmatsakis)
Release status (brson)
Compressing metadata (graydon)
Intern talks this week
eds on Thursday at 12pm (but show up 20 minutes early in case previous talks run quickly)
Overloaded extern
pcwalton: There are four meanings for extern
pcwalton: Basically what I said in my e-mail
pcwalton:
extern mod foo {} vs extern mod foo;
graydon: I want to try and minimize the extent to which people think of linking C and Rust as radically different activities
pcwalton: A (mandatory) attribute that specifies the ABI would go a long way
in particular, on the { form
brson: I think it's incredibly confusing that extern fn means something else...
pcwalton: ...that's the second part. Currently extern fn in the type means a function that closes over nothing.
nmatsakis: it should just not be a type.
pcwalton: what we used to call crust fns ... those have type *u8 but this prevents us from supporting monomorphization and so forth
pcwalton: I propose making extern fn mean that
nmatsakis: A useful thing would be a C function pointer
brson: to call it from Rust, you need to put an ABI in the type
pcwalton: can we make them coercable?
nmatsakis: yes, but you have to generate a thunk
brson: if all we had were external decls of functions, we wouldn't need the whole native mod business
pcwalton: you do need a place to write the linkage details
graydon: I think the extern mod syntax is worth keeping around just to prevent you from writing extern all the time and to help with the linkage information, but it shouldn't carry a lot of other semantic details
pcwalton: especially in systems with 2-level namespaces, it's important to have the name of the library somehow associated with the fn
graydon: this comes into sharp relief in windows
graydon: in linux you can do all kinds of things, but in windows you have to declare it as coming from a particular library
graydon: it would be enough to say that every external function has to have a library attribute, but we could just say that it's taken from the innermost enclosing attribute
nmatsakis: so how do people feel about a type like extern "abi" fn() to mean just a function pointer?
general agreement
pcwalton: then we can get rid of crust fns altogether
general confusion
pcwalton: yes, if we permit coersion from rust to C...
nmatsakis: ...only possible for bare fns (not arbitrary fn values)...
pcwalton: ...yes, only in that case
pcwalton: fns that you wish to use as a callback would just be plain old fn items, but if you use them where an extern "abi" fn is required, it would generate the wrapper at that time
brson: that's a lot of work to do under the hood
graydon: how does that compare to what happens now?
nmatsakis: basically
brson: it is an implicit performance hit...
nmatsakis: why? no worse than today, right?
brson: ...only thing that's worse is that you never create a fn that's slow
nmatsakis/graydon: it feels like the cost of stack switching is something we should solve anyhow
graydon: in particular, the cost of calling Rust->C is the same as C->Rust, and that ain't going away. Maybe stack switching isn't the right approach.
brson: another thing I was wondering: is extern "abi" fn expressive enough to cover the various cases?
nmatsakis: not enough for C++ member functions, but nobody uses those, but to handle name mangling we'd have to make extern fns invariant with respect to argument types (which is fine)
graydon: neither is enough for varargs
graydon: same thing will come up with linking to fortran with its array types
pcwalton: if we ever do want to support linking against C++, the way D does it is instructive: they have a simple subset of well-defined C++ behaviors that permit ABI compatibility
brson: so if we type extern mod do we have to write extern fn inside
pcwalton: it seems like basically the same thing we do today
brson: I think it's better
graydon: we could move over to an extern block, like in C++, so that it doesn't introduce a new namespace
brson: I like that better, too
brson: ok, so if we write extern {...} everything inside of it is an external declaration
nmatsakis: we should pay attention to collect the stack-switching code in trans
Universal Equality
pcwalton: I made some experiments at getting rid of universal ord, very successful
pcwalton: Universal ord (<, >) is pretty much never used
pcwalton: I removed universal "<" but I think it's never used
brson: What would be the plan for "<="
graydon: I saw you working on this and it harkened back to some very old questions
graydon: good defaults for cmp, memcmp (and ignoring holes), deep/shallow equality, tc
graydon: I'm increasingly thinking we made the wrong decision here in terms of taking control from the user
graydon: maybe the best thing is to implement the basics and let the users override as they want to
pcwalton: I implemented it for many types (option, [], pairs)
graydon: you talked about an automatic deriver...
graydon: that doesn't sound too loopy to me
pcwalton: I was actually thinking that you could do it sort of like Haskell does it
pcwalton: the only derivers we actually need are enum/struct
nmatsakis: this is a nice convenience
graydon: ...shades of Scrap Your Boilerplate...
pcwalton: the nice thing is that we can bake most of it into core
nmatsakis: as long as you don't mind that it only works for tuples up to some size
pcwalton: are people ok with me continuing work on this?
nmatsakis: have you tried universal equality?
pcwalton: working through it, it's mostly mechanic transformations
nmatsakis: I've had bugs on universal equality from time to time so I'm not a big fan
graydon: is this rubbing anyone the wrong way? only heard from 3 of us
tjc: it's fine by me, same as haskell, I don't feel I rely on universal eq a lot
graydon: particularly if tuples work
Method call syntax
nmatsakis: Do we want a.b() to mean as either a field-with-closure-type or a method? I'm gonna be refactoring the AST and if we wanted to change it'd be a convenient time
graydon: I'm ok with that, now we have real methods, a record filled with closures seems like it won't be common
nmatsakis: a record w/ closures kind of seems like an anti-pattern to me
graydon: it deletes the ambiguity
nmatsakis: brson, tjc?
brson: I kind of disagree that it won't be used a lot, I can imagine some scenarios, but I still think we should do it
graydon: triage will be necessary, shall we spend an hour or two together going through it?
tjc/brson: yes that could be useful
graydon: honestly this is something that most of the rest of Mozilla does regularly, we ought to do as well, it would probably help us with prioritiziation
graydon: is there anything more you wanted to discuss?
Compressing metadata
graydon: our metadata tables are enormous. Part of it was a debugging flag that Niko left on (ed: d'oh!)
graydon: nonetheless our metadata section is many times larger than our code
nmatsakis: could be partly because of generic fns whose code may not be generated
graydon: in any case, it's not necessarily bad that it's big, we could get easy benefits by running some compression on the data
nmatsakis: that would prevent us from having random access