te stack instead of mutating? Or perhaps just make
changes to the stack itself work differently - while you're looping through
them any calls to modify the stack gets put on a side-queue, and then after
you've finished looping you apply them all. You're not running arbitrary
code at this point, just adding stuff to the stack.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
efficient stream processing (stream
fusion) relies on it.
[1]
http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
objects):
http://msdn.microsoft.com/en-us/library/vstudio/system.dynamic.dynamicobject.aspx
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Sat, Aug 24, 2013 at 9:50 PM, Lindsey Kuper wrote:
> On Fri, Aug 23, 2013 at 8:30 PM, Sebastian Sylvan
> wrote:
> > I'm sure you've all seen it, but C# has something similar but a lot more
> > powerful. Basically, it has support for allowing runtime resolutio
to produce them.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
/most string literals are used for in
conjunction with various formatting functions anyway, so I wouldn't think
it would be a big deal in practice. Throwing in a call to fmt isn't a big
burden, imo.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Mon, Oct 28, 2013 at 10:23 PM, Corey Richardson wrote:
> I've written up more thoughts on stack safety at
> http://cmr.github.io/blog/2013/10/28/more-on-stack-safety/. If no one
> objects to it (meeting tomorrow!) or has any better ideas, I'll start
> implementing it.
>
Consider this: *if* yo
other tasks (the
language RT would probably spawn up more OS threads if that happens, I'd
imagine, which gets you back into the same area of eating up virtual
address space by having more OS threads than HW threads, each of which has
a dedicated "large stack" to run non-blocking tas
On Mon, Jan 27, 2014 at 9:33 AM, Matthieu Monrocq <
matthieu.monr...@gmail.com> wrote:
>
>
>
> On Mon, Jan 27, 2014 at 3:39 AM, Brian Anderson wrote:
>
>>
>> Consensus is that the `do` keyword is no longer pulling its weight.
>> Remove all uses of it, then remove support from the compiler. This is
ome (perhaps even the majority?) of the cases
where "real" lambdas are needed could still be satisfied, without having to
worry about most of the issues listed in the FAQ since the lambda can't
survive the function call it's passed to.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Mon, Aug 30, 2010 at 7:06 PM, Graydon Hoare wrote:
> On 10-08-28 02:33 PM, Sebastian Sylvan wrote:
>
> Let me first say that the only reason I write this is because I really
>> like
>> Rust. It seems to get a lot of things really right, and I'd like it to
>> b
to run at the end of the scope. Having to introduce a new class,
and a new variable for that is a bit burdensome IMO.
I realise I'm arguing for a brand new feature here though, which is
obviously a cardinal sin :-)
I'm not entirely sold on the scope feature in D, btw, but I can see its
usefulness in that it alleviates some of the burden associated with
scope-based resource management that you get with RAII.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
x27;re bike-shedding, I'm not sure why the "auto" keyword is needed at
all. Type inference is never dangerous (i.e. affects performance/semantics)
right? So why not just make the type specifier in the "let" statement
optional?
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
*can* tell whether an interface
depends on mutable data? This is the distinction that e.g. D makes between
immutable and const (immutable means the data can't be changed, const means
that *you* won't change it - the latter is needed to make sure you can write
one function that can be used
uldn't impact
semantics.
As far as I can tell, this would seem to avoid subtle problems due to
missing a semi-colon and trivial mistakes like that, while also matching
intuition about what should be legal. The downside is that the type-checking
becomes a bit
On Fri, Nov 26, 2010 at 12:22 AM, Graydon Hoare wrote:
> On 10-11-25 02:47 PM, Sebastian Sylvan wrote:
>
>> On Thu, Nov 25, 2010 at 6:54 PM, Graydon Hoare
>> wrote:
>>
>> On 10-11-25 08:50 AM, Igor Bukanov wrote:
>>>
>>>> My preference i
you're just not
incurring the cost for everything. I'd prefer if this wasn't necessary (i.e.
if refcount operations could be statically or dynamically elided often
enough that any immutable data can be sent over a channel), but you could
always make the "shared" keyword a no-op in the future if that materializes.
Happy holidays!
Sebastian
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Sat, Dec 18, 2010 at 5:32 PM, Patrick Walton wrote:
> On 12/18/2010 09:03 AM, Sebastian Sylvan wrote:
>
>> 3) The cost of reference counting in a multi-core scenario is a concern.
>> Rust already limits the number of reference operations using aliases,
>> which presuma
On Sat, Dec 18, 2010 at 5:41 PM, Sebastian Sylvan <
sebastian.syl...@gmail.com> wrote:
>
>
> On Sat, Dec 18, 2010 at 5:32 PM, Patrick Walton wrote:
>
>> On 12/18/2010 09:03 AM, Sebastian Sylvan wrote:
>>
>>> 3) The cost of reference counting in a multi-core
t least doesn't require global
synchronisation for many cases (only twice for objects with less than 4
local ref counts), you'd probably still want to only do this for shared
objects, though.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
lgorithms inside-out to create a series of
"flat" data parallel passes, rather than have the compiler do that work for
you. It took me something like two days to get a correct version of a simple
odd-even merge sort a few years ago (before there were code samples around
for it!). This is a really, really, difficult.
I realise this is highly "researchy"/"unproven" at the moment, but it might
be worth keeping it in mind so you don't make any design decisions that
would rule it out in the future.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
all to runST creates
a new, local, heap that you can mutate to your heart's content because
nobody else can see it, and none of those effects can leak (other than
through the return value) which is enforced by some cleverness with rank-2
types.
I think that if Haskell allows it, it's un
On Mon, Feb 28, 2011 at 7:09 PM, Florian Weimer wrote:
> * Sebastian Sylvan:
>
> > I think that if Haskell allows it, it's unlikely to be an issue even for
> > purists. :-)
>
> Haskell has potential side effects at every pattern match, so it can
> hardly be used
t to put in
the main module because it's really an optional extra.
Sebastian
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
t; Anyone know?
>
I would guess that the old (since eliminated) dispatcher lock would hurt you
badly if you try to actually communicate with two many threads. Should be a
lot better in Windows 7 though.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Tue, May 17, 2011 at 12:42 PM, Graydon Hoare wrote:
> > - 'auto' will probably turn to 'let' and 'let' to something else
> ('var' or such)
Why the need for two keywords? Couldn't the inferr
second token
was (if the third is not "" or "=", then the second token must've been
the type).
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
would conjecture that you're
scanning for a name more often than for a type, so putting it first
makes sense.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
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 ]").
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
antial impact on the way people write code
(not much functional stuff was being written in C# 2.0, or indeed
Java, despite it being technically possible - the slight added
convenience of lambda statements and expressions punches way above its
weight here).
--
Sebastian Sylvan
_
king much of a sweat.
So, my current "gut instinct" (in the absence of data) is to favour
light weight tasks that map to (few) OS tasks, for performance
reasons. You seem to oppose that on performance grounds. I'm not sure
why our intuitions
On Thu, Jun 9, 2011 at 11:23 PM, Graydon Hoare wrote:
> (Also ^ for pointers reminds people of Pascal, which we all know is To Be
> Avoided At All Costs :)
Worse than Pascal, it's also used in C++/CLI!
--
Sebastian Sylvan
___
Rust-dev m
tra complexity. It doesn't
>> really have the elegance of classical tail calls.
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
--
Sebastian Sylvan
___
tagged"
> - "enum" (Java-style, not C++ style)
> - "family"
> - "alt"
> - "either"
>
How about "union"? C/C++ programmers will instantly get the gist of
it, while probably suspecting that it'll be a safer version of the
u
perator overloading. I
mean, look at this:
add(scale(n, dot(view_vec, n)*2f), view_vec)
6. I seriously couldn't figure out how to use the pow function. No
amount of importing/using seemed to bring it into scope. :-/
Overall, I found Rust to be quite enjoyable to wor
r modules so that you're
forced to call the functions in the module to operate on it? Would be
nice to have a shorthand for just exporting all the members though, a
la Haskell.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
. The fact that the
literal->bits translation may not be injective doesn't mean that any
two values that happen to have the same bit representation should be
considered the same for the purposes of inferring type.
With that in place, I don't think that leaving off suffixes would be
an
s" like this covers
the majority of the benefit of dependent types without the complexity
of a general system.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Saw this over at LtU and thought this might interest a few people
here: http://code.google.com/p/decac/
And here's a paper describing it in more detail:
http://decac.googlecode.com/files/Deca%20Thesis.pdf
--
Sebastian Sylvan
___
Rust-dev mailing
calls in to the
system (or manually calls yield), the system switches to your
scheduler instead of blocking the OS thread.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
he need
for the /X part of the literal syntax at least.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Here's a note by Jonathan Shapiro saying that BitC is no longer going
to work: http://www.coyotos.org/pipermail/bitc-dev/2012-March/003300.html
It had many of the same goals as Rust, so it may be interesting to
this mailing list to learn from BitC.
--
Sebastian S
Hi,
What do you guys use to profile rust programs? Just manual timers in
the code, or do you have any tools to recommend?
I saw that brson had updated my old Rust ray tracer to Rust 0.2 so I
downloaded his version and started piling on new features. And while
it's already many times faster than it
to just
cache the hash value with the element. You usually do this anyway
because calling the hash function is sometimes expensive so you want a
cheap "early out" when checking equality (especially for things like
strings).
Anyway, I like this quite a bit better than hopscotch hash
sockaddr4_in();
What about when the initial values need to be, say, 1 rather than 0,
or "Unknown Name" instead of "", or NaN instead of 0.0f, etc.? Granted
the latter may be slightly more common, but it seems like a hack to
treat it specially just the same, in order to save a
you'd
just keep tail-calling from state to state. Without really knowing
exactly what kind of code you're trying to generate, this seems like
it might be workable.
Seb
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
guage that emphasizes immutable data structures I'd
imagine the opportunity to use these fixed arrays "in-place" would be
extremely frequent.
Seb
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
China, June 15-16, 2012.
http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2012.pdf
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ch one better suits her needs. Of course coherency at the
> executable level might be necessary.
>
> -- Matthieu
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ambda to a
function without using "do" or "for", and if so what does it look
like?
I'm guessing something like this, but I didn't see it spelled out:
foo( |x| {
let y = x+1;
y+1
});
Seb
--
Sebastian Sylvan
___
Rust-dev m
On Mon, Jul 2, 2012 at 11:26 AM, Lindsey Kuper wrote:
> A couple of weeks ago, Rust gained suffix inference for integer literals.
This makes me unreasonably happy. Funny how little things cause
annoyance well past their actual impact.
--
Sebastian Syl
s is
the answer - the Hash module can define instances for pre-existing
types using functions that are passed in by the importer of the module
(the same module imported twice but parameterized differently would be
treated as two independent modules)?
--
Sebastian Sylvan
_
to run those
methods.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
lock
the underlying worker thread - which falls back to the OS scheduling
an overprovisioned set of worker threads onto the actual CPU threads).
See e.g. this page for some example code (though it also shows some
parallel for_each and stuff like that):
http://ms
te. I couldn't get rid of the ampersand because it would fail
to compile with a "deprecated vec expr" error.
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ink this will gain much traction, but
it's one of those small niggles that I would do differently if I was
designing the language, so I thought I'd float it for consideration.
Thanks for your time!
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
whatever) is enough, but if you can make allocations stick out even
more while simultaneously simplifying the syntax then it may add up to
being a good idea.
Seb
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
u don't expect people to remember it by heart, avoid short mnemonics
in favour of descriptive names. If it's unsafe and should stick out
like a sore thumb, avoid short names. For library stuff that's
essentially just shy of being a built-in
things.
Rust doesn't have null pointer crashes. In fact, I'm kinda ambivalent
about calling a language where any reference may blow up "memory
safe". IME the vast majority of runtime crashes in Java/C# are null
pointer exceptions, so eliminating
located in the dynamic link library
D:\Programming\rust\helloworld.exe.
---
OK
-------
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ibility, but syntactically it doesn't look like
an indivisible "object" that have a small set hard-wired built in
methods on it as opposed to a value and a random grab bag of
operations that happen to have matching types but could be written by
any old schmuck and not necessarily &qu
On Wed, Oct 10, 2012 at 3:49 PM, Eddy Cizeron wrote:
> 2012/10/9 Sebastian Sylvan
>> I think there are two other benefits. The first is intellisense/code
>> completion. Type "foo." and get a list of all methods in scope with a
>> matching self type. This can be a m
p here (safely) seems like the right
call.
Seb
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
ang.org/dist/rust-0.5-install.exe
>
> If windows folks want to give that a spin, much appreciated.
>
> -Graydon
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
--
Sebastian S
but ada doesn't
>> really seem to be in the running for a wide spread next language outside
>> of certain niches.
>>
>
> Agreed.
>
> -Graydon
>
>
> __**_
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
--
Sebastian Sylvan
___
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
>
--
Sebastian Sylvan
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers wrote:
> Scala has a similar design, with the following traits:
> - TraversableOnce: can be internally iterated once (has a foreach() method
> that takes a closure)
> - Traversable: can be internally iterated unlimited times (has a foreach()
> method tha
y wrote:
> On Thu, Jun 6, 2013 at 11:01 PM, Sebastian Sylvan
> wrote:
> >
> >
> > On Thu, Jun 6, 2013 at 7:22 PM, Bill Myers
> wrote:
> >>
> >> Scala has a similar design, with the following traits:
> >> - TraversableOnce: can be interna
68 matches
Mail list logo
