My original goal in this thread was to explore a way to map module
identifiers to the locations of module implementations that
implementations can retrieve and compile with minimal user
intervention. We got sidetracked into grafting, and
I'd like to return to the original goal.
The big open q
S. Alexander Jacobson wrote:
> As I move from machine to machine, it would be nice not to have to
> install all the libraries I use over and over again. I'd like to be
> able to do something like this:
>
>import http://module.org/someLib as someLib
>
> If the requested module itself does
On 23 March 2005 13:11, Malcolm Wallace wrote:
> I think this will be trivially possible once the compilers support
> multiple versioning of packages. (Ghc may even support it already.):
>
> {-# OPTIONS -package foo-1.0 #-}
> module Old (module Foo) where
> import Foo
>
> {-# OP
Here is what I designed and implemented for my language Kogut:
There is a file format of compilation parameters (compiler options,
source file encoding, directories to look for interface files for
imported modules, directories to look for libraries, C libraries
to link, directories to look for pac
"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> Ok, well lets unpack what is actually required here:
>
> 1. Change of syntax in import statements
> GHC already has lots of new syntax.
I can see that one might wish to broaden the import syntax, rather
like Hugs once supported (but not now)
Hello
Here are some problems I see with the scheme:
1) No easy way of seing the dependencies of a single package.
Currently I can just look at the Cabal file and know what packages are
required. In the new scheme I would need to grep all the source files.
Not a very good improvement in my opinio
On Tue, 22 Mar 2005, Malcolm Wallace wrote:
Import statements should be allowed to include URL of Cabal packages.
Module namespace in these import statements should be with respect to
the package and not the local environment. e.g. these import
statements allow us to import two different versions
On Tue, 22 Mar 2005, Lemmih wrote:
The idea with Hackage was to create a central place for people to put
software or links to software, so keeping only one server for free (as
in beer) packages would be desirable. However, this does in no way
limit how Hackage can be used for private code repositor
On 22 March 2005 13:03, Lemmih wrote:
> On Tue, 22 Mar 2005 06:40:02 -0500 (Eastern Standard Time), S.
> Alexander Jacobson <[EMAIL PROTECTED]> wrote:
>> I don't understand. Are you saying that there will be only one
>> Hackage server ever and it will have all information about all
>> packages ev
On Tue, 22 Mar 2005 06:40:02 -0500 (Eastern Standard Time), S.
Alexander Jacobson <[EMAIL PROTECTED]> wrote:
> Proposal restatement:
>
> Import statements should be allowed to include URL of Cabal packages.
> Module namespace in these import statements should be with respect to
> the package and n
"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> Proposal restatement:
>
> Import statements should be allowed to include URL of Cabal packages.
> Module namespace in these import statements should be with respect to
> the package and not the local environment. e.g. these import
> statem
At 15:47 21/03/05 -0500, S. Alexander Jacobson wrote:
As I move from machine to machine, it would be nice not to have to install
all the libraries I use over and over again. I'd like to be able to do
something like this:
import http://module.org/someLib as someLib
If the requested module itse
Proposal restatement:
Import statements should be allowed to include URL of Cabal packages.
Module namespace in these import statements should be with respect to
the package and not the local environment. e.g. these import
statements allow us to import two different versions of Network.HTTP
On Mon, 21 Mar 2005 22:06:25 -0500 (Eastern Standard Time), S.
Alexander Jacobson <[EMAIL PROTECTED]> wrote:
> Lemmih,
>
> The current Haskell/Cabal module and packaging system is substantially
> annoying for the typical non-sysadmin end-user. In particular, if
> they move their code to another m
Lemmih,
The current Haskell/Cabal module and packaging system is substantially
annoying for the typical non-sysadmin end-user. In particular, if
they move their code to another machine they have to do a bunch of
different administrivia including:
1. knowing the source package for each module
On Mon, 21 Mar 2005 23:06:25 +0100, Sven Moritz Hallberg <[EMAIL PROTECTED]>
wrote:
> Greetings Alexander,
>
> I have been thinking about something very much similar for some time.
> But:
>
> Am 21. Mrz 2005 um 21.47 Uhr schrieb S. Alexander Jacobson:
>
> > As I move from machine to machine, it
A few quick thoughts:
1 Although technically HTTP URLs are locations rather than
identifiers, that is the behavior we want in this context. If you
want to trust someone else to serve you the correct module, you should
specify it. A formal spec should define exactly what URI schemes are
support
Greetings Alexander,
I have been thinking about something very much similar for some time.
But:
Am 21. Mrz 2005 um 21.47 Uhr schrieb S. Alexander Jacobson:
As I move from machine to machine, it would be nice not to have to
install all the libraries I use over and over again. I'd like to be
abl
18 matches
Mail list logo