Re: [rust-dev] strings, slices and nulls
Graydon Hoare wrote: * C functions that scan for null are inefficient, so they're even more > likely to be replaced with Rust equivalents than other C functions. Hm, I think this is not a reasonable stance: $ find/usr/include/ -name \*.h \ | xargs cat \ | grep -c 'char\( *const\)\? *\*' 10488 There are a lot of C APIs that take strings. "Rewrite the world in rust" is going to take a long time. Also guessing that C code is slow because of NUL-termination searches needs evidence. Over my ~30 years of C/Unix I've heard this but I've never seen such evidence. Maybe I missed it! /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Strict style checking
Graydon wrote (private correspondence with roc and me in late 2009): "I'm sympathetic to the second point [roc argued for style enforcement especially to ease (semi-)automatic refactoring]. Go has gofmt and elective use of it before checkin. Refactoring is still too hard even with our impressive pork-based patch generation tools. As am I. I initially baked this sort of requirement into Rust but thought it would sound too pedantic so dropped it at first. Happy to revive. There are a few peculiarities of course: - Formatting trivial differences. 0xff should pretty-print back as 0xff not 15. Likewise 0x_ should not decay to 0x nor should "hel\u006c\u006co" decay to "hello". - Preservation or elision of comments. Comment <-> documentation relationship, and/or comment <-> unit test (cf. python doctests) I have no clear ideas here. At the moment Rust fe strips whitespace and comments but I'm not at all wedded to that. - Preservation of staged compilation. Rust's design has a (conservative) syntax-extension system, a bit like lisp readtables or camlp4 extensions, so these change the source text. Preserving text in a compiled artifact entails preserving multiple texts if some of them are staged output. The easiest approach I could come up with that would be practical would be (a) a gofmt-like formatting-enforcer mode on the frontend and (b) an option to simply embed a gzipped text-of-the-program in the binary output with the dwarf info pointing into it rather than into external files. Would be a small dwarf enhancement to teach gdb to use this. *shrug* or just use a symbol-server approach. -Graydon" Things have progressed since then but this still seemed fresh and I thought worth sharing -- hope it's ok to cite, wasn't really meant to be narrowcast back in the day (my fault probably). /be On Dec 9, 2011, at 8:25 AM, Niko Matsakis wrote: > We already have a pretty printer, maybe we should just make it a bit better > and run with it as the "official style"? > > On 12/9/11 7:44 AM, Dave Herman wrote: - *Compilers* that are obnoxious about dotting every i and crossing every t are a very different thing from *tools* that enforce style. Running a lint tool, or tying a lint tool to a build process, or to a check-in process -- those things all make perfect sense to me. But yelling at me for indentation when I'm trying to hack? >>> Do you really write code using arbitrary indentation and other style, >>> and then reformat it to the project style when you submit patches? >>> I've never noticed anyone doing that. On the contrary, I think I'd >>> crank code out faster if I didn't have to keep checking that I'm using >>> the correct style for the project I'm working in. >> It's just been my experience that over-strict compiler errors get in the way >> of the development process because I often need to try things out before >> they're finished. For example, back in the bootstrap compiler days, we had >> Ocaml configured to fail if there were any dead variables. This was >> incredibly frustrating and distracting. >> >> But one alternative we could consider, that would largely have the social >> effect you're looking for (enforcing a standard style and eliminating >> annoying style differences between projects) would be a tool like gofmt: >> >> http://golang.org/cmd/gofmt/ >> >> This is not part of the go compiler, but by shipping a tool with the >> language that enforces a particular style, it sends a clear message that >> this is the language's official style. And by making the tool useful, it >> provides a carrot to use that style. But it doesn't have the danger of >> interrupting the edit-compile-run workflow by nagging the user about >> syntactic nits. >> >> I believe they've also used it as a refactoring tool to help programmers >> migrate their code when the language changes, which is a useful trick, too. >> >> You could worry that some projects would still adopt their own style, but a) >> there are practical benefits to using the official language style, and b) we >> could still set cultural norms about using the official language style. In >> practice, I think there would be so much more uniformity of style that it >> would probably make non-conformists look silly and stubborn. >> >> Dave >> ___ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] criteria for core lib
Virtual methods all over Gecko (Raptor, originally) really hurt. QI, AddRef/Release (nonsensical for arena-allocated objects, but the COM disease was rampant), all the core rendering object methods were virtual. De-virtualization took years. KHTML (now WebKit) avoided this costly mistake. It's not the same as what's discussed here but I wanted to support the concern about indirect call overhead. It's not a premature optimization to consider at this juncture. /be On Dec 4, 2011, at 10:00 PM, Patrick Walton wrote: > On 12/04/2011 09:39 PM, Patrick Walton wrote: >> Strongly disagree. If we cannot inline stuff like map, we cannot create >> a performant browser engine. There is no way around this. > > I should elaborate: Short of just telling users they can't use the looping > abstractions in the standard library if they want performant loops, which > seems like a non-starter to me. I suspect that would just lead to systems > programmers writing loops by hand, using macros, using the C preprocessor, or > something like that. All of those options would result in relatively > unstructured workarounds that miss out on the benefits of the functional > abstractions we're offering. > > We already see high-profile projects like SQLite do so-called "unity builds" > where they concatenate everything into one enormous .c file. This is in spite > of the fact that C already has macros and static/inline functions. > > We could do measurements here with instrumenting rustc, but I'm not sure it > would be relevant. What would be more relevant would be something like > inserting two function calls (one direct, one indirect) around every pixel in > pixman's alpha blending routines and seeing what the performance of Firefox > becomes. But I think we already know what the results of this test would be. > > Sorry for wording this so strongly, but I feel that this is an important > issue. > > Patrick > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Naming convention for libraries
On Nov 1, 2011, at 8:52 AM, Patrick Walton wrote: > We recently renamed libstd.so to libruststd.so to avoid stomping on a libstd > that might exist in /usr/lib. Perhaps we should attack this in a more > holistic way: either (a) all Rust libraries should start with rust* or (b) > Rust libraries should install themselves into /usr/lib/rust. > > The latter seems to be more common among language runtimes, but I'm not sure > if there are going to be library path issues on some systems if we go down > that route. Let's find out. It seems much better to use the filesystem than mangle the filenames. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Renaming "tag" and "log_err"
This seems like it will pay off for many, and rarely or never bite back. Have to keep it small, of course. /be On Oct 29, 2011, at 10:11 AM, Marijn Haverbeke wrote: >> but I suppose it can't be helped unless we really want to >> have a std::pervasives module that's imported by default. > > I've been thinking that something like the Haskell standard prelude > (small, guaranteed to always be available) might be nice. It could > hold some stuff like the std::option datatype, a print-to-stdout > function, and a few other things that are really common in tiny > programs. > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Renaming "tag" and "log_err"
On Oct 28, 2011, at 3:25 PM, David Rajchenbach-Teller wrote: > As a newbie, I confirm that both "tag" and "log_err" are quite > confusing. > > I confirm that "print" will be much better. +1 > If you want something shorter than "variant", here are a few, well, > variants: > - "sum" > - "cases" > - "choice" > - "tags" (it's a plural) > - "tagged" > - "enum" (Java-style, not C++ style) > - "family" > - "alt" > - "either" Thanks, good suggestions (although alt is taken and either is binary). I like "sum" first, "enum" second. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Vectorization
On Oct 18, 2011, at 8:58 AM, Eric Holk wrote: > > On Oct 11, 2011, at 6:22 PM, Lindsey Kuper wrote: > >> Has there ever been any discussion of vectorization (i.e., taking >> advantage of LLVM's vector types) in Rust? Patrick said that he'd >> brought it up in passing before, but I don't think I've seen it come >> up on the mailing list yet. I'm thinking about trying it out for a >> class project. I'm at the "looked at the Wikipedia page some" level >> of knowledge about vectorization right now, so I have a lot to learn. >> Um…thoughts? > > Does LLVM have any support for doing autovectorization? I know it has vector > types, and presumably these correspond to SSE or AVX or whatever vector > instructions the CPU has. I'm not sure about CPU vector units, but there's the PTX abstract ISA that compiles to GPU, from NVIDIA. Look for PTX under http://llvm.org/devmtg/2009-10/ and see also https://github.com/jholewinski/llvm-ptx-samples > As far as how to exploit these in Rust, I think it'd make sense to have some > way of making their use explicit, but higher level than SSE intrinsics like > GCC has. Perhaps one way would be to overload operators like plus to work on > tuples of numeric types? Tuples of floats match up pretty well with the > vector registers in the CPU, I think. I guess this could also be extended to > vectors. Another option I'd consider would be making a data parallel library. > Even if rustc doesn't generate vectorized code, this library could be > implemented in native code using SSE intrinsics. This also might help pave > the way for GPU support in the future. Have you guys checked out Intel Lab's River Trail yet? http://github.com/RiverTrail/RiverTrail http://brendaneich.com/2011/09/capitoljs-rivertrail/ ParallelArray (immutable, n-dimensional typed array based library abstraction) for JS, with Narcissus-based compiler to OpenCL. A tech demonstrator for sure, we are now working on integration into IonMonkey. /be > > -Eric > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Parameter passing and native calls
Thanks, I was three unread messages from the end, just before the message where all params went to pass by ref. Bad on me for my reading backlog, still I think this needs more discussion before implementation though. /be On Sep 30, 2011, at 12:25 AM, Patrick Walton wrote: > On 9/29/11 4:22 PM, Brendan Eich wrote: >> Wait, what? Even a stack allocated int32 is passed by reference? That is >> wrong, it hurts performance as well as breaking ABI. >> >> When did this change, for what reason? > > See the thread starting at > https://mail.mozilla.org/pipermail/rust-dev/2011-September/000759.html. > > Patrick > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Parameter passing and native calls
Wait, what? Even a stack allocated int32 is passed by reference? That is wrong, it hurts performance as well as breaking ABI. When did this change, for what reason? /be On Sep 30, 2011, at 12:07 AM, Patrick Walton wrote: > Now that every parameter is passed by reference, our ABI is no longer > compatible with C. Passing a struct by value is not the same as passing it by > immutable alias in C. > > This is a severe problem, and my first instinct is to propose bringing back & > for it. We could bring the old meaning of & back just for native calls, but > that seems inconsistent. > > Patrick > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Java-style iterators
On Sep 28, 2011, at 5:53 PM, Patrick Walton wrote: > On 9/28/11 5:27 PM, Brendan Eich wrote: >> On principle I do not want us to go down this path, even if we change later. >> It adds risk that we won't change. It imposes a stateful model on iterators >> where has_next and next must be coherent, and you have to write two methos >> (not one as in Python or JS.next). And, Java. > > I'd be fine with a single-method solution too: iterators could just be a > closure that returns option::t, with none used to indicate the end of > iteration. Now you are talking. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Java-style iterators
On principle I do not want us to go down this path, even if we change later. It
adds risk that we won't change. It imposes a stateful model on iterators where
has_next and next must be coherent, and you have to write two methos (not one
as in Python or JS.next). And, Java.
/be
On Sep 28, 2011, at 3:27 PM, Patrick Walton wrote:
> It would be nice if we could figure out what to do about iterators for 0.1. I
> was thinking that we could make them Java-style iterators -- that is, objects
> with has_next() : bool and next() : T methods. |for each| would simply be
> syntactic sugar.
>
> This form:
>
> for each (x in iter()) {
> ...
> }
>
> Would desugar (in trans) into:
>
> let _i = iter();
> while (_i.has_next()) {
> let x = _i.next();
> ...
> }
>
> This has the following advantages:
>
> * Easy to implement.
> * Easy for LLVM to optimize. Simple SROA and inlining should make this as
> efficient as a for loop.
> * Simple performance model.
> * Familiar to programmers.
> * Allows us to support |break|, |cont|, and early |ret| easily.
> * Allows |break| and |ret| to be efficient. They simply throw away the
> iterator object. No special stack discipline necessary.
> * Makes upvars (outer variables referenced from the loop body) free in terms
> of performance.
> * Generator-like patterns can be achieved by making the iterator
> implementation use tasks internally.
> * Allows us to eliminate |put|.
>
> But it has these disadvantages:
>
> * Tasks can be more syntactically heavyweight than sequential-style iteration
> using |put|.
> * Data sharing between tasks is restrictive, which can make generator-like
> patterns awkward to use.
>
> Thoughts?
>
> Patrick
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Can we have our tuples back?
On Aug 11, 2011, at 7:20 PM, Patrick Walton wrote: > On 8/11/11 7:17 PM, Graydon Hoare wrote: >> I wonder if we can get away with just saying that a *let* declaration >> permits multiplicity, the same way it permits trailing optional >> typarams; if this is truly the important case that's biting. It's >> decidedly less work to support a declarator form: >> >> let x = 1, y = 2; >> >> than to add (even if re-adding) another tycon. > > Should log permit multiple values too? > > I don't see why adding the tycon back introduces so much complexity, to be > honest. Right, wasn't it just another case in several alts? We should take one for the team of users, who otherwise have to multiply their record declarations beyond necessity if tuples would do. I'm speaking from relative ignorance here, so please be gentle if my many/few summary judgment is wrong. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Can we have our tuples back?
On Aug 11, 2011, at 5:31 PM, Patrick Walton wrote:
> On 8/11/11 4:10 PM, Marijn Haverbeke wrote:
>> As for destructuring, records seem to work very well there. In most
>> cases, you'll use the field names for your variables, so you get
>> simply
>>
>> let {key, val} = someexpression();
>
> Also, what I'd like to do is this:
>
> let x, y = 1, 2;
JS1.8.x today:
let [x, y] = [1, 2];
Optimizes to avoid array construction.
Wish we didn't have [] all over, but I foolishly cloned C/C++/Java's comma
operator.
/be
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Half-indent for case blocks looks terrible
On Aug 8, 2011, at 2:33 PM, Graydon Hoare wrote: > On 11-08-01 06:16 AM, Marijn Haverbeke wrote: >> One way out would be to use 2-space indents everywhere. I've always >> preferred this anyway. What are the reasons for using 4-space >> indenting? > > More visually distinct, serves as a disincentive to over-nesting rather than > factoring code into separate functions. Default stance for most non-GNU unix > people (I think?) Not sure -- varies. Some still use Unix tabs and map tabs to 4-space stops. (GNU bracing style is pure evil, btw. Nuff said.) > Discussing whitespace, mmm. A victory condition! /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Eliminate "let" hoisting
On Jul 31, 2011, at 9:23 AM, Patrick Walton wrote:
> Rust always hoists function items (named functions), even nested ones. I
> think that's a great feature for the reasons you describe -- it gets rid of
> having to think about the function dependency DAG, which is a big pain in C
> and C++, and even worse in Standard ML and OCaml, where there aren't even
> prototypes. Hoisting for named functions is fine because they're always
> completely defined before execution begins -- in particular, they can't close
> over any values, so there's no question as to which bindings they capture
> (uncertainty over this is why I assume ML functions don't hoist).
Right (and sorry for forgetting Rust's hoisting of named fns).
> So I should have been more clear -- in this scheme local variables would be
> the only non-hoisted bindings. It's rare that local variables need to be
> mutually recursive; the only time is when you want mutually recursive
> capturing lambdas, and in that case I don't think manually hoisting is too
> bad.
That was exactly our conclusion for JS when we were entertaining the C++-based
scope rule. You can't make:
{
let a = b;
let b = a;
...
}
work in either the temporal-dead-zone let-hoisting regime, or in the C++-like
regime. But the interesting case is of course not this nonsense-case, it is
something more like this:
{
let a = function(){return b};
let b = function(){return a};
...
}
and here, hoisting with temporal dead zone wins since the above "just works" --
you do not have to refactor to:
{
let a, b;
a = function(){return b};
b = function(){return a};
...
}
as you would with the C++-based rule.
> Absent mutual recursion, I don't see any benefit to hoisting local variables,
> other than (a) consistency between items and locals and (b) simplifying the
> compiler implementation a bit (but note that we actually get this wrong at
> the moment -- we initialize local variables at the time we see the "let",
> which can cause segfaults).
The crucial requirement is that Rust doesn't allow local variables to be
captured by hoisted (i.e., named) fns -- right?
/be
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Eliminate "let" hoisting
On Jul 30, 2011, at 1:58 PM, Patrick Walton wrote:
> Currently, in Rust variables hoist, just as in JavaScript. I would like to
> propose removing this feature, and having each "let" introduce a new scope.
This matches C++, so that's a plus for anyone coming to Rust from the main
Mozilla "systems" language.
> Other, weaker but still compelling arguments in my mind:
>
> This code compiles but is awfully confusing:
>
> fn main() {
> x = 3;
> log_err x;
> let int x;
> }
FYI, and not bearing on Rust at all IMHO (so feel free to skip), we on Ecma
TC39 just renewed our agreement, with better joint understanding of the
rationale, for let and const (and function-in-braced-block) hoisting to start
of block *and* for use before initialization (the "temporal dead zone") to be
an error in JS.next (ES6).
JS already has function hoisting, which wins for programming in top-down style,
maintaining source without having to topologically sort functions, etc. I made
functions hoist to top of program or outer function body to mimic letrec, way
back in the day. Given this precedent, we believe
function-declaration-in-block, which binds a block-local (as let does), should
hoist to top of block and be initialized on entry to block.
Last fall, we tried to make let (and const) open C++-style implicit scope at
declaration site, till end of explicit block. But this does not work with
function hoisting:
const k = 0;
function outer(x, y) {
if (x) {
inner();
const k = y;
function inner() { print(k); }
inner();
}
}
outer(42);
The first inner() call cannot see k under the let* or C++-based scope rule. If
this inner call should print 0 then function inner has dynamic scope. If it
should throw an error then the scope rule is equivalent to hoisting k to top of
its containing block. Likewise for let.
The reason the dead zone in which use of k before it has been initialized is a
temporal or dynamic zone, not a lexical or static zone, is shown above: inner's
declaration is dominated by k's definition, so a lexical dead zone would allow
it. But then for this approach to differ from temporal dead zone, the first
call to inner either must get undefined from k (two values for one const), or
get the outer k (dynamic scope).
Hence hoisting for all binding forms, with a read and write barrier for use
before set (write barrier for let; const must be initialized in its declaration
and it's a static error to assign anywhere else). The barriers are potentially
significant performance penalties for upvars (any directly-in-block, not
in-nested-function, use cases are probably bugs; we're still arguing about
whether to make those static errors). We shall see.
If Rust hoists nothing, in particular Rust does not hoist nested fns, then it
does not face the same predicament.
/be
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Half-indent for case blocks looks terrible
On Jul 22, 2011, at 6:46 AM, Marijn Haverbeke wrote:
> Having some braces four spaces apart and others only two makes for a
> very jarring visual effect. We could probably get used to it, but if
> somebody has a better idea, I think we should consider it.
I'm probably to blame for this style meme (although I got it from Kipp Hickman,
my old SGI / Netscape colleague), I do it i in C code for labels (goto and
switch-case). But C does not require braces around case statements, of course,
so you don't get the half-indented closing braces, as in:
switch (foo) {
case BAR1: {
...
}
case BAR2: {
... // don't forget to break!
}
default: {
...
}
}
which I agree are a bit disconcerting and unaesthetic.
The motivation is that labels are not statements. They should not indent four
spaces, and then their labeled statements indent four more. That tends to
over-indent too much, and the labels have no control flow nesting property that
needs any more indentation than their labeled statements.
K&R and old Unix ken&dmr style simply does not indent labels, so one can always
fall back on that.
A lot of Mozilla code, C++ and JS, uses two-space c-basic-offset and does
indent case labels a full two spaces, then two more for the labeled statements
(I don't think goto labels get the same treatment, but this is C++ code so
gotos are less common; JS break/continue-to-label is also rare).
Two-space c-basic-offset works a bit better with multiline if conditions:
if (very_long_conjunct_goes_here() &&
another_whopper_here()) {
consequent_at_distinct_indentation_level();
...
}
With four-space indentation units, the condition's overflow line and the
consequent block kids start at the same indentation, and are that much harder
to distinguish at a glance. This has led to a SpiderMonkey style variation
where the { in such a situation moves to its own line, in the same column as
the }.
Style, yay.
/be___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Unique pointer syntax
On Jun 10, 2011, at 2:29 PM, Rafael Avila de Espindola wrote: > On 11-06-10 02:23 AM, Graydon Hoare wrote: >> >> Personally I think I'd go with ~ and just merge boolean and bitwise ! > > I like that! As a HAKMEM print-out owner and long time C bit-twiddler I will be sad, but I'll get over it. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: nominal records
On Jun 6, 2011, at 10:08 AM, Rob Arnold wrote: > IMHO, you only get a benefit in not having to name the type if the record > type appears exactly once. Otherwise you're scattering the record type > definition throughout the code, making it harder to e.g. add new fields if > you need to. This is why, in practice, every record in the standard library > and rustc has a typedef. > > If you get type-inferred lambdas then does this case become more common? Would hate for us to paint into a nominal-only corner short-term, then evolve longer-term in ways that reduced the pressure for nominal-only records. > If you want the self-documenting aspect of records, then, well, use records > :) In fact, having to give each record a name arguably improves their > self-documenting nature. > > I want to avoid the case of coming up with awkward names for these types > which are local to a particular module or function. This is one pain point. The other is the flip side of "scattering the record type definition throughout the code": having to depend on the one true name. If someone does "add new fields" then in large codebases, depending on how the record is used, structural types do not require all clients to be updated. (At least not in structurally typed systems I've seen -- sorry if I'm missing something deep that restricts Rust's structural types in the long term.) That's the beauty of structural types -- programming in the large without as much brittle nominal version locking. I'm told the CLR went structural after an early and way too brittle nominal assembly typing scheme. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Syntax changes
On May 19, 2011, at 8:28 AM, Graydon Hoare wrote: > On 18/05/2011 6:46 PM, Sebastian Sylvan wrote: > >> In fact, in that case all you'd need to change, as far as I can tell, >> is the vector type constructor syntax to be "[T]" instead of T[] which >> would avoid any ambiguous associativity issues (that last example >> would then be "mutable @ [ @ mutable int ]"). > > Yeah. I'm sympathetic to this and have discussed exactly this point a fair > bit already; the problem is that we'd like to reserve room in the syntax for > a type of vecs that have a specific interior allocation reserved for them > rather than pointing to the heap. I.e. int[10] or such. > > This could still be done by [int](10) or [10]int or even [10 int] it's just a > matter of ... alienness of convention? Presumably if the natives are C/C++ hackers, int[10] would be non-alien. But type in the middle or on the right would be more consistent, ceteris paribus. I think [10 int] reads well. Can the constant expression sub-grammar compose this way? /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Syntax changes
On May 18, 2011, at 10:30 AM, Marijn Haverbeke wrote: > (I have no strong opinion about types before names. But I do want to > point out that...) > >> I'm not sure how destructuring with TI affects this, so that could be >> exactly what I'm missing. Thanks for any info. > > Having name:type syntax would allow type annotations in destructuring > patterns. The current syntax makes that very hard to do. Same for > optional type annotations in inner functions, and destructuring in > function arguments. I *think* that this use of the ':' character is > compatible with our intention of using it for labels and record > fields. (ML, I expect, did think this through further than C did.) Ok, this makes sense. Some foolish consistency when it comes to syntax can help (greater uniformity for people learning the language, learning inductively/constructively, developing intuition). ML seems less consistent in this light. : T as optional annotation after name seems more consistent. But consistency is overrated ;-). /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Syntax changes
On May 18, 2011, at 10:11 AM, Marijn Haverbeke wrote:
>> Depends on the exact syntax you want, I suppose, but this could be
>> done with at most single token lookahead right? Simplest option (no
>> lookahead needed):
>
> We'll probably keep the type, which can be arbitrarily complex, in
> front of the variable name. We also plan, at least in the
> type-deducing variant, to allow destructuring, making the two even
> more dissimilar.
I like type in front from C and C++, but it has caused huge mischief in the
lexers and parsers for those languages. Is it worth it?
People in this thread mentioned {x: uint, y: uint} vs. {uint x, uint y}, and it
does seem worth getting types-in-front in all contexts.
But the type-after-colon approach is strictly simpler to parse and make
optional. Can someone say why types-in-front wins? It's ok if it is an
aesthetic judgment by BDFL or cohort, I am mainly asking if I'm missing a
deeper reason.
I'm not sure how destructuring with TI affects this, so that could be exactly
what I'm missing. Thanks for any info.
/be
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] stage1/rustc builds
Congrats and huzzahs! /be On Apr 20, 2011, at 7:34 AM, Graydon Hoare wrote: > On 20/04/2011 6:19 AM, Rafael Ávila de Espíndola wrote: >> On 11-04-20 3:02 AM, Graydon Hoare wrote: >>> After that last change fixing the logging scope context bug, looks like >>> stage1/rustc builds. Just shy of midnight :) >>> >>> Takes almost an hour on my buildhost, and generates a 17mb bitcode file, >>> so obviously we need to do some tuning. >> >> Awesome! Is the 17MB with optimizations enabled? > > I honestly don't remember. The makefile rules are off as well, I had to > manually run a few steps. I'll tidy this mess up some more today. > > -Graydon > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Integer overflow checking
On Apr 16, 2011, at 8:22 AM, Patrick Walton wrote: > On 04/15/2011 11:20 PM, Patrick Walton wrote: >> This area seems promising enough that I was wondering if there was >> interest in something like this for Rust. There's no harm in having the >> programmer explicitly be able to turn off the checking at the block or >> item level; some algorithms, such as hashing algorithms, rely on the >> overflow semantics, after all. But it seems in the spirit of Rust (at >> the risk of relying on a nebulous term) to be as safe as possible by >> default, and so I'd like to propose exploring opt-out overflow checking >> for integers at some point in the future. > > To be clear: I'm not proposing that we promote to bignums or anything like > that. Most likely we'd just fail on integer overflow by default. Yes, we've talked about this in the past with roc -- failure would be better than wrapping around. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Fwd: [GitHub] (remaining bits of floating-point stuff) [graydon/rust GH-282]
Style police raid!
In the patch readable at the pull request linked below, you can see existing
code cuddling braces on both sides of else:
} else {
and (in numerous + lines)
}
else {
I'm in favor of any style guide covering this case. The JS C++ style guide
does. Anyone care?
/be
Begin forwarded message:
> From: catamorphism
>
> Date: March 22, 2011 3:43:50 PM PDT
> To: bren...@mozilla.org
> Subject: [GitHub] (remaining bits of floating-point stuff) [graydon/rust
> GH-282]
>
>
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/graydon/rust/pull/282
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fork in a Rust process
On Mar 14, 2011, at 5:21 AM, Marijn Haverbeke wrote: > That being said, I have no intention of dragging functors, monoids, or > other category-theory mumbo-jumbo into Rust. When possible, I agree we > should stick to widely-known terminology. 'Interfaces' would have been > just as good a word as 'typeclasses'. But they have been invented and > popularized as 'typeclasses', so that's probably the best word to use > for them now. C+0x tried "concepts", ended up deferring them. Seemed like typeclasses in all but name -- anyone know more? /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]
On Mar 12, 2011, at 10:42 PM, Graydon Hoare wrote: > On 12/03/2011 8:46 AM, Evan Martin wrote: > >> It seems from the bug Brendan linked to (I skimmed, I admit) they >> wanted to be able to catch memory allocation failures; it's not clear >> to me whether that's a desirable goal in Rust. (It's not clear to me >> if you're out of memory whether you can write any useful >> non-allocating Rust code to handle the error condition.) > > Not at all naive. I'd like to be able to unwind from an out-of-memory > situation though. Mozilla C++ has the same constraint, which makes precise the problem with STL's containers, e.g., lacking failed-due-to-OOM return codes. While we decorate as fallible allocation sites whose size is variable and failure-prone due to web mistakes and attacks (e.g. image height and width), and null-check, we're not yet ready to let the main process (!) fail hard if a smaller allocation walks off a cliff. And at least on Windows, it seems, it's easy to run out of VM in some cases, even in spite of overcommit being the default OS policy. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]
On Mar 11, 2011, at 2:09 PM, Marijn Haverbeke wrote: >> The restraint part is that we have no story for handling or propagating C++ >> exceptions into rust failures yet. We could do it with try/catch blocks on >> all upcalls and native calls, possibly, but it'd take some care and a degree >> of certainty that it's the right approach that I don't yet have. So there >> are no exceptions used in librustrt for now. > > I actually think this is a sane decision. It'll require a peculiar > style of C++ programming, but is probably still less burdensome than > properly dealing with exceptions (which, on cross-language boundaries, > tends to be extremely painful). Agreed. For Mozillans this will be the same C++ subset we use (templates, RAII, all the best parts save exceptions). Graydon, thanks for clarifying. You know me, I would have been pretty happy sticking with plain C :-P. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Fwd: [GitHub] Add basic file-system functionality [graydon/rust 2330c96]
Marijn asked why we are not using STL in the runtime C++. It's a good question. In Mozilla C++, we have avoided STL because we cannot take the code size and runtime costs of exceptions on all platforms. https://bugzilla.mozilla.org/show_bug.cgi?id=200505 is worth a read if you are so inclined. Once we gave up on STL for want of failure propagation via return value, we went in different directions on other, particular design points (raw buffer access, single-allocation hashtable [double hashing with entries as interior allocations]). The high cost of exceptions with MSVC looks like it will endure, alas. Even with zero-cost exceptions in GCC, the RTTI hit was costly last time we checked (a while ago). I hope this helps. I'm curious to hear from people who see a better way to go cross-platform with Rust's C++. It is 2011, after all! /be Begin forwarded message: > From: marijnh > > Date: March 10, 2011 9:31:39 PM PST > To: bren...@mozilla.org > Subject: Re: [GitHub] Add basic file-system functionality [graydon/rust > 2330c96] > > Yeah, that's a TODO. Is there a reason you're not using the STL anywhere in > the runtime code? > > https://github.com/graydon/rust/commit/2330c96e4550d371d71822d4aa0baadba95a1253#commitcomment-298321 ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Immutable shared boxes and destructors
On Dec 18, 2010, at 9:41 AM, Sebastian Sylvan wrote: > http://www.hpl.hp.com/personal/Pramod_Joisha/ Thanks, we noticed these -- a Mozilla Research guest speaker, Stefan Brunthaler of the Technical University of Vienna, pointed Joisha's work out to some of us a couple of months ago. FWIW there are patent clouds visible at the URL I cut above. The unique_ptr idea seems worth exploring in any event. /be ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
