___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
On 10-Oct-2001, Hal Daume III <[EMAIL PROTECTED]> wrote:
> So, barring this, I'm curious how other people handle this issue.
>
> I have multiple projects. Call them A, B, C. They are in directories:
> ~/projects/A
> ~/projects/B
> ~/projects/C
> repsectively.
>
> Say I'm creating a new p
On Wed, Oct 10, 2001 at 03:29:03PM -0400, Hal Daume III wrote:
> So, barring this, I'm curious how other people handle this issue.
>
> I have multiple projects. Call them A, B, C. They are in directories:
> ~/projects/A
> ~/projects/B
> ~/projects/C
> repsectively.
>
> Say I'm creating a
So, barring this, I'm curious how other people handle this issue.
I have multiple projects. Call them A, B, C. They are in directories:
~/projects/A
~/projects/B
~/projects/C
repsectively.
Say I'm creating a new project, D, in ~/projects/D that uses code that
I've written in packages A,
On Wed, 10 Oct 2001, Hal Daume III wrote:
(snip)
> least) is that the Java compiler knows how to interpret the "."s and
> will use them to navigate directory structure.
(snip)
Yes, that's certainly an interesting idea. I'd like to fall short of
mandating anything about location of source files in
I think one important aspect of Java's java.foo.bar style has been
overlooked: the semantics. sure, syntactivally, java.foo.bar and
java_foo_bar; they're basically the same. the big issue (to me, at
least) is that the Java compiler knows how to interpret the "."s and
will use them to navigate di
"Manuel M. T. Chakravarty" wrote:
> * After this, the main difference that remains is the
> representation of GUI components as a vanilla data type
> instead of opaque handles that do not make the structure
> of the components explicit in the types (like the TupLS
> does). From the paper
Ian Lynagh <[EMAIL PROTECTED]> wrote,
> On Wed, Sep 26, 2001 at 10:59:55PM +1000, Manuel M. T. Chakravarty wrote:
> >
> > Currently, there doesn't seem to be much interest in going
> > for a completely new version of Haskell. The idea of adding
> > addenda to H98 and so slowly and in incrementa
> I don't think this is compatible with things like adding support
> for the library hierarchy with multiple dots to Haskell 98 as you
> will then be able to write a program that is valid Haskell 98 by
> todays definition but not yesterdays. OTOH if what you mean is
> adding support incrementally
On Wed, Sep 26, 2001 at 10:59:55PM +1000, Manuel M. T. Chakravarty wrote:
>
> Currently, there doesn't seem to be much interest in going
> for a completely new version of Haskell. The idea of adding
> addenda to H98 and so slowly and in incremental steps move
> to more functionality seems to be
At 18:53 25-9-01 +1000, Manuel Chakravarty wrote:
>"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote,
>
> > | * Start from the API of GTK+ as a base line:
> >
> > That's fine by me. But can I suggest that the task force be sure
> > to read the details of the Clean GUI library design. Peter Aachte
> Great. So that is something that goes into some library conventions
> document.
Such a document is here:
http://www.haskell.org/~simonmar/libraries/libraries.html
If there are comments on the design (which is by no means finalised),
please take them to the libraries mailing list.
C
Lennart Augustsson <[EMAIL PROTECTED]> writes:
> "S. Alexander Jacobson" wrote:
>> Great. So that is something that goes into some library conventions
>> document. Java has a convention that libraries should have reverse domain
>> name structure. Is that how we should use _?
> Yes, I think t
"S. Alexander Jacobson" wrote:
> Great. So that is something that goes into some library conventions
> document. Java has a convention that libraries should have reverse domain
> name structure. Is that how we should use _?
Yes, I think that could be the way. And in addition there should be
Great. So that is something that goes into some library conventions
document. Java has a convention that libraries should have reverse domain
name structure. Is that how we should use _?
-Alex-
On Wed, 26 Sep 2001, Lennart Augustsson wrote:
> "S. Alexander Jacobson" wrote:
>
> > On Wed, 26 S
"S. Alexander Jacobson" wrote:
> On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote:
> > > Given that Haskell98 is not ready for libraries anyway, why are you so
> > > concerned about it?
> >
> > It isn't? Why? Because of the lack of hierachical name
> > spaces? Then, C isn't ready for librar
"S. Alexander Jacobson" wrote:
> Haskell will not be production quality without concurrency. If concurreny
> allows for a cleaner API and easier to use library, then use it. BeOS had
> deep concurrency throughout and was a much better OS as a result. Its
> 2001, there is no reason I shouldn't
On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote:
> > Given that Haskell98 is not ready for libraries anyway, why are you so
> > concerned about it?
>
> It isn't? Why? Because of the lack of hierachical name
> spaces? Then, C isn't ready for libraries either.
As I posted in a prior thread:
At 2001-09-25 01:53, Manuel M. T. Chakravarty wrote:
>* I am not a big fan of introducing an extra monad (`GUI' in
> this case). It can easily become a pain in programs that
> do a lot of "normal" IO as you have to lift all IO
> functions to GUI.
Heh. I had to do this for JVM-Bridge because
"Manuel M. T. Chakravarty" wrote:
> * I am not a big fan of introducing an extra monad (`GUI' in
> this case). It can easily become a pain in programs that
> do a lot of "normal" IO as you have to lift all IO
> functions to GUI.
Shouldn't GUI be a typeclass (as a subclass of Monad), with
Given that Haskell98 is not ready for libraries anyway, why are you so
concerned about it? A GUI system without concurrency is still incomplete.
The haskell library interface story is still pretty weak because there is
no consensus about what monad they should expose (and whether they should
real
"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote,
> | * Start from the API of GTK+ as a base line:
>
> That's fine by me. But can I suggest that the task force be sure
> to read the details of the Clean GUI library design. Peter Aachten
> (while visiting Cambridge) rendered a good chunk of it i
| *** The GUI Library Task Force Strategy Proposal ***
Great!
| * Start from the API of GTK+ as a base line:
That's fine by me. But can I suggest that the task force be sure
to read the details of the Clean GUI library design. Peter Aachten
(while visiting Cambridge) rendered a good chunk
23 matches
Mail list logo
