[Moving to haskell-prime]
I think there would be real merit in some reworking of the module system,
especially to allow programmers to give the complete signature of a module,
perhaps by expanding what the export list says. Including instances.
Any such thing is very far from being a tried
Stephen Dolan wrote:
> unsafePerformIO is possibly the most ugly feature of Haskell, yet is
> necessary to do many things which should be possible without it, such
> as reading configuration from a file at startup or creating global
> IORefs
There is a considerable debate about global mutable sta
Stephen Dolan wrote:
At the moment,
we have the situation of modules using unsafePerformIO newIORef, which
influences program behaviour without being referenced by main.
Not really. Even with things as they currently are, if we have at the
top level..
resultOfSomething = unsafePerformIO doSom
I think what you're describing seems to be so completely different
from Haskell as it is now that that people either don't understand
it, or they do understand it and do think it's downright silly, but
are just too polite to say that. Maybe you should try writing it up
in a more comprehensible for
Stephen Dolan wrote:
Would this be useful, useless, or just downright silly?
The silence is deafening :-)
I think what you're describing seems to be so completely different
from Haskell as it is now that that people either don't understand
it, or they do understand it and do think it's downri
Ln $ show (fac val)
mainFunc
However, this approach does not work for modules which need to do
their own initialisation with the current module system.
I propose that it be legal to write things like this:
MyModule.hs:
fac n = product [1..n]
do
ref <- newIORef 42
module MyModule (ref, fac)
an
Hello Simon,
Thursday, February 23, 2006, 2:21:22 PM, you wrote:
SM>ghc --make My.Dotted.Module.hs Main.hs
SM> works fine. Similarly with GHCi.
i don't known that. we should add this to faq
SM> It's only when GHC has to actually *find* a source file for a module
SM> that the hierarchical
On 22 February 2006 14:55, Ben Rudiak-Gould wrote:
> Simon Marlow wrote:
>> there's a lack of modularity in the current
>> design, such that renaming the root of a module hierarchy requires
>> editing every single source file in the hierarchy. The only good
>> reason for this is the separation be
On 22 February 2006 13:09, David Roundy wrote:
> On Tue, Feb 21, 2006 at 03:50:29PM +, Henrik Nilsson wrote:
>> I'm already somewhat unhappy about the way most present Haskell
>> tools map module names to path names (I'd generally prefer to have
>> the possibility to flatten my file hierarchie
Georg Martius wrote:
> Okay, I see the point of not including the environment into the spec. However
> other languages like Java for example do this as far as I know.
To be precise, no, the Java specs leave this to the implementation:
JLS - 7.2. host support for packages
Each host determines h
ace reform boils down to rules for converting partial names
into canonical names. I can't see how any useful functionality in the module
system could depend on a particular way of organizing code on disk.
-- Ben
___
Haskell-prime mailing lis
David Roundby wrote:
> I'd like to second this. I've been annoyed by the fact that ghc
> requires extra subdirectories in order to use hierarchical modules,
> and would be doubly annoyed if the language definition declared that
> this couldn't be fixed. jhc's behavior sounds nicer, but I'd rath
David Roundy wrote:
> DR> fixed. jhc's behavior sounds nicer, but I'd rather there were the
> DR> possibility of naming our haskell files whatever we liked. Currently, as
> DR> far as I can see, we can only do this with Main, and even then there are
> DR> weirdnesses in ghc because Main.hi gets
Hello David,
Wednesday, February 22, 2006, 4:09:07 PM, you wrote:
DR> I'd like to second this. I've been annoyed by the fact that ghc requires
DR> extra subdirectories in order to use hierarchical modules, and would be
i'll be third :) i planned to fill a ticket but still not done it
DR> doub
Dear all,
Okay, I see the point of not including the environment into the spec. However
other languages like Java for example do this as far as I know.
Anyway, I would like to hear your comments about point 2-4 of my original
mail, because there are more important from my point of view. These d
On Tue, Feb 21, 2006 at 03:50:29PM +, Henrik Nilsson wrote:
> I'm already somewhat unhappy about the way most present Haskell tools map
> module names to path names (I'd generally prefer to have the possibility
> to flatten my file hierarchies by, say, using dots in my file names), but
> at lea
Dear all,
Simon M. wrote:
> This is not the first time that someone has made the same suggestion
> as Georg, and for good reasons: there's a lack of modularity in the
> current design, such that renaming the root of a module hierarchy
> requires editing every single source file in the hierarchy.
On 21 February 2006 18:22, Henrik Nilsson wrote:
> Georg wrote:
>
> > Well, the hierarchical module system as it is implemented today and
> > how it is proposed for being included into Haskell' uses the file
> > system to locate modules.
>
> Yes, too
On Tue, Feb 21, 2006 at 03:50:29PM +, Henrik Nilsson wrote:
> I'm already somewhat unhappy about the way most present Haskell tools
> map module names to path names (I'd generally prefer to have the
> possibility to flatten my file hierarchies by, say, using dots in
> my file names), but at lea
PS:
> True, but do these differences matter to us? Sorry for my naivety, but
> I can't see that much problems, expect very old 8.3 restrictions, but
> they are history now!
Here's a concrete example, then.
Windows file systems don't distinguish case.
Thus the two different Haskell modules "FOO
Hi Georg,
Georg wrote:
> Well, the hierarchical module system as it is implemented today and
> how it is proposed for being included into Haskell' uses the file
> system to locate modules.
Yes, tools need to, somehow, locate modules.
Yes, for portability reasons, it is conve
Hi Henrik,
On Tuesday 21 February 2006 16:50, Henrik Nilsson wrote:
> Hi all,
>
> Georg Martius wrote:
> > I have some proposals for changes of the hierarchical module system as
> > it is at the moment.
> > [...]
> > The hierarchical name can be derived
Hi all,
Georg Martius wrote:
> I have some proposals for changes of the hierarchical module system as
> it is at the moment.
> [...]
> The hierarchical name can be derived from the place in the filesystem.
This is not a comment about the above proposal in itself, which arguably
ha
Hello,
I have some proposals for changes of the hierarchical module system as it is
at the moment.
Goals:
- easy refactoring at Module/Package level
- easier import/export of trees of modules (useful for any larger library)
- relative imports/exports
- deep import or export lists
Simon Marlow wrote:
>>> Perhaps 'import' should be allowed anywhere among definitions.
> [...] Against:
> - tools that collect imports have to parse the whole file (eg. GHC's
>dependency analyser)
> - can't easily see what is imported
only if we keep the idea that "import" both says *that*
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> on balance, I like the way it is now.
An opinion to the contrary:
http://www.uclic.ucl.ac.uk/harold/srf/javaspae.html
"Importing packages: A brief example of design issues"
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> On 30 January 2006 09:03, Simon Peyton-Jones wrote:
>
>>>> With the module system, we should make a distinction between
>>>> declaring
>>>>
>>>> (1) that we want to use a modul
On 30 January 2006 09:03, Simon Peyton-Jones wrote:
>>> With the module system, we should make a distinction between
>>> declaring
>>>
>>> (1) that we want to use a module
>>> (2) how to bring the module's names into scope
>>
>>
Am Montag, 30. Januar 2006 10:13 schrieb Johannes Waldmann:
> [...]
> I am not sure what a local fixity declaration would mean
> for an operator that is defined in some outer scope.
I think, it should be handled the same way a local type declaration for a
variable that is defined in some outer s
On Mon, Jan 30, 2006 at 10:13:36AM +0100, Johannes Waldmann wrote:
> I am not sure what a local fixity declaration would mean
> for an operator that is defined in some outer scope.
It would mean a whole new class of obfusciation ability for haskell
programmers :)
John
--
John Meacham -
Simon Peyton-Jones wrote:
> Indeed. Requiring the import clauses to be at the top, and the fixity
> declarations, makes them easy to find -- but we don't require that for
> type signatures or class declarations etc. It'd be more consistent to
> allow imports and fixity declarations anywhere.
T
| > With the module system, we should make a distinction between
declaring
| >
| > (1) that we want to use a module
| > (2) how to bring the module's names into scope
|
| Perhaps 'import' should be allowed anywhere among definitions.
Indeed. Requiring the import cl
Johannes Waldmann <[EMAIL PROTECTED]> writes:
> With the module system, we should make a distinction between declaring
>
> (1) that we want to use a module
> (2) how to bring the module's names into scope
Perhaps 'import' should be allowed anywhere among definiti
With the module system, we should make a distinction between declaring
(1) that we want to use a module
(2) how to bring the module's names into scope
E. g. in Ada, there is "with" and "use", and "use" can be local,
see also http://www.dcs.gla.ac.uk/mail-www/h
34 matches
Mail list logo
