indeed! Thanks erik!
On the paralllel list, edkso shares with us a single commit that adds all
the requested features as a user land lib
https://github.com/haskell-distributed/distributed-static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7
@tweag folks, please do not write personal attacks
For interested fellows, discussion also continues in [1] and [2].
Best,
Facundo
[1] https://ghc.haskell.org/trac/ghc/ticket/7015
[2] https://groups.google.com/d/topic/parallel-haskell/b-x7VmjlEOw/discussion
On Thu, Jan 30, 2014 at 4:47 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
On 01/28/2014 06:03 PM, Carter Schonwald wrote:
Theres actually a missing piece of information in this thread: what
are the example computations that are being sent? My understanding is
that erlang has not way to send file handles, shared variables,
Tvars, Mvars, memory mapped binary files, GPU
Hi Carter,
On Tue, Jan 28, 2014 at 6:03 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Theres actually a missing piece of information in this thread: what are the
example computations that are being sent?
Quite simply, the same as those considered in the original Cloud
Haskell paper,
Hi Eric,
On Wed, Jan 29, 2014 at 3:20 AM, Erik de Castro Lopo
mle...@mega-nerd.com wrote:
Mathieu Boespflug wrote:
thank you for the good points you raise. I'll try and address each of
them as best I can below.
0) I think you could actually implement this proposal as a userland
library,
Hello,
I'd just like to say I haven't gone over every discussion in this
thread and had time to digest it all - I thought I would just
highlight a minor technicality.
On Fri, Jan 24, 2014 at 11:19 AM, Facundo Domínguez
facundo.doming...@tweag.io wrote:
Looking up static references
Hi Austin,
this is very useful information, thanks. So it seems that the rts
linker is here to stay for a while longer still, at least because
there is no good alternative on Windows as of yet.
If I understand you correctly, on Windows dynamic linking is not an
option in part because of the
To address the concerns about static linking and portability, there is
also the alternative of of using the RTS linker in those platforms
that need it.
In many aspects, neither linker makes a big difference to us. We are
going with the system's dynamic linker mainly because GHC team has
expressed
Hi Carter, Tim,
On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
anyways
1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt
dynamic loading as a user land library.
If you can't make it work as a library and can demonstrate why (or
Hi Mathieu,
On 28 Jan 2014, at 12:53, Mathieu Boespflug wrote:
We would prefer to do it that way, to be honest. As explained in my
previous email, we identified two problems with this approach:
1) User friendliness. It's important for us that Cloud Haskell be
pretty much as user friendly
Theres actually a missing piece of information in this thread: what are the
example computations that are being sent?
My understanding is that erlang has not way to send file handles, shared
variables, Tvars, Mvars, memory mapped binary files, GPU code / memory
pointers , and other fun unportable
Hello Carter,
Thanks for the links. IIUC the ObjLink module contains an interface
to the RTS linker. The points raised by Mathieu in his last email as
(1a), (1b) and (2) still hold.
Here's a use case for (2):
module Communicate(run)
import Control.Distributed.Process
f :: Int - Int
f = id
Escuse me, the module export list was meant to be
module Communicate(runExpect, runSend) where
Facundo
On Tue, Jan 28, 2014 at 5:13 PM, Facundo Domínguez
facundo.doming...@tweag.io wrote:
Hello Carter,
Thanks for the links. IIUC the ObjLink module contains an interface
to the RTS linker.
Mathieu Boespflug wrote:
[Sorry for the multiple reposts - couldn't quite figure out which
email address doesn't get refused by the list..]
Hi Carter,
thank you for the good points you raise. I'll try and address each of
them as best I can below.
0) I think you could actually
Hi Brandon,
On 26 Jan 2014, at 19:01, Brandon Allbery wrote:
On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson watson.timo...@gmail.com wrote:
In Erlang, I can rpc/send *any* term and evaluate it on another node. That
includes functions of course. Whether or not we want to be quite that general
On 25 Jan 2014, at 18:12, Carter Schonwald wrote:
1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt
dynamic loading as a user land library.
If you can't make it work as a library and can demonstrate why (or how even
though it works its not quite satisfactory),
On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson watson.timo...@gmail.comwrote:
In Erlang, I can rpc/send *any* term and evaluate it on another node. That
includes functions of course. Whether or not we want to be quite that
general is another matter, but that is the comparison I've been making.
anyways
1) you should (once 7.8 is out) evaluate how far you can push your ideas
wrt dynamic loading as a user land library.
If you can't make it work as a library and can demonstrate why (or how
even though it works its not quite satisfactory), thats signals something!
But I really think
Hello,
With the support of Tweag I/O, Mathieu and I have been assembling
a design proposal for the language extension for Static values that
will take Cloud Haskell a big step forward in usability. Please, find
the proposal inlined below.
We are looking forward to discuss its feasibility
Hey Facundo,
thanks for sharing this proposal.
several questions:
0) I think you could actually implement this proposal as a userland
library, at least as you've described it. Have you tried doing so?
1) what does this accomplish that can not be accomplished by having various
nodes agree on a
I don't have time to weigh in on this proposal right now, but I have several
comments...
On 24 Jan 2014, at 17:19, Facundo Domínguez wrote:
Rationale
===
We want the language extension to meet the following requirements:
1. It must be a practical alternative to the remoteTable
On 24 Jan 2014, at 17:59, Carter Schonwald wrote:
0) I think you could actually implement this proposal as a userland library,
at least as you've described it. Have you tried doing so?
I didn't pick up on that at all - how would we be able to do that?
1) what does this accomplish that can
On Fri, Jan 24, 2014 at 12:19 PM, Facundo Domínguez
facundo.doming...@tweag.io wrote:
In principle, only symbols in shared libraries can be found. However,
the dynamic linker is able to find symbols in modules that are linked
statically if GHC is fed with the option -optl-Wl,--export-dynamic.
[Sorry for the multiple reposts - couldn't quite figure out which
email address doesn't get refused by the list..]
Hi Carter,
thank you for the good points you raise. I'll try and address each of
them as best I can below.
0) I think you could actually implement this proposal as a userland
MyState, Int...
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Ashley Yakeley
| Sent: 28 June 2003 00:25
| To: [EMAIL PROTECTED]
| Subject: Re: Language extension proposal
|
| In article [EMAIL PROTECTED],
| Andrew J Bromage [EMAIL PROTECTED
If we could only figure out a good syntax for
(optional) type application, it would deal rather nicely with many of
these cases. Trouble is, '..' gets confused with comparisons. And
when there are multiple foralls, it's not obvious what order to supply
the type parameters.
What about
At 2003-06-30 01:55, Ralf Hinze wrote:
What about
mantissa (| Double |) + 4 ?
This would work perfectly with my method if (| Double |) were syntactic
sugar for (mkType :: Type Double) or similar. I really think it's the
most straightforward way of doing it and I hazard the easiest to
Hi
There's nothing wrong with this in principle; the difficulty is that
when you say
mantissa + 4
you aren't saying which float type to get the mantissa of. Earlier
messages have outlined workarounds, but in some ways the real solution
is to provide a syntax for type application.
Ashley Yakeley wrote:
Oh I do this all the time in HBase. I simply do this:
data Type a = MkType
getType :: a - Type a
getType _ = MkType
class (Bounded a) = FloatTraits a where
epsilon :: a
mantissaDigits :: Type a - Int
Suffering from persecution mania,
I prefer to know
At 2003-06-28 02:51, Ralf Laemmel wrote:
Suffering from persecution mania,
I prefer to know for sure that nobody never ever will
pattern match on those a's. So I prefer to write:
I don't understand. Did you mean pattern-match on MkType? I could stop
that by hiding it but exposing mkType =
Ashley Yakeley wrote:
At 2003-06-28 02:51, Ralf Laemmel wrote:
Suffering from persecution mania,
I prefer to know for sure that nobody never ever will
pattern match on those a's. So I prefer to write:
I don't understand. Did you mean pattern-match on MkType? I could stop
that by hiding
In article [EMAIL PROTECTED],
Andrew J Bromage [EMAIL PROTECTED] wrote:
Another example is floating point format information, like the
information in C's float.h. One might implement this as:
class (Bounded a) = FloatTraits a where
epsilon :: a-- OK
this man, he talks in maths. | www.isi.edu/~hdaume
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew J Bromage
Sent: Tuesday, June 24, 2003 9:18 PM
To: [EMAIL PROTECTED]
Subject: Language extension proposal
G'day all.
I've been
G'day all.
On Wed, Jun 25, 2003 at 08:48:12AM -0700, Hal Daume wrote:
I'm not sure this is really necessary (at least syntax-wise).
Well, of course, no extension is absolutely necessary in a Turing-hard
language. :-)
For the record, here are a couple of other solutions which avoid the
G'day all.
I've been toying with an idea for a small language extension, and I
was curious what you all think of this.
As a motivating example, consider the following standard typeclass:
class Bounded a where
min :: a
max :: a
This is an example of what I refer
} Language extension proposal
*
Adding the following language features seem to make Haskell more fit
the needs of programming mathematics:
(der)more "deriving" abilities
(overl) extended polymorphism for values and instance ove
36 matches
Mail list logo