Log of the #nice channel on irc.freenode.net

Using timezone: Central European Time
* arjanb leaves00:30
* cm_ leaves01:27
* bonniot leaves02:33
* bonniot joins10:22
* arjanb joins11:24
* cm_ joins13:20
hello
<bonniot>hi13:26
<cm_>Are we getting closer to a 1.0 release?14:05
<bonniot>time-wise, surely ;-)14:07
seriously, I just found a bug that I would like to see fixed before 0.9.914:08
then there will be a few more versions, because a few features are still missing
do you miss something specifically?14:09
otherwise, how is 1.0 important for you?
<cm_>Soon time to call to arms in order to conqueror the world then Nice everywhere ;-)
<bonniot>:-)
are you getting fluent?14:10
<cm_>The literal 1.0 isn't very important to me I'm not missing anything particular at the moment. I'm a nice rookie
Eventually
<bonniot>i think it's already time to mention Nice in technical forums, lists, ... when it is relevant14:12
of course at 1.0 it will be an occasion to make more noise ;-)14:13
<cm_>The fact that types aren't invariant was something a never have thought of but hey I'm not a computer scientist. It was however enlightening14:14
<bonniot>yes, I hope discovering Nice is an enlightening experience ;-)14:16
<cm_>How is it done in java 1.5? Runtime errors?
<bonniot>for arrays? ArrayStoreException, yes14:17
many things in Nice are about exchanging runtime errors with compile-time ones14:18
have you read http://nice.sourceforge.net/safety.html ?
<cm_>Eg List<A> al; List<B> bl; class A extends B {} bl= al; <-- I guess this is illegal in nice but is it in Java?14:19
<bonniot>no, illegal in both
<cm_>ok
<bonniot>java is invariant for classes, but covariant for arrays
not very consistent
<cm_>strange14:20
<bonniot>in Nice, you can even declare covariant classes when it is safe
<cm_>I haven't read safety.html. Is it sometimes hard to navigate nice.sf.net
<bonniot>suggestions are welcome14:21
:-)
<cm_>I guess i missed the link in "Presentation". This was the only one in this section. Another colour perhaps
Homo sapiens and perception 14:22
<bonniot>yes, I could improve the stylesheet14:24
<cm_>Have you thought of the import syntax? Perhaps a clearer differentiation between "java import" and package import.14:27
<bonniot>i don't know: even if it's more different, people might use the Java style sometimes for nice packages out of habit14:29
<cm_>I'm very used to import specfic classes in Java as eclipse takes care of that. 14:30
The import x.y.*; is somewhat sloppy.
Not to mention the greater probability for name clashes14:31
<bonniot>true14:32
<cm_>Why not pimport for package import or something similar14:33
<bonniot>looks funny!14:34
<cm_>indeed14:35
import x.y.<z> perhaps ;-)
<bonniot>so i'm aware the current situation is not perfect, just not sure what's the best solution14:36
another option is to also accept 'import x.y.z.*;' to import a Nice package14:37
<cm_>But the problem that you can't import specific java classes still remains - right?14:38
<bonniot>and to accept import x.y.MyClass; and disambiguate with package import based on which one exists (the class or the package)
there :-)
<cm_>ok
That can't be to hard to revolve
That is probably the best solution14:39
<bonniot>I although thought it might be useful to have a construct to "export" a package, so that packages importing you also import that package automatically
<cm_>Best is hard to define though
<bonniot>sure
do you know CSS?
<cm_>nope - need help?14:40
<bonniot>was trying something out14:41
<cm_>Implicit import? 14:42
<bonniot>no, for the webpages14:43
sorry
export, yes
<cm_>hehe - I meant the export construct
<bonniot>yes14:44
<cm_>Are you running Linux? Do you think ABI is important? I made the mistake discussion that yesterday - a very delicate subject. I'm just curious if the non-abi is a general agreement or not.14:46
<bonniot>yes, I'm running Debian14:47
i'm not familiar with the ABI question
<cm_>That keeping a binary compatible interface for kernel modules in order to overcome the situation where end users have to compile their own kernel. The pro non-abi thinks that everything should be open source and that the non-abi is enforcing that. The problem still occurs if you wan't to install third party products - open source or not.14:49
People can get very upset regarding this issue.14:50
<bonniot>isn't it easier to recompile the module against the headers of your kernel?
<cm_>Of course - but perhaps not that easy ;-) 14:52
The interfaces aren't api-stable either so that is also difficult
<bonniot>easier than recompiling a kernel I would say
if the interface changes, nothing saves you from modifying the module anyway, right?14:53
<cm_>Right, thats why I think that api and abi stability is important so that people can implement drivers indepentently from the core kernel developers14:54
<bonniot>on Debian there is a good utility, module-assistant, that makes recompiling kernel modules quite easy14:56
is this new style better for links on the website?14:57
yes, I'm all for independent development as much as possible14:58
<cm_>Yes, much better
Yes, and the kernel source tree is crazy huge.
Something is also wrong in the development method. It can't take 10 years to develop a descent kernel - not rocket science. If they only did their research right ;-) But not invented here is a very common attitude.15:01
<CIA-9>03bonniot * 10Nice/web/ (new.xsl gray.css): Make non-navigation links red in all cases, so they are more clearly visible.
<bonniot>true. i'm not sure about the timing though. there are not so many core contributors, and you need to be quite conservative when working on the kernel, so it takes time15:04
surely it could have been more efficient, but it's still an impressive result
<cm_>True, it took a long time before some understood that cycle optimization is selldom fruitful on modern hardware and to focus on asymptotic behaviour.15:06
<bonniot>did you follow kernel development?15:07
<CIA-9>03bonniot * 10Nice/web/language.html: Added links to "go further".15:08
<cm_>I have a friend that reads the mailing lists and we often have discussions. Someone argued that it is difficult to ensure O(1) memory allocation of two consecutive pages (for the stack 8k)15:09
What do you call a type parameter that has constraints? A guess you could make a comparsion to type classes in haskell?15:33
How to interpret the semantic difference between: <Foo T> f(T x) and f(Foo x)?15:36
<bonniot>that's missing the return type (which matters here)16:06
first Q: a constrained type parameter? :-)
<cm_>But if it is void16:07
<bonniot><Foo T> void f(T x) and void f(Foo x) are strictly equivalent16:08
(provided Foo is a class or non-abstract interface)16:09
<cm_>Ok, but what about <Foo T> void f(List<T> x) and void f(List<Foo> x) then?
<bonniot>yes, that's different, because List is invariant16:11
all clearM16:12
?
<cm_>I understand when to user either construct, I think, but a don't get the general picture. I might have to study some type inference first
user -> use
The consequences for the caller is clear but what are consequences for the callee?16:14
<bonniot>in the first version, the callee only knowns that the components of the list x have some subtype T of Foo16:16
so you cannot add a Foo to x (but you can add a T, which you can do if you got it from x like you could do when reordering)
in the second version you can add a Foo to x16:17
but then a caller cannot call that method with a List<FooBar>, which makes sense
<cm_>so f can't do x.add(new Foo()) in the first case?16:18
<bonniot>correct
<cm_>but x.add(new T()) is valid ;-). Seriously, how to add an element to x in f?16:19
In the first case
<bonniot>x.add(x.get(0))
or anything that has type T, for instance an additional argument of type T16:20
like in <Foo T> void foo(List<T> x, T y)
<cm_>Interesting, a guess the first construct has to be used for interfaces16:22
always
<bonniot>i don't see why?16:23
you can declare void foo(List<SomeInterface>)16:24
<cm_>eg f(List<IFoo> x), calling f with a List<Foo> is invalid I guess even if Foo is impl. IFoo
due to type invariance16:25
<bonniot>yes, but you can call f with a List<IFoo>
which contains Foos
List<IFoo> l = new ArrayList(); l.add(new Foo());16:26
<cm_>so List<IFoo> x; x.add(new Foo()) is valid then
<bonniot>that's correct
yes :-)
of course
it's even very useful
* CIA-9 leaves
* CIA-7 joins
<cm_>Pardon my non existing typ inference knowledge
<bonniot>no pb16:27
the non-variance is only a question when comparing two generic types
like List<IFoo> and List<Foo>
add has type: <T> void add(List<T> l, T x);16:28
so in particular you can use it for T=IFoo:
add(List<IFoo>, IFoo)
and since a Foo is also an IFoo, the call l.add(new Foo()) is correct16:29
<cm_>Ok, I guess that this can't be emphasize enough in examples. Something for the web site perhaps16:30
<bonniot>good idea, there could be a tutorial on type variables16:31
<cm_>My guess is that type invariance, covarience and related is going to be the major pitfall for many users.
* CIA-7 leaves16:32
* CIA-9 joins
<cm_>Type inference is greek for 99.999% of all programmers I guess16:34
But if you compare to haskell, eg.16:36
f xs= xs ++ [0]16:37
Has the type f :: Num a => [a] -> [a]
But you couldn't do it Nice as: <Num T> f(List<T> xs) { xs.add(new Integer(0)); }16:38
Given that Num if defined of course16:39
Thats why I am so confused16:41
<bonniot>type inference is about not writing all the types because the compiler can deduce them
so that's a simplification for users
but this is not what we have been speaking about here
<cm_>No, type system 16:42
I guess
<bonniot>ok
about your haskell program, it's not adding to the list, it's creating a new one
that makes a big difference typing-wise16:43
immutable lists can be co-variant (instead of non-variant)
<cm_>Could you pin-point why?16:44
(Not that the Haskell is creating a new list of course ;-) )16:45
* CIA-9 leaves16:46
* CIA-7 joins
* CIA-7 leaves16:49
* CIA-3 joins16:53
<arjanb>that haskell example looks simple but isn't16:54
<cm_>Eg this doesn't work: f xs= xs ++ [0.0]16:55
a = 1
Now f has the type Fractional a => [a] -> [a]
So f a is invalid
Even though f 1 is valid16:56
<arjanb>integer literals in haskell are short for fromInteger integerliteral fromInteger :: Int -> Num a16:57
<cm_>But anyway I don't understand the fundamental difference between immutable and mutable list and the consequences it has to the type system16:58
<bonniot>the reason you cannot accept mutable covariant lists is the following:
List<B> l = new ArrayList();16:59
foo(l);
B b = l.get(0);
with void foo(List<A> l);
foo(l) { l.add(new A()); }17:00
with class B extends A {}
<cm_>A follw
ow
<bonniot>that's it
the definition of foo is correct17:01
it's the call foo(l) that's incorrect
you cannot pass a List<B> where List<A> is expected (for mutable lists)
<cm_>As easy as that. Proof by contradictive example is my favorite
Lets hope that this was my final question about the type system in nice. A guess however that we have pin-pointed something that probably is subjected to great confusion17:04
<bonniot>note that variance question is the same in Java 5, so it will become easy to get material on that :-)17:05
<cm_>And the educational commission is left to Sun 17:06
Very good
The timing couldn't be better17:07
<bonniot>:-)17:10
we'll need to focus on what Java 5 *doesn't* provide
<cm_>A minor idea to the error reporting: If you issue a.f(b,c) you get a error message saying that f(A, B, C) isn't defined. It might be more clear to report that neither a method f(B, C) in A nor a function f(A, B, C) is defined.17:18
Even if the concept of function and method is interchangeable as far as I can understand17:19
<bonniot>yes, there are only methods now
what would the precise working be?
<cm_>That yould could check class A and look for an applicable method17:20
<bonniot>sorry, i meant "wording". how would the error message look like?17:22
<cm_>It is correct to say that the method owner is determined by the first argument (this) even if dispatching could relate all the arguments17:23
<bonniot>the concept of "method owner" seems empty to me in Nice17:24
<cm_>But nice distinguish between methods defined within a class or outside but without any semantic difference? Methods are exported to "java" when defined within17:26
<bonniot>no difference at all. all of them are exported17:27
<cm_>But how about multimethods?
<bonniot>all methods are multimethods :-)17:28
i don't get your question
<cm_>True, I meant how they are exported to Java.
<bonniot>if the first arg is a Nice class, as a member of that class17:29
<cm_>With Java i mean something that conforms to the class conception in the jvm
<bonniot>yes
if not, as a static member of the "dispatch" class17:30
<cm_>Ok17:35
About the error reporting. In java:17:37
Test.java:7: cannot find symbol
symbol : method f(int,int,int)
location: class Test
t.f(1,2,3);
^
1 error
The could be improved ;-)
Anyway I don't know if the concept of owners is applicable. I imagine that the Java programmer using Nice is going to define methods within classes and is consequently going to assume error messages reflecting the method owner concept17:41
How about a similar differentiation as for where methods are implemented (dispatch or not)17:43
Where within/out is a syntactic choice of preference17:48
<bonniot>we could use it in error messages17:51
i'm going to be away for the week-end18:00
see you on monday...18:04
<cm_>Have I nice week-end18:05
<bonniot>thx, you too18:06
* bonniot leaves
* CIA-3 leaves19:19
* CIA-9 joins19:20
* CIA-9 leaves
* CIA-9 joins19:55
* CIA-9 leaves21:43
* CIA-9 joins22:28
* cm_ leaves22:31
* Bluelive joins22:44
any life here ?22:45
* Bluelive leaves

Generated by Sualtam