On 2008-08-28 14:45 -0700 (Thu), Jonathan Cast wrote:
Now, I happen to know that the only top-level handles that can be
established without issuing an open system call are
stdin
stdout
stderr
(unless you're happy to have your global nonStdErr start its life
attached to an unopened FD).
Adrian Hey wrote:
There's shed loads of information and semantic subtleties about pretty
much any operation you care to think of in the IO monad that isn't
communicated by it's type. All you know for sure is that it's weird,
because if it wasn't it wouldn't be in the IO monad.
So I think you're
Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
In any case, what I'm trying to establish below is that it should be
a
safety property of - that the entire module (or perhaps mutually
recursive groups of them?) can be duplicated safely - with a new
name,
or as if with a new name - and
On Wed, Sep 3, 2008 at 2:53 AM, Ashley Yakeley [EMAIL PROTECTED] wrote:
It's worth mentioning that the current Data.Unique is part of the standard
base library, while hs-plugins is rather experimental. Currently Data.Unique
uses the NOINLINE unsafePerformIO hack to create its MVar. If
Dave Menendez wrote:
The Haskell 98 report includes NOINLINE, but
also states that environments are not required
to respect it. So hs-plugins wouldn't necessarily
be at fault if it didn't support Data.Unique.
Also, the definition of NOINLINE in the report doesn't
preclude copying both the
Ashley Yakeley wrote:
To solve this the hs-plugins dynamic loader maintains
state storing a list of what modules and packages have
been loaded already. If load is called on a module that
is already loaded, or dependencies are attempted to load,
that have already been loaded, the dynamic
Ashley Yakeley wrote:
Currently Data.Unique uses the NOINLINE unsafePerformIO
hack to create its MVar. If hs-plugins duplicates that MVar,
that's a bug in hs-plugins.
Sittampalam, Ganesh wrote:
Also, the definition of NOINLINE in the report doesn't
preclude copying both the MVar *and* its
Yitzhak Gale wrote:
Right. It would not be a bug in hs-plugins. That is
the most urgent problem right now.
[...]
For the short term - can we *please* get an ONLYONCE
pragma that has the correct semantics?
So the purpose of this pragma would solely be so that
you can declare hs-plugins buggy
I wrote:
For the short term - can we *please* get an ONLYONCE
pragma that has the correct semantics?
Sittampalam, Ganesh wrote:
So the purpose of this pragma would solely be so that
you can declare hs-plugins buggy for not respecting it?
No, the hs-plugins problem - whether hypothetical or
(apologies for misspelling your name when quoting you last time)
Yitzchak Gale wrote:
For the short term - can we *please* get an ONLYONCE pragma that has
the correct semantics?
Until a permanent solution is implemented and deployed in the
compilers (if ever), can we please have a pragma
For the short term - can we *please* get an ONLYONCE pragma that has
the correct semantics?
Sittampalam, Ganesh wrote:
How do you propose that this pragma would be implemented?
As far as I know now, in GHC it could currently just be
an alias for NOINLINE, but the GHC gurus could say for sure.
Yitzchak Gale wrote
Other applications and libraries that support the pragma - such as
other
compilers, and hs-plugins - would be required to respect the
guarantee, and bugs could be filed against them if they don't.
If hs-plugins were loading object code, how would it even know of the
I wrote
Other applications and libraries that support the pragma -
such as other compilers, and hs-plugins - would be
required to respect the guarantee, and bugs could be
filed against them if they don't.
Sittampalam, Ganesh wrote:
If hs-plugins were loading object code, how would it even
On Wed, Sep 3, 2008 at 9:30 AM, Yitzchak Gale [EMAIL PROTECTED] wrote:
I wrote
Other applications and libraries that support the pragma -
such as other compilers, and hs-plugins - would be
required to respect the guarantee, and bugs could be
filed against them if they don't.
Sittampalam,
Ganesh Sittampalam wrote:
You see this as a requirement that can be discharged by adding the ACIO
concept; I see it as a requirement that should be communicated in the type.
Another way of looking at it is that Data.Unique has associated with it
some context in which Unique values are safely
On Tue, 2 Sep 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
You see this as a requirement that can be discharged by adding the ACIO
concept; I see it as a requirement that should be communicated in the type.
Another way of looking at it is that Data.Unique has associated with it
some
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Eh? Please illustrate your point with Data.Unique. What requirements
does it place on it's context? (whatever that might mean :-)
It requires that its context initialises it precisely once.
It's context being main? If so this
Adrian Hey wrote:
We have to have something concrete to discuss and this is the simplest.
Like I said there are a dozen or so other examples in the base package
last time I counted and plenty of people have found that other libs/ffi
bindings need them for safety reasons. Or at least they need
On Mon, 1 Sep 2008, Adrian Hey wrote:
Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have global
main/process scope whether or not they're bound to something at the
top level.
Global variable is exactly the right term
On Thu, Aug 28, 2008 at 07:21:48PM -0400, Brandon S. Allbery KF8NH wrote:
OS provided one? What if you have an exokernel, where it is expected
these things _will_ be implemented in the userspace code. why
shouldn't
that part of the exokernel be written in haskell?
What's stopping it? Just
On Fri, Aug 29, 2008 at 04:33:50PM -0700, Dan Weston wrote:
C++ faced this very issue by saying that with global data, uniqueness of
initialization is guaranteed but order of evaluation is not. Assuming
that the global data are merely thunk wrappers over some common data
source, this
On Mon, 1 Sep 2008, John Meacham wrote:
On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote:
Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have global
main/process scope whether or not they're bound to
On 2008 Sep 1, at 18:08, Ganesh Sittampalam wrote:
On Mon, 1 Sep 2008, John Meacham wrote:
On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote:
Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have
global
On Mon, 1 Sep 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Sep 1, at 18:08, Ganesh Sittampalam wrote:
On Mon, 1 Sep 2008, John Meacham wrote:
for instance, windows dll's have
the ability to share individual variables across all loadings of said
dll. (for better or worse.)
Interesting, is
On Mon, 1 Sep 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Eh? Please illustrate your point with Data.Unique. What requirements
does it place on it's context? (whatever that might mean :-)
It requires that its context initialises it precisely
On Mon, 1 Sep 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Right, but they might be the same package version, if one is a dynamically
loaded bit of code and the other isn't.
OK. It's up to the dynamic loader to deal with this, and make sure that
initialisers are not run more than
Dan Doel wrote:
Here's a first pass:
-- snip --
{-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-}
module Unique where
import Control.Monad.Reader
import Control.Monad.Trans
import Control.Concurrent.MVar
-- Give Uniques a phantom region parameter, so that you can't accidentally
--
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
Well, yes, but if I implemented a library in standard Haskell it would
always be safely serialisable/deserialisable (I think). So the global
variables hack somehow destroys that property - how do I work out why it
does in some
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Adrian Hey wrote:
But then again, I'm sure that some that will be adamant that any way
of making global variables is a hack. But they'll still be happy
to go on using file IO, sockets etc regardless, blissfully unaware
of
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout and
stderr are things provided by the OS to a process. That's what defines
them as having process scope, not something the
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout
and stderr are things provided by the OS to a process. That's what
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout and
stderr are
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety
requirement has been met, but I think it fails on the improved API. The
main complaint would be what I see as loss of modularity, in that
somehow what should be a small irrelevant detail of
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
I don't follow what you mean. stdin, stdout and stderr are just file
descriptors 0, 1 and 2, aren't they? You can create them as many times as
you want with using that information
On 2008 Aug 31, at 10:44, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:
I don't follow what you mean. stdin, stdout and stderr are just
file descriptors 0, 1 and 2, aren't they? You can create them as
many
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety
requirement has been met, but I think it fails on the improved API.
The main complaint would be what I see as loss of modularity, in that
somehow what should be a
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 10:44, Ganesh Sittampalam wrote:
In that case it seems that any library that might be used from a
runtime that isn't the top-level of a process should avoid doing
IO
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you clearly think so little of that you need to ask:
process-global (or process-local depending on how you think
On Sun, 31 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote:
Thanks for taking the time to do this Dan. I think the safety requirement
has been met, but I think it fails on the improved API. The main complaint
would be what I see as loss of
On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:
Where do the filehandle structures live in the latter case?
The place you clearly think so little of that you need to ask:
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC
interface?
A value of type Unique you mean? This isn't possible. Data.Unique has
been designed so cannot be Shown/Read or otherwise
serialised/deserialised
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
What stops the same rule from applying to
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
If you want to standardise a language feature, you have to explain its
behaviour properly. This is one part of the necessary explanation.
To be concrete about scenarios I was considering, what happens if:
- the same
On Sat, 30 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be
serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
Well, yes,
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Every single call to newIORef, across the whole world, returns a different
ref.
How do you know? How can you compare them, except in the same Haskell
expression?
I can write to one and see if the other changes.
The same
Ganesh Sittampalam wrote:
On Sat, 30 Aug 2008, Adrian Hey wrote:
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
Well, yes, but if I implemented a library in standard Haskell it would
always be safely
Adrian Hey wrote:
Global variables are needed to ensure important safety properties,
but the only reasons I've seen people give for thread local variables
is that explicit state threading is just so tiresome and ugly. Well
that may be (wouldn't disagree), but I'm not aware of any library
that
On 2008 Aug 30, at 6:28, Adrian Hey wrote:
Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let
them be serialised/deserialised?
Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.
What
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today. It would be Perl, ML, or
On 2008 Aug 29, at 4:22, Adrian Hey wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be
the
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 29, at 4:22, Adrian Hey wrote:
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative
On Thu, 28 Aug 2008, Adrian Hey wrote:
Ganesh Sittampalam wrote:
On Thu, 28 Aug 2008, Adrian Hey wrote:
There's no semantic difficulty with the proposed language extension,
How does it behave in the presence of dynamic loading?
To answer this you need to be precise about the semantics of
C++ faced this very issue by saying that with global data, uniqueness of
initialization is guaranteed but order of evaluation is not. Assuming
that the global data are merely thunk wrappers over some common data
source, this means that at minimum, there can be no data dependencies
between
On Fri, Aug 29, 2008 at 4:33 PM, Dan Weston [EMAIL PROTECTED] wrote:
C++ faced this very issue by saying that with global data, uniqueness of
initialization is guaranteed but order of evaluation is not.
In C++ circles, this is referred to as the static initialization
order fiasco, and it is a
I actually was more interested in the problems with the obvious fix
for this, namely the construct on first use idiom:
int A(int a) { static int aa = a; return aa; }
int B() { return A(3); }
int C() { return A(7); }
int D() { if (today() == Tuesday) B(); else C(); return a(0); }
Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC
interface?
A value of type Unique you mean? This isn't possible. Data.Unique has
been designed so cannot be Shown/Read or otherwise
serialised/deserialised (for obvious reasons I guess).
Also what
Bryan O'Sullivan wrote:
I haven't seen a coherent description of
what the semantics of top-level - should be, but avoidance of
widespread swearing would be at the top of my list of requirements.
Don't the ACIO monad properties satisfy you?
Anyway, as I pointed out in my last post, if this is
I'm certain you can write a kernel in Haskell where the only use of
global variables is those that hardware interfacing forces you to use.
On Thu, Aug 28, 2008 at 3:32 AM, John Meacham [EMAIL PROTECTED] wrote:
On Thu, Aug 28, 2008 at 12:15:10AM +0100, Lennart Augustsson wrote:
I didn't say
Jonathan Cast wrote:
On Wed, 2008-08-27 at 11:53 +0100, Adrian Hey wrote:
John Meacham wrote:
As with all design decisions, it is sometimes the right thing and
sometimes the wrong one. And sometimes the most expedient. (which,
occasionally, is a perfectly valid driving force behind a certain
Lennart Augustsson wrote:
I don't don't think global variables should be banned, I just think
they should be severly discouraged.
If you're saying a language should not provide a sound way to do
this (as I believe you are), then AFAICT for all practical purposes
you *are* saying you think
Adrian Hey wrote:
There are plenty situations where it makes no semantic sense to allow
2 or more or some thing. A list of all active processes for example.
all referring to what scope? perhaps there occurs a situation
with several process (thread) pools, severals cores etc.
See also
Johannes Waldmann wrote:
Adrian Hey wrote:
There are plenty situations where it makes no semantic sense to allow
2 or more or some thing. A list of all active processes for example.
all referring to what scope? perhaps there occurs a situation
with several process (thread) pools, severals
On Thu, 2008-08-28 at 10:00 +0100, Adrian Hey wrote:
Lennart Augustsson wrote:
I don't don't think global variables should be banned, I just think
they should be severly discouraged.
If you're saying a language should not provide a sound way to do
this (as I believe you are), then
Jonathan Cast wrote:
On Thu, 2008-08-28 at 10:00 +0100, Adrian Hey wrote:
Lennart Augustsson wrote:
I don't don't think global variables should be banned, I just think
they should be severly discouraged.
If you're saying a language should not provide a sound way to do
this (as I believe
On Thursday 28 August 2008 12:26:27 pm Adrian Hey wrote:
As I've pointed out several times already you can find simple examples
in the standard haskell libs. So far nobody has accepted my challenge to
re-implement any of these competantly (I.E. avoiding the use of global
variables).
Why
I don't think anyone has claimed that any interface can be implemented
without globals.
Of course some can't (just pick an interface that is the specification
of a global variable).
What I (and others) claims is that such interfaces are bad. Using a
global variable makes an assumption that
On Thu, Aug 28, 2008 at 01:17:29PM -0400, Dan Doel wrote:
On Thursday 28 August 2008 12:26:27 pm Adrian Hey wrote:
As I've pointed out several times already you can find simple examples
in the standard haskell libs. So far nobody has accepted my challenge to
re-implement any of these
Lennart Augustsson wrote:
I don't think anyone has claimed that any interface can be implemented
without globals.
Of course some can't (just pick an interface that is the specification
of a global variable).
I said in the original challenge even I'd let you (anyone) change the
interface if you
On Thu, 28 Aug 2008, Adrian Hey wrote:
implicit parameters (a highly dubious language feature IMO).
How can you say that with a straight face at the same time as advocating
global variables? :-)
Ganesh
___
Haskell-Cafe mailing list
On Thu, 28 Aug 2008, Adrian Hey wrote:
There's no semantic difficulty with the proposed language extension,
How does it behave in the presence of dynamic loading? What about remote
procedure calls?
Also what if I want a thread-local variable? It seems like an extension
like this should
On Thu, Aug 28, 2008 at 09:00:41AM +0100, Lennart Augustsson wrote:
I'm certain you can write a kernel in Haskell where the only use of
global variables is those that hardware interfacing forces you to use.
And hence you need a safe way to use program-scope variables. It is true that
there are
Ganesh Sittampalam wrote:
On Thu, 28 Aug 2008, Adrian Hey wrote:
implicit parameters (a highly dubious language feature IMO).
How can you say that with a straight face at the same time as advocating
global variables? :-)
Quite easily, what's the problem? IORefs, Chans etc are perfectly
Jonathan Cast wrote:
This has been answered repeatedly, at least implicitly. Unless you
insist that getWhatever should live in the IO monad and have no
functional arguments (why?), there is no reason why this should be
impossible.
What's more, there seems to be no good *semantic* reason why
On Thu, 2008-08-28 at 22:24 +0100, Adrian Hey wrote:
Jonathan Cast wrote:
This has been answered repeatedly, at least implicitly. Unless you
insist that getWhatever should live in the IO monad and have no
functional arguments (why?), there is no reason why this should be
impossible.
On Thu, 2008-08-28 at 14:45 -0700, Jonathan Cast wrote:
On Thu, 2008-08-28 at 22:24 +0100, Adrian Hey wrote:
Jonathan Cast wrote:
This has been answered repeatedly, at least implicitly. Unless you
insist that getWhatever should live in the IO monad and have no
functional arguments
Lennart Augustsson wrote:
I don't think anyone has claimed that any interface can be implemented
without globals.
Of course some can't (just pick an interface that is the specification
of a global variable).
What I (and others) claims is that such interfaces are bad. Using a
global variable
Ganesh Sittampalam wrote:
On Thu, 28 Aug 2008, Adrian Hey wrote:
There's no semantic difficulty with the proposed language extension,
How does it behave in the presence of dynamic loading?
To answer this you need to be precise about the semantics of what
is being dynamically loaded. But
As I said earlier, global variables may be necessary when interfacing
with legacy things (software or hardware).
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today. It would be Perl, ML,
On 2008 Aug 28, at 17:01, John Meacham wrote:
On Thu, Aug 28, 2008 at 09:00:41AM +0100, Lennart Augustsson wrote:
I'm certain you can write a kernel in Haskell where the only use of
global variables is those that hardware interfacing forces you to
use.
OS provided one? What if you have an
Lennart Augustsson wrote:
As I said earlier, global variables may be necessary when interfacing
with legacy things (software or hardware).
By prior context I didn't mean legacy languages. I meant
logically prior - enclosing contexts.
It will always be necessary on occasion to refactor code
On Thu, 2008-08-28 at 23:48 +0100, Lennart Augustsson wrote:
The Haskell philosophy has always been to stick it out until someone
comes up with the right solution to a problem rather than picking some
easy way out. So I'd rather keep global variables being eye sores (as
they are now) to
Lennart Augustsson wrote:
The Haskell philosophy has always been to stick it out until someone
comes up with the right solution to a problem rather than picking some
easy way out.
I understood from your previous remarks that you regarded this as a
non-problem even in C. There's no
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today. It would be Perl, ML, or Java.
The Haskell philosophy has always been to stick it out until someone
comes up
On 2008 Aug 28, at 20:45, Adrian Hey wrote:
Lennart Augustsson wrote:
If Haskell had always taken the pragmatic path of adding what seems
easiest and most in line with imperative practice it would not be the
language it is today. It would be Perl, ML, or Java.
The Haskell philosophy has
On Thursday 28 August 2008 2:28:35 pm David Roundy wrote:
On Thu, Aug 28, 2008 at 01:17:29PM -0400, Dan Doel wrote:
On Thursday 28 August 2008 12:26:27 pm Adrian Hey wrote:
As I've pointed out several times already you can find simple examples
in the standard haskell libs. So far nobody
Lennart Augustsson wrote:
BTW, I'm not contradicting that the use of global variables can be
necessary when interfacing with legacy code, I just don't think it's
the right design when doing something new.
AFAICS the use of top level mutable state in the base libs has nothing
at all to do with
Lennart Augustsson wrote:
I told you where to look at code. It's C code, mind you, but written
in a decent way.
No well written device driver ever accesses memory or IO ports
directly, doing so would seriously hamper portability.
Well something must be accessing both. Dunno what you mean by
I've also written quite a few hosted and non-hosted device drivers (in C).
None of them have any global variables.
On Wed, Aug 27, 2008 at 9:07 AM, Adrian Hey [EMAIL PROTECTED] wrote:
Lennart Augustsson wrote:
I told you where to look at code. It's C code, mind you, but written
in a decent
Lennart Augustsson wrote:
I've also written quite a few hosted and non-hosted device drivers (in C).
None of them have any global variables.
The point is to be able to properly model, understand and if necessary
implement *entire systems* without using global variables (allegedly).
You can
On Wed, Aug 27, 2008 at 02:23:04AM +0100, Lennart Augustsson wrote:
BTW, I'm not contradicting that the use of global variables can be
necessary when interfacing with legacy code, I just don't think it's
the right design when doing something new.
As with all design decisions, it is sometimes
John Meacham wrote:
As with all design decisions, it is sometimes the right thing and
sometimes the wrong one. And sometimes the most expedient. (which,
occasionally, is a perfectly valid driving force behind a certain bit of
coding). However, I am fully convinced it is necessary. You don't even
Judah Jacobson wrote:
I've been wondering: is there any benefit to having top-level ACIO'd
- instead of just using runOnce (or perhaps oneshot) as the
primitive for everything? For example:
oneshot uniqueRef :: IO (MVar Integer)
uniqueRef = newMVar 0
I've been wondering about something like
I think a strong advantage of the straight up ACIO formulation (rather
than a one-shot IO based thing) is that it can be fully, correctly, and
safely be defined without referencing the IO monad or its interaction
with the IO monad at all. In practice, ACIO will be generally be used to
interact
Lennart Augustssom wrote:
Since at some point you have to interface with the hardware you are
forced to obey whatever convention is used for interrupts etc. At that
point you may very well have to use global variables. But you can
quickly abstract away from that in stay in the safe land
On Wed, 2008-08-27 at 11:53 +0100, Adrian Hey wrote:
John Meacham wrote:
As with all design decisions, it is sometimes the right thing and
sometimes the wrong one. And sometimes the most expedient. (which,
occasionally, is a perfectly valid driving force behind a certain bit of
coding).
On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote:
[cut]
However, note the weasel words. Those are in there on purpose, every
design calls for different solutions. To blanketly say certain
constructs are just wrong to the point of disallowing them in the
language, especially when they
Am Mittwoch, 27. August 2008 22:57 schrieb Jonathan Cast:
On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote:
Hello Jonathan,
Wednesday, August 27, 2008, 8:12:42 PM, you wrote:
* I wonder why that name was chosen? The design doesn't seem to have
anything to do with IO, it's
On Wed, 27 Aug 2008, Jonathan Cast wrote:
* I wonder why that name was chosen? The design doesn't seem to have
anything to do with IO, it's more of a `we have this in C so we want it
in Haskell too' monad.
The 'C' in ACIO says that it commutes with any operation in the IO
monad. Without that
On Wed, 2008-08-27 at 23:20 +0200, Daniel Fischer wrote:
Am Mittwoch, 27. August 2008 22:57 schrieb Jonathan Cast:
On Thu, 2008-08-28 at 00:53 +0400, Bulat Ziganshin wrote:
Hello Jonathan,
Wednesday, August 27, 2008, 8:12:42 PM, you wrote:
* I wonder why that name was chosen? The
1 - 100 of 115 matches
Mail list logo
