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

Using timezone: Central European Time
* CIA-5 leaves00:26
* CIA-5 joins
<arjanb>good night01:47
<bonniot>good night01:48
* arjanb leaves
* bonniot leaves02:48
* arjanb joins10:32
* bonniot joins11:49
<arjanb>good morning11:54
* CIA-5 leaves12:02
* CIA-5 joins
<arjanb>i listened to a talk(mp3) about the antlr 3 internals and now i want to have it for sure12:04
<bonniot>:-)12:26
<arjanb>what are you working on atm?12:29
i don't know what to do next..12:30
<bonniot>I have a bug for subclasses with less type parameters to fix12:33
and i'll look a the field overrides12:34
it would be good to implement the constructors that use field assignments12:36
do you think you could do it?
<arjanb>i will take a closer look12:39
<bonniot>this should be the typical testcase:12:41
/// PASS
let b = new B("xx");
assert b.a == 1 && b.b == 2;
/// Toplevel
class A { int a; }
class B extends A { int b; }
new B(String s)
{
x = s.length;12:42
super(a: 1);
}
agreed?
sorry, should be 'b = s.length;'
<arjanb>this or super as last call?12:43
<bonniot>super, because all the fields of this have already been assigned
actually we could as well allow super to be called first, it should not matter12:44
the simpler is without a superclass:12:45
/// PASS
let b = new B("xx");
/// Toplevel
class B { int b; }
new B(String s)
{
b = s.length;
}
that's what was discussed on nice-info12:46
/// FAIL12:47
/// Toplevel
class B { int b; }
new B(String s)
{
}
<arjanb>what about requiring this.x = ... for the field assignments?12:48
<bonniot>that can be a first step if it helps, yes
is it for the design or the implementation?
<arjanb>both12:49
<bonniot>i don't mind at this point. I suppose omitting this should be allowed though because it's already the case in the rest of the language12:50
there is a point for explicit this, but we are already introducing a new mechanism for construction, and that's what really matters12:51
<arjanb>i think all custom constructor should have a call to this(not super) and only at the end because of initializers12:53
<bonniot>the initializers must be run at the end, that's granted12:55
but currently the call to this is required to pass the values of the fields. if the fields are assigned, there is no need to write this() at the end
<arjanb>i think assigning fields in custom constructors is odd13:09
i prefer the syntactic sugar only variant:13:10
new A (...) {
this.y = ...
this.z = ...
this(x: ...);13:11
}
becomes
new A ( ... ) {
this_y = ...
this_z = ...
this(x: ... , y: this_y, y:, z: this_z); 13:12
}
<bonniot>isn't that equivalent to:
new A(...) {13:13
this(y: ..., z: ..., x: ...);
}
?
<arjanb>almost but it makes a difference when you assign a field in 2 branches of an if13:14
<bonniot>if you allow that, then I see no difference with my proposal13:15
(appart from the this prefix, which is another question)
<arjanb>class A { int x; int y; }13:20
new A (...) {13:21
this.x = ..
this(y: ...); // error no constructor or must generate a additional one13:22
}
<bonniot>you want to allow this?
that? ;-)
<arjanb>don't know, just thinking about what should happen in such a case13:23
<bonniot>i think this is a mixture of two styles, not very elegant13:24
<CIA-5>03bonniot * 10Nice/src/bossa/syntax/NiceClass.java: Cleanup.13:35
<arjanb>this needs some more thought13:42
<bonniot>i fail to see the big problem13:43
<arjanb>when directly assigning fields and calling another CC will problably cause these fields to be overwritten
<bonniot>yes, that should not be allowed
that's why it's a super call that must be made13:44
<arjanb>and i'm worried about the interaction with another feature i want: default values depending on previous fields
<bonniot>super will not overwrite the fields since it does not know them
that's a good feature too13:45
but there is no interaction, since the default values are only used when calling this(...)
ok, there could be one if you want to allow the constructor to omit the values of fields with default ones13:46
so it might be a good idea to start with implementing fields which depend on previous ones13:47
<arjanb>that's not an easy one13:51
<bonniot>well, either one has to be tackled first, then we will have a clearer idea14:12
i don't think there is a fundamental problem14:13
<arjanb>btw what's the order of evaluation of function arguments?14:21
<bonniot>left-to-right14:22
<arjanb>void foo(int x, int y) {14:23
println("x: "+x+" y: "+y);
}
int i = 3;
foo(y: i, x: ++i);
prints: x: 4 y: 414:24
<bonniot>ok, it's left-to-right for the declaration order :-)14:26
that's bogus, but i don't think it's critical14:27
<arjanb>i will commit a testcase, just in case we run out real issues to improve14:33
<bonniot>right
<CIA-5>03arjanb * 10Nice/testsuite/compiler/methods/namedParameters.testsuite: Testcase for order of evaluation of named arguments.14:45
<arjanb>;-)
<CIA-5>03bonniot * 10Nice/ (2 files in 2 dirs): 14:52
Fixed field type override checking when there is a value override higher up
in the hierarchy.
<arjanb>isn't that a different solution than discussed yesterday?15:21
<bonniot>it is :-)15:22
<arjanb>why?
<bonniot>it's safe like this15:24
is there a reason to change it?
<arjanb>no but you proposed another solution yesterday15:26
* CIA-5 leaves
* CIA-4 joins
<bonniot>yes. i don't have a strong opinion on this, so we can wait for feedback on this15:28
* CIA-4 leaves15:35
* CIA-4 joins
<bonniot>btw, who was it who was asking for an interpreter?15:44
<arjanb>i think pitecus15:45
<bonniot>I found back an embryo of Nice interpreter that I send to somebody some time ago16:01
if somebody is interested, it could be a good starting point
<arjanb>what do you think of implementing tuples with classes instead of arrays?16:30
<bonniot>wht for?to avoid casts?16:31
<arjanb>for being able to dispatch on them and for speed16:32
<bonniot>it's not clear if it would be faster, because loading a new class is expensive16:33
and in general this does not look like a priority
<arjanb>loading a new class, how do you mean?16:35
<bonniot>loading a new class in the JVM
<arjanb>you need only a few16:36
<bonniot>with fields of type Object? then why would it be faster than arrays?
<arjanb>yes i tried that it still seems faster16:37
<bonniot>how much?16:38
<arjanb>classes don't have bound- and store- checks
~13s for arrays ~9s for tuples16:39
<bonniot>not bad16:40
<arjanb>i swapped in a loop the values of a 2-tuple
<bonniot>with what types?
<arjanb>(String, String) pair = ("abc", "xyz");
for( int x = 100000000; x >= 0; x--)
{
(String a, String b) = pair;
pair = (b, a);
}
Tuple2<String, String> pair = new Tuple2(first: "abc", second: "xyz");16:41
for( int x = 100000000; x >= 0; x--)
{
String a = pair.first;
String b = pair.second;
pair = new Tuple2(first: b, second: a);
}
<bonniot>trying...16:46
<arjanb>class Tuple2<T, U> {16:48
final T first;
final U second;
}
<bonniot>uh, arrays seem much faster...16:50
<arjanb>which jvm are you using?16:51
<bonniot>1.4 and 1.516:53
<arjanb>with -server?
<bonniot>no
yes, with -server it's the opposite16:54
so it depends ;-)
<arjanb>and this simple test has the risks of being jitted away..16:55
<bonniot>if it was it would be much faster, no?
<arjanb>yes16:56
* pitecus thinks an implementation of a programming language with an interactive interpreter is twice as "nice" as one without.16:57
<bonniot>pitecus: do you want to have a look at the prototype?16:58
<pitecus>bonniot, sure
<bonniot>what OS do you run?
<pitecus>mandrake linux
<bonniot>ok, so a Makefile is fine,16:59
?
<pitecus>sure
<bonniot>how should I send it?
<pitecus>if you have nowhere to upload it you can just attach it to an email for grzegorz@pithekos.net17:00
<bonniot>sent17:02
<pitecus>thanks
<bonniot>it's not very useful in itself, but it provides an evaluate(String) method17:03
<pitecus>that's a start
<bonniot>so with a bit of work it could read commands and interpret them17:04
it's a quick hack, but it could already serve a purpose
for better performance or for semantic reasons, it could be possible to plug it into the compiler at a higher level17:05
<pitecus>Well if all you want is an interactive shell, performance is not a big issue.17:07
<bonniot>sure
i'm more thinking of latency
<pitecus>yup17:08
Oh, I see you call it cute :)17:09
<bonniot>nice and small ;-)
(it's just an idea)17:10
pitecus: you'll need to set nice_home in the Makefile17:16
<pitecus>yeah done that. After running make is said: Still a bit slow...
... but OK after warm up!
<bonniot>correct17:17
<pitecus>so how do i eval stuff?
<bonniot>as I said it just implements the eval(String) method
so for a real interpreter you'll need to implement the part that read on System.in and passes that to the eval method17:18
<pitecus>OK time to write my own REPL.
<bonniot>right
probably there are some good libraries out there to do line input, history, etc...17:19
<pitecus>That's not essential. You can run it under rlwrap, or emacs or something.
<bonniot>true17:20
<pitecus>Repl would be easier if nice didn't have statements, so evaluate could always return a value. Another argument against statements :)17:32
<bonniot>to print the value of expressions?17:33
<pitecus>yes. If eval always returns a value, you can just print it. I'm sure your familiar with how Lisp or ML or Ruby interactive shells work. They always print the result of evaluating the expression the user types.17:36
<bonniot>right
some expressions return void, so it's not very different from a statement17:37
<pitecus>With cute, the user will have to use println explicitely to see the result
<bonniot>no, you could make it print the value if there is one
<pitecus>hm i'm probably looking at the wrong method then. 17:38
void evaluate(String statements)17:39
<bonniot>right, at the moment it doesn't
i'm just saying it's possible
<pitecus>I, OK I misunderstood.17:40
* bonniot leaves20:13
* bonniot joins22:56
<arjanb>in the parser the 'implies' operator is still commented out23:44
that remembers me that the syntax of anonymous functions hasn't been decided23:46
it's getting time to pin down the syntax before 1.0 (with exception of additions)23:52
another issue is the new keyword00:19
<bonniot>i was wondering if -> for anonymous functions would cause ambiguity problems with functional types00:40
<arjanb>javaCC didn't find one00:45
i don't have any problem with the current syntax of anonymous functions00:46
and i find `->` for implies good enough00:51
for the new keyword i think making it optional is better than removing it because many are used to it00:53

Generated by Sualtam