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 unope
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
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.
>
>
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
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
exi
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 f
(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 p
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
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 bug
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*
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
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 t
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 h
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
On Tue, Sep 2, 2008 at 4:19 PM, Ganesh Sittampalam <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Sep 2008, Ashley Yakeley wrote:
>>
>> It's worse than that. If you derive an instance of Typeable for your type,
>> it means everyone else can peer into your constructor functions and other
>> internals. Sure,
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 con
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 c
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 on
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 once.
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 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
"globa
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 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, 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 something at the
>> top level.
>
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
On Sun, 31 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
That sounds more feasible - though it does constrain a plugin architecture
(in which Haskell code can dynamically load other Haskell code) to
cooperate with the loading RTS and not load multiple copies of modules;
this mig
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
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 som
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 i
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:
process-glo
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 modulari
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 ab
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 to
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 sma
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 to those
handles, for fear of producing output corrupt
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 t
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 without
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 the
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 y
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 thin
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
defi
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 H
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
o
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
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
-- com
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 sto
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 s
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 serialisable/deserialisa
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
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, b
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 proces
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 Data.Random
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 (
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 i
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 i
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
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 i
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 plugi
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
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 practic
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
language
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 Java.
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
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 alway
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 w
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 justification
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 re
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 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 ex
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, or
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 thi
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 var
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 ar
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
> > impossib
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 th
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
ord
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
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 als
On Thu, 2008-08-28 at 20:28 +0100, Adrian Hey wrote:
> 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 o
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
Haskell-Cafe@ha
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, 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
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 there'
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).
>
> W
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 y
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), the
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
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 "si
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 glo
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 bi
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
On Thu, Aug 28, 2008 at 12:15:10AM +0100, Lennart Augustsson wrote:
> I didn't say NetBSD doesn't use global variables, I said the device
> driver model doesn't use global variables. And quite a few things
> that used to be in global variables have been moved into allocated
> variables and are bei
On 2008 Aug 27, at 12:12, 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.
As I understand it, "IO" means "anything not encompassed by
equationally-reas
I didn't say NetBSD doesn't use global variables, I said the device
driver model doesn't use global variables.
And quite a few things that used to be in global variables have been
moved into allocated variables and are being passed around instead.
That's simply a better way to structure the code.
On Wed, Aug 27, 2008 at 12:17:46PM -0500, Derek Elkins wrote:
> On Wed, 2008-08-27 at 02:35 -0700, John Meacham wrote:
> > 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 poi
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 wa
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
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
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 the
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
> > co
1 - 100 of 120 matches
Mail list logo
