Such sugar would would use some sort of monad trait right?
On Sunday, December 8, 2013, Ziad Hatahet wrote:
On Sat, Dec 7, 2013 at 2:21 PM, Gábor Lehel
illiss...@gmail.comjavascript:_e({}, 'cvml', 'illiss...@gmail.com');
wrote:
I do wonder whether it wouldn't make sense to add sugar for
do notation is a bit better behaved than scala's for notation (afaik)
When HKT and the associated traits happen, some analogue of the Functor and
Applicative abstractions in haskell would be great complements to monads.
In fact, it can easily be argued that they're more important in many
library
Yup. It's a known problem in the Haskell community that folks wish to
eventually move away from.
On Friday, December 13, 2013, György Andrasek wrote:
On 12/13/2013 12:53 PM, spir wrote:
I think this is a good possibility, make the module/crate organisation
mirror the filesystem (or the
maybe i'm not understanding things, but is there any reason why the
standard library couldn't provide both types of channels? Its really really
not a which should be the default, but two abstractions/data structures
which are very very different in when they're used in practice!
Looking at the
could you explain an example deadlock scenario concretely?
by blocking we mean a function like *fn sendBlockingBoundedChan(self,
t:T)- ()*
that doesn't return until the message in enqueued? Why should that even be
the default sending procedure?
On Thu, Dec 19, 2013 at 1:40 PM, Patrick Walton
agreed! Applications that lack explicit logic for handling heavy workloads
(ie producers outpacing consumers for a sustained period) are the most
common culprit for unresponsive desktop applications that become completely
unusable.
relatedly: would not bounded but programmatically growable
kevin, what sort of applications and workloads are you speaking about. Eg
in your example irc server, whats the typical workload when you've used it?
cheers
-Carter
On Fri, Dec 20, 2013 at 12:54 PM, Kevin Ballard ke...@sb.org wrote:
On Dec 20, 2013, at 8:59 AM, Carter Schonwald carter.schonw
:55 PM, Carter Schonwald carter.schonw...@gmail.com
wrote:
kevin, what sort of applications and workloads are you speaking about. Eg
in your example irc server, whats the typical workload when you've used it?
cheers
-Carter
On Fri, Dec 20, 2013 at 12:54 PM, Kevin Ballard ke...@sb.org wrote
thats enforced by the provided api,and I've been speaking with
that sort of memory usage model in mind.
On Fri, Dec 20, 2013 at 4:15 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
i'd be very very surprised if bounded channels in go don't dynamically
resize their queues
.).
Personally, I lean toward providing unbounded channels as the primitive
and implementing bounded channels on top of them OR providing both as
primitives.
On Fri, Dec 20, 2013 at 4:19 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
actually, you're right, in go they're fixed sized
Agreed!
On Sunday, December 22, 2013, Ziad Hatahet wrote:
But we already have Option::unwrap_or() and Option::unwrap_or_else() that
behave similar to the 'else' syntax suggested above.
--
Ziad
On Sun, Dec 22, 2013 at 10:37 AM, Léo Testard
leo.test...@gmail.comjavascript:_e({}, 'cvml',
that seems like a reasonable balance
On Mon, Dec 23, 2013 at 12:23 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/23/13 4:12 AM, Gábor Lehel wrote:
I don't like either that (a) the possible failure is silent, and
refutable lets look the same as irrefutable ones, nor (b) baking fail!()
This is a very good point. Many of those same issues apply in Haskell too.
Additionally, the examples people have given for refutable let thus far all
seem to be special cases of a do notation / computation expression /
monadic abstraction.
That said, unless a special builtin trait is made,
Indeed! And the producer can always have their own private backlog. There
is nothing preventing each producer having it's one internal backlog queue
that's not bounded. But such behavior should be deliberate rather than
accidental.
On Tuesday, December 24, 2013, Daniel Micay wrote:
On Tue, Dec
I'm not sure if that's how ghc channels work. I seem to recall that the
main ones are using STM, though I think there's an MVAr one. There's some
differences in semantics for the two.
On Wednesday, December 25, 2013, Benjamin Herr wrote:
On Tue, 2013-12-24 at 18:48 -0800, Patrick Walton
I'd be interested too. A good lock-free wait-free data structure is a
powerful abstraction in terms of the programmer's quality of life.
Likewise, afaik, hardware lock Ellision is only a real win in the no / low
contention case. You still need to provide a code path to fall back on if
there's
Exactly. Hence my suggestion :-). Non blocking explicit failure plus
(optionally adjustable) boundedness.
I believe some folks recently hacked out a nonblocking queue for rust a
month or so ago in the context of work stealing right?
On Thursday, December 26, 2013, Daniel Micay wrote:
On Thu,
as a counter point, in strongly typed languages (of which rust is one), the
type checker is a great aid in fixing breaking changes :). In fact it makes
addressing such breakages quite easy.
This is pretty notable in other strongly typed langs like haskell, when
theres been breaking changes, its
In fact most haskellers building distributed/concurrent systems are
emphatically in favor of only bounded channels.
On Tuesday, December 31, 2013, György Andrasek wrote:
On 12/31/2013 06:16 AM, Patrick Walton wrote:
I am concerned that we are only hearing one side of the argument here,
and
, though how to do them really well is open to
some refinement perhaps
On Tue, Dec 31, 2013 at 12:35 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/31/13 7:20 AM, Carter Schonwald wrote:
In fact most haskellers building distributed/concurrent systems are
emphatically in favor of only
what are some candidate data structures in that case? i'm happy to try and
hack out some prototypes for that.
On Tue, Dec 31, 2013 at 4:41 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 12/31/13 1:33 PM, Nathan Myers wrote:
On 12/30/2013 08:58 PM, Patrick Walton wrote:
I'm not
For the sake of concreteness, what would be an example of the live lock
scenario?
On Tuesday, December 31, 2013, Devin Jeanpierre wrote:
On Tue, Dec 31, 2013 at 4:40 PM, Jason Fager jfa...@gmail.comjavascript:;
wrote:
About the deadlock scenario, why aren't non-blocking sends sufficient to
question: is there any reason why cmake integration / support couldn't be
mediated via some improvements to rustpkg?
I had a first look at the current rustpkg api yesterday, and i ran away
screaming about the the many angled stringy typed ones that inhabit the
gaps in configuration space.
I
I realized something. A good near term working solution could make use of
the pending procedural macros to make a nicer syntax for the and_then
procedures!
(or could the current syntax rules style macros work with that even?). Not
sure If i'll have the time to do that experiment,
but throwing
If the in rust approach is chosen, I warmly recommend checking out some of
the design ideas in Shake. Shake has a pretty nice design that allows for
dynamic build deps (in make systems the way around that is to use make to
make your make files), and a few other neat ideas, including but not
corey, those would be very very nice refinments and a healthy progressive
yet conservative stance that leaves the room for evolving healthy defaults
(I've a slow boil program to bring breaking changes to fix numerical warts
in haskell over the next 2-3 years, )
@corey, one example of a Real
sounds like we agree! (and thanks for clarifying some of the detail points
i neglected)
On Sat, Jan 11, 2014 at 2:27 AM, Daniel Micay danielmi...@gmail.com wrote:
On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald
carter.schonw...@gmail.com wrote:
corey, those would be very very nice
excellent point owen. I'd agree myself, seeing how that exact same platform
dependent int/uint size gotchas (wrapping style semantics) are a recurrent
source of surprise in GHC Haskell, and other languages. In my own
applications I like wrapping semantics, but for most people, a signed
counter
http://static.rust-lang.org/doc/0.9/std/num/trait.Algebraic.html
On Sunday, January 12, 2014, Thad Guidry wrote:
Where is the fast inverse square root function in Rust ?
http://en.wikipedia.org/wiki/Fast_inverse_square_root
Anyone know if this semi-accurate function is at a hardware level
is subtle :-)
On Sunday, January 12, 2014, Carter Schonwald wrote:
http://static.rust-lang.org/doc/0.9/std/num/trait.Algebraic.html
On Sunday, January 12, 2014, Thad Guidry wrote:
Where is the fast inverse square root function in Rust ?
http://en.wikipedia.org/wiki/Fast_inverse_square_root
@daniel,
the GHC haskell IR predates LLVM, and theres actually some pretty nice
examples of LLVM doing AMAZING optimization of bit fiddling haskell code
(in fact, for any performance ratio, i can manufacture a natural bit
fiddlign example where ghc -fllvm is that much better than ghc -fasm for
bit
enforce what statically? There is a very really very subtle tradeoff in
how powerful a static verification scheme can be vs how easily it can be
used (the sweet spot being somewhere in between nothing and complete proof
based verification).
It sounds like there are valid arguments for several
...
On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller trop...@bluewin.ch wrote:
Carter Schonwald carter.schonw...@gmail.com
wrote:
enforce what statically? There is a very really very subtle tradeoff in
how powerful a static verification scheme can be vs how easily it can be
used
Neat proposal:
thoughts
0) seems like you need to add a notion of const expr to the type system for
this proposal, right? I started staring at that and it's pretty subtle
(though I may have been looking at it wrong)
1) do rust tuples actually map to the llvm simd vector types?
2) so this would
operation!
http://llvm.org/docs/LangRef.html#shufflevector-instruction
On Tue, Jan 14, 2014 at 2:07 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Neat proposal:
thoughts
0) seems like you need to add a notion of const expr to the type system
for this proposal, right? I started
...@vitalitystudios.com wrote:
On Tue, Jan 14, 2014 at 1:07 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Neat proposal:
thoughts
0) seems like you need to add a notion of const expr to the type system
for this proposal, right? I started staring at that and it's pretty subtle
(though I may have been
good point, SIMD vectors are values where you can't take pointers /
addresses (except when suitable cpu dependent intrinsics are available that
load a value from a memory and do an operation and optionally store it
again )
On Tue, Jan 14, 2014 at 3:09 PM, Daniel Micay danielmi...@gmail.com
ummm, the whole point of SIMD vector values is they work in register. Sure,
sometimes the register allocator may spill to stack, but while an *ARRAY*
of values of type T can have notion of an address, a SIMD Vector of T
(likely f64/f32/int32/int64) doesn't really have the same idea..
On Tue, Jan
indeed. I wonder how many rust idioms will change once HKT is sorted out?
(its something i'm very excited to find out :) )
On Sat, Mar 1, 2014 at 2:31 AM, Vladimir Matveev dpx.infin...@gmail.comwrote:
Hi, Tobias,
Yes, there is. A monad is a functor by definition, so it has to accept
a type
I'm in NYC.
ya'll should come to the nyc haskell hackathon, there'll be lots of folks
there who enjoy strongly typed systemsy code, tis april 4-6, all welcome!
www.haskell.org/haskellwiki/Hac_NYC
On Wed, Mar 19, 2014 at 9:40 PM, Andrew Morrow andrew.c.mor...@gmail.comwrote:
On Mar 18,
40 matches
Mail list logo
