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

Using timezone: Central European Time
* arjanb leaves05:53
* bonniot joins12:50
* arjanb joins14:12
hi daniel14:13
<bonniot>hello14:15
<arjanb>had good vacation?
<bonniot>happy new year!
yes, except the getting sick part!14:16
and you?
<arjanb>quite well
<bonniot>Nice is in Debian:14:19
http://packages.debian.org/unstable/devel/nice
<arjanb>great14:20
<bonniot>what have you been up to?14:48
<arjanb>i have taken some distance from nice for some time and only tried to answer questions and bugs15:31
<bonniot>holidays :-)15:34
that was still very useful that you did that, when I was very little available15:35
are you motivated to look at some things now?15:37
<arjanb>yes15:39
and i have some ideas again15:41
few little things found writing some nice code:15:42
default value of fields depending on previous is needed because you can't use initializer for final fields15:43
<bonniot>right15:44
at the moment you would need to set it at the call site15:45
could you look at the parser to see if expression statements could be restricted15:46
<arjanb>requiring named params at a call of a default constructor of a simple class can be annoying
wdym?
<bonniot>not to include 'f;' '123;' ...
it's a follow up on one of isaac's reports15:47
(agreed, the specification at the call site is just a workaround)
i'm actually surprised the parser accepts it at all15:48
because it should follow Java for such things
<arjanb>currently statement expressions and normal expressions share the same productions15:58
<bonniot>In Jqvq it's:16:01
void StatementExpression() :
* The last expansion of this production accepts more than the legal
* Java expansions for StatementExpression. This expansion does not
* use PostfixExpression for performance reasons.
*/
{}
{
PreIncrementExpression()
|
PreDecrementExpression()
|
PrimaryExpression()
[
"++"
|
"--"
|
AssignmentOperator() Expression()
]
}
<arjanb>this one does allow f; 16:02
i have an idea how to fix this16:06
it seems to work16:22
but many test cases break16:28
and what to do with super;16:32
it doesn't work anymore due to parser changes so should it be super(); and deprecating super; ?16:47
*away for half an hour*17:03
<Bluelive>hi bonniot :)17:19
welcome back
congrats on getting into debian unstable17:20
hwo did tha happen ?17:21
<bonniot>hello bl17:39
<arjanb>*back*
<bonniot>i wrote the deb package myself
and got a debian developer to sponsor it (upload into the debian archive)17:40
<Bluelive>:)
<bonniot>arjanb: super is a keyword anyway, so you can add it to the list of expressions allowed as statements17:41
<Bluelive>now you only need packages for redhat, knoppix, suse and a few more ;)
<bonniot>yeah, but I expect users of these system to do it17:42
we already have a rpm
<arjanb>yes but isn't it more consisting to allow super();17:44
<Bluelive>ive addded something horrible to get super working an alpha :)17:46
super<type>
it was the only way i could think of to specify the correct superclass
<bonniot>i think super with brackets should be reserved for more complex cases where you need to resolve an ambiguity17:47
otherwise it's strange to write super() when the method has in fact arguments17:48
<arjanb>i have now 35 failing testcases of which the half are using new SomeClass(); as statement18:16
<bonniot>we could allow those too: the side effects can be in the initializer18:22
what is the other half like?
<arjanb>like somefield; true; [0];18:30
<bonniot>so these cases could be rewritten18:35
what do you think?
like
let dummy = true;
let dummy = [0];
arjan, did you get a copy of Bryn's iterator library?18:45
<arjanb>some months ago yes18:50
using a constructor call as statement because of side effects in the initializer doesn't sound like a good reason18:51
<bonniot>i agree it looks weird18:57
it's a known style in Java
but maybe we can try to get rid of it
<Bluelive>why are you having troubles with expressions as statements ?18:58
<bonniot>are you interested to see the final version of the nice.functional library?
we try to limit them to catch silly bugs
<Bluelive>you could require them to return void to the statement scope ?18:59
<bonniot>that's going even further19:00
<Bluelive>i intent to have an optional warning flag for that19:03
expressions leaking values usually mean that something should hav ebeen checked
<arjanb>yes, could you forward the final version of Bryn lib19:07
i must change more to allow constructor calls as statement so why not disallow it for now and see whether we get reactions to that19:09
requiring expressions not to leak values has the same (dis)advantages as checked exceptions19:12
<bonniot>ok for now allowing ctor calls19:16
for not ...
<arjanb>about leaving away () for method calls i find it confusing in case of an function object field19:36
class A {
()->void foo = () => println("field foo");
void bar()
{
let a = this.foo;
this.foo();
this.foo()();
let b = foo;
foo();
foo()();
}
}
can you tell without compiling it what happens at each line of bar()?19:37
<bonniot>i think so :-)19:39
the last line is wrong, right?19:40
<arjanb>the last two don't compile19:41
<bonniot>I usually write (this.foo)() instead of this.foo()()
what's the error of the next to last?19:42
<arjanb>D:\Nice\.\testbug\test.nice: line 87, column 5:
foo is not defined
<bonniot>hum, that could probably be handled, no?19:44
<arjanb>i don't know19:45
<bonniot>anyway that's not related to strengthening statement syntax, is it?19:46
<arjanb>no
but i have some doubt with readability of code with the relaxed rules of () or not19:47
<bonniot>so, the syntax change can only help by removing some confusion19:48
<arjanb>right19:49
any idea what this testcases tries to test?21:14
./// FAIL bug
new AWrapper();
./// Toplevel
class A<T> {}
<A SomeA> class AWrapper<SomeA> {
}
<bonniot>yeah, that ther lack of a type parameter for SomeA is deteted21:55
in general, just add 'let dummy = ...' for expressions that cannot be statements anymore
the only trick is if there is an expected failure, it's probably better to explicitely give the type of dummy too, so that a "polymorphic let" error does not concel the expected one21:56
<arjanb>committed22:36
why does it generate some much seperated cvs mails? 22:37
<bonniot>one per directory?22:38
<arjanb>yes
what about making it possible for enums to implement interfaces?22:40
<bonniot>yes, i see no issue with that22:51
<arjanb>could finally implements make sense for enums?23:05
<bonniot>only if the enum type can have subtypes23:15
see you tomorrow23:23
<arjanb>cu
* bonniot leaves23:25
* ChanServ leaves00:13
* ChanServ joins00:17