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
>
> > wrote:
>
>> I do wonder whether it wouldn't make sense to add sugar for Option, at
>> least eventually. (`int?` at the type level is re
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
as another point in the design space, a pretty idiom for SQL style dbs in
haskell is the *-simple family of libs
postgres simple
http://hackage.haskell.org/package/postgresql-simple-0.3.7.0/docs/Database-PostgreSQL-Simple.html
mysql-simple
http://hackage.haskell.org/package/mysql-simple-0.2.2.4/d
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 d
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 channel
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 wrote:
> On Dec 20, 2013, at 8:59 AM, Carter Schonwald
> wrote:
citly pick a bound (with no
> “default” provided).
>
> -Kevin
>
> On Dec 20, 2013, at 12:55 PM, Carter Schonwald
> 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
a max size 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 dynamica
tc.).
>
> 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:
&
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
>
> > wrote:
>
>> Hello,
>>
>> Le 22 déc
that seems like a reasonable balance
On Mon, Dec 23, 2013 at 12:23 PM, Patrick Walton wrote:
> 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!()
>> into the sem
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, that
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 wrot
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 any
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 us
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,
>>
l, though
perhaps to different people, though how to do them really well is open to
some refinement perhaps
On Tue, Dec 31, 2013 at 12:35 PM, Patrick Walton wrote:
> On 12/31/13 7:20 AM, Carter Schonwald wrote:
>
>> In fact most haskellers building distributed/concurrent systems are
>>
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 wrote:
> On 12/31/13 1:33 PM, Nathan Myers wrote:
>
>> On 12/30/2013 08:58 PM, Patrick Walton wrote:
>>
>>> I'm not particularly intereste
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 >
> wrote:
> > About the deadlock scenario, why aren't non-blocking sends sufficient to
> > address that concern?
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 empha
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 the
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
limit
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" numb
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 wrote:
> On Sat, Jan 11, 2014 at 2:06 AM, Carter Schonwald
> wrote:
> > corey, those would be very very nice refinments and a healthy progres
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 wrap
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
rical computation 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
@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 d
ype checker too...
On Mon, Jan 13, 2014 at 4:06 PM, Tobias Müller wrote:
> Carter Schonwald
> 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 (th
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 req
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
mond <
wich...@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 propos
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 wrote:
> On Tue, Jan 14, 2
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
whatever the notation, it needs to be one that
a) gives good support for enforcing the "the shuffle is dictated at compile
time"
b) is really simple, and easy to adjust for different size SIMD vectors.
2x, 4x,8x,16x are all ones that currently and/or will soon exist on the
CPU front at the very le
6 PM, Jens Nockert wrote:
>
> On 2014/01/17, at 0:12, Carter Schonwald
> wrote:
>
> > whatever the notation, it needs to be one that
> > a) gives good support for enforcing the "the shuffle is dictated at
> compile time"
> > b) is really simple, and easy to
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 wrote:
> Hi, Tobias,
>
> Yes, there is. A monad is a functor by definition, so it has to accept
> a type to produce another
n can add a performance argument against using HOFs.
>
>
> On Sun, Mar 2, 2014 at 12:46 AM, Carter Schonwald <
> carter.schonw...@gmail.com
> > wrote:
>
>> indeed. I wonder how many rust idioms will change once HKT is sorted out?
>> (its something i'm very excited t
Well, hkt hasn't been done yet so there's that too :-)
On Monday, March 3, 2014, Daniel Micay wrote:
> On 03/03/14 07:27 PM, Carter Schonwald wrote:
> > Trust me when I say that monadic bind for simple things like option
> > should always be inlined away. In any sane l
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 wrote:
>
>
> On Mar 18, 2014, at 8:27 PM, Clark Gae
45 matches
Mail list logo
