On Mon, Dec 01, 2008 at 05:30:33PM -0800, Judah Jacobson wrote:
You can limit the size of that stub file using:
foreign import ccall progname progname :: Ptr (Ptr CChar)
which lets you access that global variable and write the
getters/setters in Haskell rather than C.
this solves my
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global variable to be
defined. A C program using my_function, one of the library functions,
would look like:
char progname[] = a_program_name;
int
main(
On Mon, Dec 1, 2008 at 4:39 PM, Andrea Rossato
[EMAIL PROTECTED] wrote:
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global variable to be
defined. A C program using my_function, one of the library
On Mon, Dec 1, 2008 at 4:55 PM, Evan Laforge [EMAIL PROTECTED] wrote:
On Mon, Dec 1, 2008 at 4:39 PM, Andrea Rossato
[EMAIL PROTECTED] wrote:
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global
On Mon, Dec 01, 2008 at 04:55:14PM -0800, Evan Laforge wrote:
On Mon, Dec 1, 2008 at 4:39 PM, Andrea Rossato
[EMAIL PROTECTED] wrote:
Hello,
I'm writing the bindings to a C library which uses, in some functions,
global variables.
To make it clearer, those functions need a global
I would find a ForeignData extension incredibly helpful. This will be
crucial if Haskell ever wants to target out of the ordinary systems.
/jve
On Mon, Dec 1, 2008 at 8:38 PM, John Meacham [EMAIL PROTECTED] wrote:
On Mon, Dec 01, 2008 at 04:55:14PM -0800, Evan Laforge wrote:
On Mon, Dec 1,
Taral wrote:
On 5/23/07, Adrian Hey [EMAIL PROTECTED] wrote:
I think I still prefer..
var :: IORef Int
var - newIORef 3
So do I. For one very good reason: this syntax could be defined as a
constructor syntax and guaranteed to run before main.
Or even at compile time (which is why I think
On 5/24/07, Adrian Hey [EMAIL PROTECTED] wrote:
Taral wrote:
The other syntaxes proposed don't strike me as sufficiently rigorous.
Me neither. It's always been a great source of puzzlement to me why this
very simple and IMO conservative proposal should be so controversial.
Unless someone can
Adrian Hey wrote:
Taral wrote:
On 5/23/07, Adrian Hey [EMAIL PROTECTED] wrote:
I think I still prefer..
var :: IORef Int
var - newIORef 3
So do I. For one very good reason: this syntax could be defined as a
constructor syntax and guaranteed to run before main.
Or even at compile time
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time? (Well, I guess you could,
but that wouldn't still be
David House wrote:
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time? (Well, I guess you could,
but that
On 2007-05-24, David House wrote:
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time? (Well, I guess you
Aaron Denney wrote:
On 2007-05-24, David House wrote:
On 24/05/07, Adrian Hey [EMAIL PROTECTED] wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being IO
operations at all).
You can allocate heap space at compile time?
Isaac Dupree wrote:
var :: IORef Int
var = {-# EVALUATE_THIS_TEXT_ONLY_ONCE #-} (unsafePerformIO (newIORef 3))
I think I still prefer..
var :: IORef Int
var - newIORef 3
or, more likely..
var :: IORef Int
var - ACIO.newIORef 3
The - syntax should make the intended semantics clear and
On 5/23/07, Adrian Hey [EMAIL PROTECTED] wrote:
I think I still prefer..
var :: IORef Int
var - newIORef 3
So do I. For one very good reason: this syntax could be defined as a
constructor syntax and guaranteed to run before main.
The other syntaxes proposed don't strike me as sufficiently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Isaac Dupree wrote:
Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or
USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE
would be a good first step... if successful it would remove the
occasional need for -fno-cse for
| I see no need two answer this again I believe I have already made my
| views perfectly clear already and provided ample evidence to justify
| them. Surely I don't need to do it again?
Is there a Wiki page about this somewhere? Often email gets into a loop
because not everyone reads
On 21-mei-2007, at 9:31, Simon Peyton-Jones wrote:
| I see no need two answer this again I believe I have already made my
| views perfectly clear already and provided ample evidence to justify
| them. Surely I don't need to do it again?
Is there a Wiki page about this somewhere? Often email
Jules Bean wrote:
I've pretty much convinced it's wrong. There should be one and only
one main from which all subsequent IO activity derives. But creating
internal state in the form of mutable data structures is not an IO
activity. It just so happens that at the moment the only way to do this
is
Adrian Hey wrote:
Jules Bean wrote:
I've pretty much convinced it's wrong. There should be one and only
one main from which all subsequent IO activity derives. But creating
internal state in the form of mutable data structures is not an IO
activity. It just so happens that at the moment the
[cc'ing HPrime]
Isaac Dupree wrote:
The unsafePerformIO hack being used is not very satisfactory given how
many optimizations make it difficult to use safely in practice. This
hack is also used many places. I would be happier if that situation
were not true, and I suspect there's something
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian Hey wrote:
[cc'ing HPrime]
Isaac Dupree wrote:
The unsafePerformIO hack being used is not very satisfactory given how
many optimizations make it difficult to use safely in practice. This
hack is also used many places. I would be
Isaac Dupree wrote:
Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or
USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE
would be a good first step... if successful it would remove the
occasional need for -fno-cse for a whole module in GHC, at least.
I have a hard
Adrian Hey wrote:
Also, I don't know if the OP was a noob, but telling people (especially
noobs) that if they can't figure out how to solve a problem without
using a global variable then that must be down to inexperience and
general cluelessness on their part just seems wrong to me. It simply
Jules Bean wrote:
That's not my point. newIORef creates unique names (references). The
whole job of newIORef is to create unique names; unique names which
refer to little tiny bits of state parcelled up somewhere in that
mysterious IO monad. It is the scope of this uniqueness I'm talking
Albert Y. C. Lai wrote:
Adrian Hey wrote:
Also, I don't know if the OP was a noob, but telling people (especially
noobs) that if they can't figure out how to solve a problem without
using a global variable then that must be down to inexperience and
general cluelessness on their part just seems
Hello Isaac,
Sunday, May 20, 2007, 6:41:54 PM, you wrote:
Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or
USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE
would be a good first step...
or LOOK_BUT_DON'T_TOUCH :)
--
Best regards,
Bulat
| and (at worst) are evil. These people are quite simply wrong and
| should be ignored :-)
|
| Adrian Hey is not only wrong, but actually evil. He should be ignored. :-)
|
| I am right, I might well be evil, and if past experience is anything to
| go by I already know that I will be ignored.
On Thu, 17 May 2007, Jules Bean wrote:
Eric wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
(Perhaps annoyingly) the answer to this question, like so many other
questions on this list, is a question. What are you trying to do?.
[I agree with your points, but...]
Adrian Hey wrote:
I've pretty much convinced it's wrong. There should be one and only
one main from which all subsequent IO activity derives. But creating
internal state in the form of mutable data structures is not an IO
activity. It just so happens that at
Jules Bean wrote:
main = do
sockstate - initSocks
graphstate - initGraphics
...
disposeGraphics graphstate
disposeSocks sockstate
exit
Voila. Mutable state which persists for our entire program.
Arguably it's a pain passing around the state explicitly. Alternatively,
you can
Simon Peyton-Jones wrote:
For example, I was looking back at your ACIO mail a couple of months ago,
when I was thinking about concurrency.
Actually, this is Ian Starks proposal..
http://www.haskell.org/pipermail/haskell-cafe/2004-November/007664.html
..but is one with which I agree. I just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian Hey wrote:
Furthermore, if it is going to take this state handle as an explicit
argument then you need to provide some way for users to get this
state handle. This could be by..
1 - Making it an argument of main.
2 - Exposing a
On Thu, May 17, 2007 at 07:25:03PM +0100, Adrian Hey wrote:
The above hack is not actually Haskell. It's a hack, and it depends on
the particular implementation characteristics of GHC. It is not
unreasonable to imagine that a future GHC might contain different
compilation techniques (I
On Thu, May 17, 2007 at 11:00:18PM +0100, Jules Bean wrote:
I'm not sure that's quite to the point. Clearly we can set up state at
the top of our main action:
main = do
sockstate - initSocks
graphstate - initGraphics
...
disposeGraphics graphstate
disposeSocks sockstate
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
E.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
eeoam:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
E.
The usual way is to run the code that needs a global variable in a State monad.
The next answer is: you don't really need global variables, since you
don't have mutable variables
On 17/05/07, Eric [EMAIL PROTECTED] wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
You can pass around an environment with the State or Reader monads
(read/write and read-only respectively). If you want to do IO with the
data you'll
You can also use mutable variables (MVars) found in Control.Concurrent.MVar
http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html
They might work depending on your implementation. The reading and
writing of MVars returns IO actions.
On 5/17/07, Dougal Stanton
On Thu, 17 May 2007 14:41:33 +0100
Eric [EMAIL PROTECTED] wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
E.
Another alternative, for write-once variables, is implicit parameters.
--
Robin
On Thu, May 17, 2007 at 02:41:33PM +0100, Eric wrote:
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
Just declare them at the top level, as a function but without
arguments:
===
x =
Eric wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
(Perhaps annoyingly) the answer to this question, like so many other
questions on this list, is a question. What are you trying to do?.
The reason for this is that haskell's
Eric wrote:
H|i,
Does anyone know of a simple and straightforward way to use global
variables in Haskell?
I assume what you're looking for is to be able to have IORefs,MVars
Chans etc at the top level. The standard (for want of a better word)
way to do this is known commonly known as the
Please take this message in the fashion that is intended. My criticism
is light hearted, as I believe yours is.
Adrian Hey wrote:
[hack snipped]
BTW, this is the commonly the subject of flame wars on the Haskell
mailing lists because there appear to be many who passionately believe
and
On 17/05/07, Jules Bean [EMAIL PROTECTED] wrote:
I'd be willing to take a sportsman's bet that the original poster
does not actually need to use this hack; I doubt his application falls
into the categories you have outlined. I would discourage people from
using this hack unless it is, in fact,
Jules Bean wrote:
BTW, this is the commonly the subject of flame wars on the Haskell
mailing lists because there appear to be many who passionately believe
and assert that so called global variables are (at best) unnecessary
and (at worst) are evil. These people are quite simply wrong and
should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Adrian Hey wrote:
They are necessary because they are the only way to ensure important
safety properties of many IO APIs.
That's a bold claim. It's very hard to prove that things don't exist.
(That is, that other ways to ensure these safety
Adrian Hey wrote:
We've been talking about
this problem for years, but nothing is ever done about it (a solution to
this problem isn't even on the agenda for Haskell' AFIAK).
The problem needs talking about, it's important.
My objection was the implication that top-level mutable state was the
Albert Y. C. Lai wrote:
There is no reality about global variables. Global variables are
syntactic sugar for local variables. That is the reality we need to
think through. This syntactic sugar streamlines many practical programs
and is indeed valuable.
I agree that the use of the term global
On 5/17/07, Adrian Hey [EMAIL PROTECTED] wrote:
Jules Bean wrote:
BTW, this is the commonly the subject of flame wars on the Haskell
mailing lists because there appear to be many who passionately believe
and assert that so called global variables are (at best) unnecessary
and (at worst) are
Benjamin Franksen [EMAIL PROTECTED] writes:
We could reduce the pain of applying the C wrapper solution a bit by adding
some support in the FFI. I imagine a feature to allow writing small C
wrappers around imported foreign routines directly inside the Haskell
module.
Such a facility is
(stdin,stdout,stderr) seem to naturally have this scope (assuming you
don't use freopen). There needs to be only one Handle created for each
of these because otherwise the buffering won't work properly. Global
- initializers seem like the right thing here.
I think I would rather have them
I think the broad issue is that there are many different levels of the
system at which something can be global: a module, a thread, a process,
a user, a computer, a network segment, the internet, the universe, etc..
If your model of a concept is more global than the concept itself, you
lose
On Tuesday 09 November 2004 03:18, Ben Rudiak-Gould wrote:
Adrian Hey's example of a badly-written C library is one. But I agree
with Robert Dockins that such cases are better solved in C than in Haskell.
Yes. Your code won't depend on compiler (dependent) flags to disable
optimizations, which
54 matches
Mail list logo
