| Newsgroups |
gmane.comp.lang.nice.general |
| Message-ID |
<[email protected]> |
[Typos corrected and subject line fixed. Sorry to do this twice in one weekend!
- Brian]
Quoting Daniel Bonniot <[email protected]>:
> For private, your view is quite sound and quite be extended naturally.
> There are compilation units ("files"), and features can be visible only
> inside their unit if they are private. units are groups in packages,
> which hold the default visibility. public features are visible
> everywhere. (we would need to define this even if Nice didn't have this
> Java look, by the way)
In my proposal, I suggested to have the default visibility be private so that
there would be no "private" keyword which people would find to be confusing. To
make something visibile to the whole package, a "package" keyword would be used,
and to make it visible to everything, a "public" keyword would be used.
> In addition to the manual, it would indeed be great to have several
> tutorials/introductions, targetting different audiences. Currently, the
> user manual might have this Java flavour because such info is also
> needed, and it is not presented elsewhere. The more we have of this kind
> of material, the more we can make sure that the manual is "neutral".
> It's a question of manpower. It you and/or others would like to write a
> tutorial targetting people familiar with functional languages, that
> would be a great contribution.
That makes a lot of sense.
>
> >To be honest, I don't think that knowing Java is really that much of a
> >benefit to learning Nice anymore. It has diverged too much.
> >
> >
> There is a fair amount of interest around Nice. I don't think there
> would be half of it if the language was a traditional research language,
> with a brand new syntax and close to no libraries, however pure and
> clever that language may be.
I love marketting. :)
> >I agree that that sounds better but I don't think it describes the language
> as it is right now.
> >
> Any proposal? I'm aware mine is not perfect, it's just that perfection
> is hard ;-)
>
> >In particular, most of the support for modularity has not been
> >designed or implemented yet.
> >
> >
> Well, you can already write the kind of modular code that only
> multi-methods allow. What is missing is enforcing visibility. That does
> not really prevent you from anything, although it does miss the benefit
> of being sure a feature is not used out of its scope.
> So that's not a lie, but OK that's a half trugh ;-)
What I meant by both of my previous sentences above is that there doesn't seem
to be much modularity in Nice because its module system as not been designed
yet. First, there is the visiblity issue. Also, there should be a mechanism for
describing the interdependencies between modules. In Cecil, they have "module Z
extends module Y" which is important for their multimethod coverage checking (if
you have only "module X imports module Y" then X cannot extend any generic
functions or classes from module Y). Finally, there isn't documentation that
tells me what kinds of changes break the binary interface of a module.
> Visibility should not be very hard to implement, though. If somebody is
> considering helping out with the compiler, that might be a good way to
> get started.
I agree. I have been thinking about doing that. But then also I have been
thinking that maybe Nice should just adopt the whole O'Caml (or similar) module
system. If so, then I don't waste time doing a visibility modifiers
implementation that will be replaced later.
- Brian
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click