___
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
On Tue, 25 Sep 2001 17:41:06 +1000, Manuel M. T. Chakravarty wrote:
>> Many applications where GUIs are used require a canvas/scribble field
>> with the following basic functionality:
>>
>> - set a point in a particular color; if speed is an issue,
>> mapping a 2D-array content to the canvas w
"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 promised GUI mailing list is now available:
http://www.haskell.org/mailman/listinfo/gui
Manuel
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Ashley Yakeley <[EMAIL PROTECTED]> wrote,
> At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote:
>
> > *** The GUI Library Task Force Strategy Proposal ***
>
> It's worth pointing out that I'm covering much of the same ground with my
> bridge to the
"Ch. A. Herrmann" <[EMAIL PROTECTED]> wrote,
> Basically, I like the suggestions, but want to clarify:
>
> > * The library focuses on graphical *user interfaces* (ie,
> > buttons, menus, scrollbars, selection lists, etc) as
> > opposed to drawing and animation routines.
>
> Many application
On Mon, 24 Sep 2001, Ashley Yakeley wrote:
> At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote:
(snip)
> >* The library focuses on graphical *user interfaces* (ie,
> > buttons, menus, scrollbars, selection lists, etc) as
> > opposed to drawing and animation routines.
>
> Java has APIs for bo
At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote:
> *** The GUI Library Task Force Strategy Proposal ***
It's worth pointing out that I'm covering much of the same ground with my
bridge to the Java VM.
http://sourceforge.net/projects/jvm-bridge/
Of course there ar
"Carl R. Witty" wrote:
>
> "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
>
> > + More sophisticated approaches (that often require
> > language extensions or are still experimental) can be
> > implemented on top of this basic API - eg, FranTk,
> > Yahu, Fruit, iHas
Try http://www.cs.uu.nl/people/ralf/hw2001/3.html
I originally saw it on lambda:
http://lambda.weblogs.com/2001/09/07
-Alex-
On 24 Sep 2001, Carl R. Witty wrote:
> "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
>
> > + More sophisticated approaches (that often require
> >
"Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> writes:
> + More sophisticated approaches (that often require
> language extensions or are still experimental) can be
> implemented on top of this basic API - eg, FranTk,
> Yahu, Fruit, iHaskell, etc.
I keep seeing references t
| *** 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
On Mon, 24 Sep 2001, Ch. A. Herrmann wrote:
(snip)
> Many applications where GUIs are used require a canvas/scribble field
> with the following basic functionality:
(snip)
Absolutely. The only reason I've found Java usable is that I can make my
own Canvases and LayoutManagers and 'implement' many
Basically, I like the suggestions, but want to clarify:
> * The library focuses on graphical *user interfaces* (ie,
> buttons, menus, scrollbars, selection lists, etc) as
> opposed to drawing and animation routines.
Many applications where GUIs are used require a canvas/scribble field
with t
e appended proposal. As soon as this becomes
technical, I propose to take it off the main list to the new
GUI mailing list.
Cheers,
Manuel
-=-
*** The GUI Library Task Force Strategy Proposal ***
Goals
~
* Development of a GUI library API for Haskell that is
portable across Haskell s
35 matches
Mail list logo
