This blog post showed up on HN:
http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/
The author's Rust implementation is here, and s/he invites pull requests if you
can improve it:
On Oct 4, 2012, at 3:25 PM, Brian Anderson bander...@mozilla.com wrote:
As a side note, we should do more with the Twitter account so it doesn't
appear that we are dead.
If I can get the credentials to the account I'll be happy to share the
responsibility for tweeting updates.
Dave
Hi Ben,
Thanks for all your awesome work. This is really exciting stuff, and I also
appreciate your write-ups on your blog.
Dave
On Sep 28, 2012, at 5:22 PM, Ben Blum bb...@andrew.cmu.edu wrote:
Hi folks,
Many of you know this by now, but I'm sure there are people here who
didn't sit in
, at 6:32 AM, Niko Matsakis wrote:
On 7/18/12 9:48 PM, David Herman wrote:
That would result in a very different performance model, since Rust expects
to be able to create several metric craptons [1] of concurrent tasks,
whereas the number of workers you can create is much smaller. But who knows
On Feb 4, 2012, at 1:17 PM, Patrick Walton wrote:
On 02/04/2012 06:21 AM, Arne Döring wrote:
The second suggestion is concerning tho #fmt macro. #fmt works like
printf, but its string is parsed at compile time, so that errors might
be thrown when the string is incorrect. So when you unwind
On Nov 29, 2011, at 3:11 PM, Graydon Hoare wrote:
On 11-11-29 12:00 PM, Niko Matsakis wrote:
I like that this allows the user to customize how types can be copied,
logged, and sent.
I don't. It's in conflict with predictability and the guarantees the language
is trying to make for its
On Nov 29, 2011, at 3:51 PM, Graydon Hoare wrote:
On 11-11-29 03:43 PM, David Herman wrote:
On Nov 29, 2011, at 3:11 PM, Graydon Hoare wrote:
On 11-11-29 12:00 PM, Niko Matsakis wrote:
I like that this allows the user to customize how types can be copied,
logged, and sent.
I don't
I think we're beginning to converge; in many ways there's not a ton of
difference between the categories proposal and typeclasses.
What would you do with multiple instance declarations that differ by
specificity? For example, one declared on [int] and one declared on [T].
Eventually, we'll
On Nov 28, 2011, at 12:38 AM, Marijn Haverbeke wrote:
I prefer them because they enforce a much more structured way of
thinking. Declaring grab-bags of methods and assembling them into
interfaces ad-hoc seems clumsy and, as you mention, error prone ---
just because a method has a given name,
I'm very concerned about these changes. Let's talk about this on Tuesday.
Dave
On Nov 18, 2011, at 10:55 AM, Marijn Haverbeke wrote:
I pushed the new kind system today. Things to be aware of are:
- We now have proper copyability analysis, and resources can be used
in saner ways.
- The
Just a couple detail responses:
- Overall: technically strong proposal, but I'm lukewarm about doing it,
and definitely don't want to *now*. In order, I'd prefer to finish
what we've got scoped for the next while, then explore Niko's
sketch, then get to this if we find it necessary.
I
I understand that tail calls aren't working with the current state of things,
and I won't get in the way. Fair warning: I am not promising I won't argue for
bringing them back at some point in the future.
- The alias-optimizing issues discussed earlier in this thread
I've been chatting with
My opinion is that we should bring back tuples but that the standard way to
access the elements should be destructuring let.
This seems reasonable to me, except you'd want to allow destructuring tuples
anywhere patterns are allowed (e.g., function parameters, alt, etc).
Standard ML does #1
I believe eliminating tuples was a mistake. Just look at what happens to the
zip function:
fn zipT,U([T] a1, [U] a2) - [{ fst: T, snd: U }]
or with a typedef for pairs:
fn zipT,U([T] a1, [U] a2) - [PairT, U]
Another use case: debugging with polymorphic log:
log (x, y, z);
is way
I'll try to stick up for tail calls, at least down the road (I'd say having
them in the first release doesn't really matter).
A few points:
- As you guys have said, this issue seems pretty tied in with the memory
management semantics, particularly with refcounting. But I'm still not
convinced
Patrick Walton wrote:
(2) All named functions have type @fn. They are reference counted. They
can close over outer variables, but only those on the heap (i.e. only over
boxes).
Note that there are a few ways this could be achieved.
a) C++0x-style capture clauses:
{
let x = @99;
So you did -- sorry I missed that.
Dave
On Jun 10, 2011, at 9:58 AM, Graydon Hoare wrote:
On 11-06-10 09:12 AM, David Herman wrote:
Since unlike C/C++ we have a distinct bool type, would it be possible to
overload ! so that on numeric types it means bitwise not? This would free up
Indeed. This was always going to be one of the trickiest part of the design. In
this latest iteration, we've only been attacking it for a couple of days. We
can't expect a solution to just pop out that easily; we will have to bang our
heads against it for a while. And we've already seen a
How do you get from lack of compositionality to forfeit all other
features?
Lack of polymorphism, not composition.
I'm sorry, I'm just still confused about why you claim we have no polymorphism.
I mean, we simply do have polymorphism. I think I understand why you are saying
that
Yes it does. But it is still incomplete and a hack: look at all that
complexity to do what is
simple in ML. Rather it isn't simple .. its non-existent. There's no
machinery required
to make it work.
That doesn't really bother me. ML has a different set of trade-offs. It's a
given that we
FWIW, I have plenty of friends in the PL research world who design type systems
that are not based on your restrictive definitions (type system = initial
algebra, type system design = category theory). But I have no interest in a
theoretical shouting match. We'd probably lose -- no one on our
I don't have any concrete solutions to offer, just a few scattered thoughts:
- In our recent discussions at the all-hands, we were leaning towards
eliminating the ability to send higher-order data over channels. This would be
in tension with the desire to migrate tasks.
- Migrating tasks could
, inside the unchecked part you could assign the wrong type to a
variable or data structure.) But we could avoid certain checks (like comparing
the result type of the two arms of an if). Not that I'm advocating option #4. :)
Dave
On Nov 23, 2010, at 2:53 PM, David Herman wrote:
Of these, I like
FWIW, I'm with Patrick-- this all sounds too complicated to me. At least until
we've written some significant code, it doesn't seem worth trying to solve a
problem we may not actually have. And Patrick's suggestion of scoped literals
at least sounds like a reasonably simple approach (that
Graydon and Patrick recently brought up our disjoint-union types which were
originally structural, and Graydon has recently redone them to be nominal. I
wanted to understand the ramifications better, so I spent a little time last
week digging into the design space of nominal and structural
25 matches
Mail list logo
