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
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
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
| *** 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
20 matches
Mail list logo
