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

* Mot joins12:52
* Mot leaves
* bonniot joins13:18
* arjanb joins13:24
<bonniot>hello arjan13:31
<arjanb>hello daniel
<bonniot>what's new?13:32
<arjanb>nothing but that i have vacation now13:33
it might be possible to get rid of the '=' in the dispatch on enum constants13:34
the reason for it was to avoid that a typo transforms them into a default implementation13:35
the solution would be that for a method declaration
void foo(Type param);
the default implementation must use the same name for the param:
foo(param) { ... }13:36
otherwise there would be an error
this could even be used to resolve which method is implemented
<arjanb>so then unnamed parameter are not allowed anymore?13:37
<bonniot>If the declaration has anonymous parameters, then they cannot be refered to without a pattern
or they could be completely forbidden, yes
if think the first option is safer for now
I think this change would be good, because = is not very pretty13:38
what do you think?
<arjanb>and what if the name of the parameter and a global constant have the same name13:39
<bonniot>then it is an error at the declaration of the method13:40
<arjanb>but if you import 2 packages one with the declaration and one with the global constant and you want the implement that method13:41
<bonniot>this would rarely happen, especially if there is a convention that enum values names start with a capital letter13:42
then you could use the fully qualified name
foo(first.pkg.Value) { ... }13:43
<arjanb>so without = is only for enums
<bonniot>foo(second.pkg.Value) { ... }
what is only for enums?
<arjanb>foo(someglobal) { ... }
instead of foo(=someglobal) {...}13:44
<bonniot>i think enums and globals should be treated the same, no?
<bonniot>the full qualification is something that is not implemented yet13:46
but i want it in the long term, for package variables and constants, and also for methods13:47
<arjanb>an enumelement is always an unique value but globals not
<bonniot>i think it can be done when the visibility modifiers are implemented
<arjanb>so i don't have problem with = for globals
<bonniot>it is merely a cosmetic aspect13:48
but i think = is not pretty
<arjanb>yes but we get patterns like >value >global name>value in the future13:50
<bonniot>maybe we should only add name>value, because:13:51
is difficult to read (to parse by the reading programmer)13:52
i think function types should also have the possiblility of name parameters13:53
(int number, String name)->void 13:54
<bonniot>yes, it can help documenting the type
so we we agree to get rid of = pattern completely, and to force the default implementation to use the name of the declaration?13:55
<arjanb>i'm not sure because i tend to use shorter names in the implementation than in the declaration13:57
but get rid of = yes13:58
<bonniot>i think we need the second if we want the first
otherwise there is the risk of a typo
you can still use a short name when you use a pattern13:59
<arjanb>ok then i agree
<bonniot>and with functions replaced with methods, you could also put the default implementation with the declaration if you wish
for function types, i think it is possible only to make a small change in the parser, to accept a name and ignore it14:00
<arjanb>it's not simple because of possible ambigueties between that and tuples14:01
<bonniot>ok, but it should only concern the parser14:02
i see: for tuples, the names will be important14:03
<arjanb>and i think named class type parameters are usefull14:05
Map<Key: String, Value: int> someMap = new HashMap();14:06
<bonniot>OK, so i think it is best to wait for the '=' to be removed before releasing 0.9, since it appeared in no previous release
yes, it seems to be useful
<arjanb>'=' can be removed easily without implementing the requirement of name to be the same as in the declaration14:07
<bonniot>true, but i think it should still be done, because there is a dangerous situation otherwise14:09
did you have time to work on the compiler last week?
you must have seen that there were not many commits ;-)14:12
but i had a discussion that provided interesting perpesctives for the long term14:13
principally regarding removing the restrictions of the type system
i have look at the 2 bugreport related to tuples but i didn't see a solution because i'm not familiar with that part of the code14:15
<bonniot>the problem is that when tuples are created, and their component types are type variables, their bytecode type is Object[]14:18
then when their are used, the code knows they should have a more precise type, like String[], and so it inserts a cast, which fails at runtime14:19
<arjanb>array cast are dangerous in java and the jvm14:20
List<List<int>> x = [[3,4,5]];14:23
int i = x[0][1];
this code fails at runtime but i don't understand why it typechecks14:24
int[][] y = [[3,4,5]];
List<List<int>> x = y;
this is not accepted by the typechecker14:25
<bonniot>the second is not accepted because an array of arrays can be view as a List of arrays, but not as a List of Lists14:27
that would be unsafe
because you can modify x, and put a LinkedList as an element, and that would modify y14:28
the first one is accepted because it is safe: you did not store the array in any variable, and thus it still has a polymorphic type14:29
was this clear?15:19
for the first one, it is jsut a problem in the code generation, related to the ones for tuples i think
would you be able to implement the change to remove '=' ?15:20
<arjanb>yes i can remove '=' this evening15:34
<bonniot>ok, great. i will not be reachable most of next week, although I might read emails once or twice16:53
do you have ideas about what todo during that time? do you need help about something?16:54
<arjanb>i know enough things that i can do next week but i haven't questions yet17:05
i could work on patterns\enums\visibility modifiers and i'm rewriting bitvector for speeding up the typesystem17:16
i want to try function replaced by multimethods17:18
when bryn has a preview of the additions of the stdlib i want to experiment with that17:21
i have some ideas for range which i want to try out17:24
<bonniot>ok, that sounds like a lot of good things :-)17:40
i'm going to leave around 6:3018:14
<arjanb>should the check that the name of the default implementation is the same as in the declaration happen during resolving or before18:29
i mean or after18:30
i have to eat now18:34
<bonniot>it cannot happen before, because you don't know what method the implementation is related to18:38
it should happen during resolution, to use this information for resolving, with a good error message if the only problem is a wrong name18:39
bye bye!18:41
* bonniot leaves
* arjanb leaves19:02
* arjanb joins23:44
* Leblin joins00:07
you are the first who isn't listed as developer to come here
<Leblin>Really? wow. well, its my second time here, last time no one was here
Probably because I'm in us pacific time and you two are in europe right?
<Leblin>I'm very interested in Nice. i've even checked out the source to look at it.
<arjanb>:-) only there is not much Nice code in compiler itself yet00:13
but it's useful to look at the nice.lang package source
<Leblin>I know. Only a few sources. Hehe. Is that a current goal to rewrite it all in Nice?
<arjanb>it's a long term goal for the main packages00:14
because converting to Nice cost a lot of time00:15
<Leblin>Nice code is slower than java?00:17
<arjanb>depends on how you use Nice it's currently about 20% slower00:19
<Leblin>That isn't too bad.00:21
Is there any plans to make it possible to dispatch on a class with type parameters?00:23
<arjanb>type parameters are compile time only so you can't dispatch on that00:24
but why do you want to dispatch on them00:26
<Leblin>The problem I am having is that you can't call functions from these methods, since the functions require the type parameters
<arjanb>do you have a little example?00:28
<Leblin>I changed to code that I had problems with. I could create a new example for you.00:30
class A { }00:35
void do_something( List<A> x ) { }
class B<T> extends LinkedList<T> { }
add( x@B, o ) {
do_something( x );
return super;
Arguments (type(x)<java.util.Collection<E>) do not fit: 00:36
nice.lang.void do_something(java.util.List<A> x)
The only workaround I could find is to make do_something a multimethod itself, or make the linkedlist a field of B instead of a parent class.00:41
<arjanb>the compiler is right here you try to apply a List of anything to a list of A00:45
<Leblin>Yes, that is why i asked if/when it would be possible to dispatch on the type parameters. i understand the restriction of compile time.
<arjanb>there is are known bug related to this00:49
class B {}00:50
class A<T | T <: B, B <: T> extends AbstractSet<T> { }
add(a@A, b@B) = super;
this testcase should compile but doesn't typecheck00:51
if i change your example to 00:52
class A {}
void do_something( List<A> x ) { }
class B<A T> extends LinkedList<T> { }
add( x@B, o ) {
do_something( x );
return super;
it should work but doesn't because of that bug00:53
i will add this one to the testsutie00:56
<Leblin>It does complicate things when you know your list is going to operate only on a specific type of object. That is why I chose to make the list of a field of the class instead.00:57
however you lose some flexability this way. your class can't be manipulated as a collection00:58
<arjanb>why is that?00:59
did you encounter other problems recently?01:05
<Leblin>well i suppose you could, however it would more work than if you could subclass
hm. nothing that hasn't already been resolved. you and Daniel are very fast at eliminating bugs01:06
<arjanb>do you have feature request then?01:07
<Leblin>well, one thing that would be helpful is if the compiler outputed more errors before exiting. especially in the typecheck phase it in general will only output 1 error and then exit.01:12
<arjanb>yes that very useful but also difficult because you don't want to get multiple error messages caused by the same problem01:15
<Leblin>i understand your point. errors usually escalate. however nice always recompiles the entire package, and on my 300mzh computer, even a small project can take a while..01:17
<arjanb>how long is a while01:18
I have made some changes to speed up the compiler but i can't help the startup time01:20
<Leblin>it takes about 8 seconds to compile that test case until the error. a project of a few files for a total of a few hundred lines takes about 20-25 seconds01:21
yes i know. the jvm takes a while to start.
<arjanb>there is a wiki page for error messages that need improvements: http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/BadErrorMessages01:26
currently there is no difference between errors that should stop compilation and which shouldn't01:31
this has not a high priority but it should be implemented before 1.001:42
<Leblin>im back. has anyone started on a javadoc style tool for nice?01:50
<arjanb>not yet
the only project started at the moment for supporting the compiler is a Eclipse plugin01:53
<Leblin>i am interested in giving it a stab actually..01:54
<Leblin>my greatest concern would be how to group the information the most. since methods don't belong to a class, you can't group them by class like in javadoc01:56
<arjanb>i think there should be at least 2 views
one file/class based and the other for each method01:57
so if you click on a method name than a page with the method declaration and all the implementations should appear01:59
do you have an idea how javadoc works and what support you need from the compiler?02:02
<Leblin>thats pretty much what i have been thinking
<arjanb>you could put your ideas at a more permanent place: http://nice.sourceforge.net/cgi-bin/twiki/view/Dev/NiceDoc02:04
<Leblin>i'm not completely sure yet.. i haven't given it too much thought in case the project was already being worked on. i would love to write it in nice (expect for the parser)
<arjanb>do you know any opensource javadoc-like tool?02:10
<Leblin>there's doxygen02:13
i find javadoc much simpler and easier to use however02:16
<arjanb>yes but it's useful to look how such things work before you start02:17
one important issue is how dependant nicedoc will be on the compiler02:23
if nicedoc is a library plugged in the compiler it could reuse the parser02:24
another approach is to make a simplified version of the parser for nicedoc02:25
i don't know which is better02:26
you could ask daniel for suggestions02:35
* _Leblin joins03:14
<arjanb>what happened?03:15
<_Leblin>Dialup disconnected. I'm seeing double. Heh. I'm thinking that a simplified version of the parser would be easier to work with, however i'm definately open to suggestion. this would be my first time working on a tool such as this03:16
<arjanb>if needed i can help with the parser part 03:23
<_Leblin>i have some experience with yacc/bison, and i have looked at javacc however i never put it to use
of course, i've looked at Nice's parser too :)03:24
<arjanb>Nice's parser isn't easy to read because a lot of java code is between everything03:29
* Leblin leaves03:33
<_Leblin>Yes I noticed. I was able to read through it, so it isn't that bad.
Its about time I timed out :)
<arjanb>how much is the time difference between where you live and europe?03:46
<_Leblin>I'm not sure. it is currently 6:45 PM03:47
<arjanb>here 3:45 AM03:48
so you have not much changes of finding someone here03:50
<_Leblin>Probably not. I spend little time at the computer during the week (since I work with one all day). that only leaves me with weekends, or holidays such as today.03:52
i found an open source javadoc called doctorJ. it is written in c++, and uses Yacc03:53
<arjanb>yacc is an LR parser generator right?03:56
and Nice'parser is LL so reuse is difficult then03:57
<_Leblin>thats correct. It would be much easier to reuse Nice's parser, at least I would think so04:04
<arjanb>i'm going to sleep now before it gets light04:37
bye bye
* arjanb leaves

Generated by Sualtam