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
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
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, 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 new
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, it
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 that could
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.
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 Aachten
(while
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 more
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 to
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 incremental steps
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:
*
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 be
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 libraries either.
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 Sep
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 some
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 applications where GUIs
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 Java VM.
http://sourceforge.net/projects/jvm
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
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 into
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 would be
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
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 all
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 systems
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 the
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
| *** 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
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 to Fruit
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
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, iHaskell, etc.
I
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 are differences
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 both, I
32 matches
Mail list logo
