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

Using timezone: Central European Time
<bonniot>so exp local vars are finished?01:24
<arjanb>yes it was just another stupid mistake
<bonniot>and don't you think some duplication could be avoided?01:30
typecheck for ExpLocalVar seems mostly the same as for Block.LocalVariable01:31
<arjanb>not sure if the total amount of change can be reduced01:36
<bonniot>but there is duplication atm, isn't there?01:45
<arjanb>yes01:46
<CIA-3>03arjanb * 10Nice/src/bossa/parser/Parser.jj: Made switch an unused keyword to improve the parse error message.
<arjanb>did you find the cause of malformed attribute?01:49
<bonniot>basically yes, and i'm investigating solutions01:51
not sure i will commit tonight, though
<arjanb>the wiki is getting busy02:16
<CIA-3>03arjanb * 10Nice/ (2 files in 2 dirs): Fix compilation of multiple exp local vars.02:25
<bonniot>yep, it's busy :-)02:26
and nice-info has good discussions too...02:29
<CIA-3>03bonniot * 10Nice/src/nice/tools/util/source-lines.nice: Get the source line number right in limit cases.02:43
<bonniot>good night02:56
* bonniot leaves02:58
* arjanb leaves03:40
* rubber joins08:58
Hello...
* rubber leaves09:02
* rubber joins09:03
* bonniot joins09:21
hi09:32
hello rubber!
<rubber>Hello... :)
<bonniot>how are you doing?
<rubber>I have to leave for a cup of coffee... CU in 15 minutes...
Thnx.... Becoming awake now :)
<bonniot>:-)09:33
<rubber>CUS
<bonniot>?
<rubber>CUsoon(15 minutes)09:34
<bonniot>ok09:35
<rubber>please have a look at the mail I sent...
<bonniot>i shall
<rubber>back09:58
<bonniot>i sent an answer to your message09:59
btw, are you changing your nick?
<rubber>Well, GummiEnte is a already registered Nick... It is also "only" my german translation for me original nick... It comes from rubberduck, but to be short, I often/mostly use rubber.10:01
rubber is now registered.10:02
<bonniot>ok10:03
<rubber>arjanb is not registered btw...
<bonniot>somebody else chose GummiEnte? isn't that surprising?
how do you tell?
whois10:04
<rubber>well, a sideeffect. I played around with /msg memoserv and wanted to send arjanb a memo..., but that didn't work, cause arjanb isn't registered.
whois is a must, to check, that the users have identified...10:05
you could make the core developers channel ops, if they are registered... (through chanserv)10:06
<bonniot>i see you studied freenode :-)
<rubber>Well, these bots are laying around on most irc net's...10:07
<bonniot>did you get any notification?10:10
<rubber>About what?
<bonniot>msg chanserv access #nice list
<rubber>no...10:11
<bonniot>so you are op now :-)10:12
<rubber>Am I?10:13
Let me rejoin, maybe I'm then...
* rubber leaves
* rubber joins10:14
<bonniot>what it means is that you can become op if you need to10:17
by default nobody is op
<rubber>ok, so no autoop... :) Good
Ok.10:19
How to use NiceClass from an SymbolExp?10:21
I can get a VarSymbol, but what to do with it?10:22
<bonniot>i think you want:10:25
SymbolExp.getFieldAccessMethod
this can return null if the symbol is not a field
otherwise a FieldAccess10:26
if that's a NiceFieldAccess, then you have the "field" field (!)10:27
otherwise it's an access to a field declared in Java
JavaFieldAccess
that one has already isFinal() and isStatic, you probably want to add isVolatile()10:28
<rubber>:)
<bonniot>you could also add accessors to FieldAccess, with different implementations for NiceFieldAccess and JavaFieldAccess10:29
that could allow you to use them uniformly
that's up to you
<rubber>What's the difference between a nice class and a java class?10:31
Ah, ok... I see already.10:32
<bonniot>depends if they were declared in a Nice source or not10:36
<rubber>maybe we should add functions for all access states?10:37
Not only static, final and valatile, but also transient, synchronised, ppp, native? ?10:39
<bonniot>i usually do that on demand only. if we can keep those details internal, it's all the better, don't you think?10:42
<rubber>Depend on in which part you are developing.10:44
<bonniot>can you explain?10:45
<rubber>Well, I tighten the "most" outer interfaces to only the things needed, but internally in the middle and base parts, I give myself the most possible freedom.10:47
You use 2 blanks as tabs?10:48
<bonniot>indents are of size 2 blanks10:50
but the TAB char is 8 spaces
yes, but what is middle or base part might be outer for another project10:52
<rubber>I would like to add at least isVolatile and isTransient, cause these are the only attributes that are left to be recognized...
<bonniot>ok
<rubber>synchronized is missing at the moment...
<bonniot>a field cannot be synchronized10:53
<rubber>Ah, yes, I mixed it together with synchronized(field) { ... }10:54
An overriden field is final, non-volatile and non-transient, right?10:58
<bonniot>yes, only final fields can be overriden11:01
but I suppose volatile and transient are irrelevant, it could be either on or off
<rubber>What do you suggest?11:02
<bonniot>aboiut what?
<rubber>turned on/off?
<bonniot>what i mean is that both cases will happen11:03
<rubber>...for OverridenFields???
<bonniot>it depends on the user source
so, it would be the same as the original field11:04
<rubber>So, the volatile/transient attribute is inherited from the overriden attribute?
<bonniot>(overriden fields do not appear in the bytecode, they are just there for typing)
yes
<CIA-3>03bonniot * 10Nice/ (2 files in 2 dirs): 11:18
Avoid infinite recursion when dealing with ambiguity between several global
variables.
<rubber>Is the following allowed for OverridenField:11:25
boolean isTransient() {
Field f = null;
NiceClass parent = getParent();
if (parent != null)
f = parent.getOverridenField(this, value == null);
if (f == null)
throw User.error(sym,
"No field with this name exists in a super-class");
return f.isTransient();
}
Isn't it already possible to store the overriden field at instantiation time?11:26
getOverridenField does now return a Field instead of the Declaration...
<bonniot>i don't think you can do it at instantiation time11:27
because the original field might be below in the source
so it's not even parsed yet
<rubber>but when we call isTransient it should work, should'nt it?11:28
<bonniot>yes, it should, or you'll have to make it so :-)11:29
<rubber>:)
To run the testsuite simple run make test?11:33
<bonniot>make test for the old one, and make check for the new one11:35
make check test for both
<rubber>Ok.
<bonniot>do you have working code?
<rubber>Yes, I hope...11:36
<bonniot>great!11:37
could you write your own testcases?
<rubber>I haven't done up to now...
...haven't had a look at the syntax.
<bonniot>the new one is inside testsuite/compiler11:38
that's the one you should use
* bonniot is away: 15mn11:43
* bonniot is back (gone 00:21:01)12:04
* arjanb joins12:12
<rubber>hello arjan12:15
b(this) <-- this is a call to get the field b?
<bonniot>hello arjan
yes, just like this.b12:16
<arjanb>hello
<bonniot>a.foo(b) is syntaxtix sugar for foo(a,b)
a.foo() is syntaxtix sugar for foo(a)12:17
a.foo is syntaxtix sugar for foo(a)
"syntaxtix" sounds like a name in an Asterix comic strip :-)12:20
<arjanb>rubber: what memo did you want to send me?12:21
it's syntactic i think12:22
<rubber>:)
<bonniot>yes i know, it was a typo :-)
<rubber>arjanb: I was just playing around.12:23
<arjanb>i see
<bonniot>in french it's "syntaxique", so that's confusing...
<arjanb>i'm registered now
<bonniot>you didn't see this: [arjanb] has been added to the access list for #nice with level [20]12:25
?
<rubber>I did not.
<arjanb>nope12:26
<bonniot>now you did :-)12:27
it probably only notifies the user making the modification12:28
arjan, any plans?12:30
<arjanb>no12:31
<bonniot>it would be good to look through the open bug reports12:33
you already fixed switch
<arjanb>these open bug reports are nothing for me12:41
1,2,6 are hard 3,7 are design issues/RFEs 4,5,8 are typing things so for daniel12:43
<rubber>:)12:44
What is a LowlevelRigidClash?12:50
<arjanb>some type error12:51
<bonniot>it happens when a subtyping does not hold12:52
for instance in:
<arjanb>what are you making?
<bonniot>int x = "foo";
you will have a clash between String and int
why?
arjanb: why Postponed?12:54
<arjanb>because it's not an important bug and i don't see an easy way to solve it12:57
<rubber>Well, I thought it is enough setVarType(variable, now: sureType, otherBranch: type); to an sure type, but that ended in an: mlsub.typing.lowlevel.LowlevelRigidClash: Clash (nice.lang.Maybe[0]<:nice.lang.Sure[1])12:59
<bonniot>arjanb: why is it not solved already, now that switch is a keyword?13:01
rubber: that shows that the value has still a ? type
is the statement executed at all?
<rubber>Monotype leq: ?com.S <: com.S this causes the clash13:02
com.S is the example/test...
Arguments (?com.S) do not fit:
nice.lang.void g(com.S this)
<bonniot>yes, the value still have the ? type13:03
<arjanb>daniel: i thought you were talked about the outofmemory but for switch i think i accidentily hit the scrollwheel or something
<CIA-3>03bonniot * 10Nice/ (2 files in 2 dirs): 13:07
Make sure that constructors imported from compiled packages are available early
enough for all uses.
<rubber>It isn't sufficient to set the monotype of a monosymbol in the case of a class field, right?13:35
<arjanb>not sure if the field has a type variable
<bonniot>it might be the SymbolExp whose type you need to change13:36
<rubber>But in the case of b(this) this is no SymbolExp but a CallExp; so the same holds for CallExp?13:38
<bonniot>well, it's a CallExp whose function is a SymbolExp(b)13:39
<rubber>ahh, the function gets called, right?
<bonniot>wdym?13:40
b(this) is represented as CallExp(function: SymbolExp(b), arguments: [SymbolExp(this)])
<rubber>Just to understand the cohesions...
<bonniot>(in pseudo-code)
is that clearerM13:41
?
<rubber>Yes.
<bonniot>hum, but each use will have a different CallExp and SymbolExp object13:42
so what you could change is the Symbol of the FieldAccess13:43
that's a PolySymbol, not a MonoSymbol13:44
wait, that would be wrong13:49
if (this.b != null)
foo(that.b);13:50
it's not b itself that's guaranteed to return non-null values, it's the combination "this.b"
<rubber>yes.13:51
and this.b is 'CallExp(function: SymbolExp(b), arguments: [SymbolExp(this)])' ?
<bonniot>yes13:52
but each occurence is represented independently, naturally
<rubber>but CallExp is reused with different parameters?13:53
<bonniot>not the same instance
<rubber>Ok.
<bonniot>maybe it's wrong to focus on fields13:54
the point can be generalized to arbitrary complex expressions
(with properties, it's not even clear what is a field and what is not)13:55
e.g.
if (System.getProperty("foo") != null)13:56
useFoo(System.getProperty("foo"));
<rubber>isn't it the same e.g. with if (f.g != null) { // now f.g is still ?null ... } ?
<bonniot>the same between what and what?13:57
<rubber>between our problem now, that it is no local variable but something more general...13:58
<bonniot>don't understand that sentence14:03
<rubber>class A { ?B b = null } let g() => { A a = new A(); if (a.b != null) { // now we still only have ?B }}...
Me too.
<bonniot>the one you wrote? ;-)14:04
<rubber>:)
<bonniot>so, what i'm saying is that fields are just a special case
the general case is:
if (<complex expression> != null) { ... <same complex expression> }14:05
<rubber>and what to conditions must be fullfilled, so that we can guarantee, that the second complex expression is still != null?14:06
<bonniot>well, one solution (same as for fields) is to copy the value in a local variable14:07
<arjanb>the only case is final fields
<bonniot>but I think it would make sense at least to require that the expression elements are constant
arjanb: yes, but with properties this would expose implementation details14:08
<rubber>would'nt it be possible to create a new syntax element, that would create such local copies?
...for arbitrary elements/results?14:09
<bonniot>that's expression local variables
<rubber>right... :)
<bonniot>if (let x = foo.x) { use(x); }
if ((let x = foo.x) != null) { use(x); }
but that's still not too friendly, is it?14:10
that wouldn't even work in the current implementation, x is out of scope in the body
<rubber>?
ah, ok.14:11
<bonniot>use(x); // x is not visible here
<rubber>but I assume, this would be nice, if.
<bonniot>if what?
<rubber>and therefore you even could create syntactic sugar....
<bonniot>like?14:12
<rubber>if 'if ((let x = foo.x) != null) { use(x); }' would be possible....
WEll, what would be short enough...?
<bonniot>people expect
if (this.x != null) use(this.x);14:13
to work
<rubber>yes, like me too.
<bonniot>(without the explicit this, it's even more surprising that it does not)
given that this.x might actually represent a property, which could return randomly null and not null, it seems unavoidable to store the value in an implicit local cariable14:15
variable
<rubber>yes, but doing that would change the semantics?...14:16
<bonniot>yes and no
<rubber>exact.
<bonniot>no, because the JVM spec already allows a JVM to do that (for fields)
<rubber>so, should'nt the user have the choice which semantics to use?14:17
What does the JVM?
<bonniot>and it's arguable that this semantics make sense
<rubber>it creates a local copy?
<bonniot>the JVM does what it wants, as long as it respects the spec :-)
<rubber>ah, yes... if is not volatile, right?
<bonniot>yes
<rubber>:-)))
So, at the moment nice does the correct semantics.14:18
<bonniot>giving a choice of semantics might be very confusing
<rubber>ok, so we come back to another syntax.
<bonniot>there is no "correct" semantics
<arjanb>but what if you have a local copy and you call some method that changes that field?
<bonniot>Nice is a source compiler
JVMs execute bytecodes14:19
<rubber>aeh, yes.
<bonniot>arjanb: then the values differ. that's already possible in Java (if they are in different threads)
<arjanb>but that can happen in a single thread
<bonniot>yes14:20
<rubber>how?
ah, I get an example.
<bonniot>if (this.x != null) { changeX(this); use(this.x); }
<rubber>So what? we need a runtime typechecker?14:26
(just kidding)
<bonniot>:-)14:27
so, it's completely safe to work with the copy, the question is whether the semantics is good or bad14:28
or it's possible to impose further restrictions
<rubber>but, if working with the copy, then your example still might throw an NPE?14:29
<bonniot>no
use is called with the value of the copy
<arjanb>i'd rather let the compiler insert assertions like notNull instead of making local copies14:30
<rubber>ok, but what if you add 'this.x = ?fun();' // pseudo ?...
<bonniot>arjanb: that would be unsafe
rubber: wdym?14:31
<rubber>how could the compiler keep track of an arbitrary result from fun(). Does it reset the nullness info to maybeNull?14:32
if so, ok.
<bonniot>yes, it would reset the info14:33
that's already done for local variables
<rubber>ok. then this would be nice. but is it pratical?
<bonniot>i think the semantics makes sense, at least under certain circumstances
for instance when you say "if the sofa looks comfortable, sit on the sofa"14:34
<rubber>;)
<bonniot>you don't mean that if somebody put a different sofa in the meantime, you sit on that one
you mean the same sofa :-)
rubber: what would be the practical problem?14:35
<rubber>aeh, wrong... is it possible to implement...
<bonniot>yeah sure. it's quite similar to local variables, just a bit more complex14:36
<rubber>...should have been my question.
<bonniot>i agree that the semantics is questionable, there should probably be some restrictions
<rubber>(implementation times: bonniot: 1 day; arjanb: 1,5 days; rubber: 1 year) ?14:38
<bonniot>:-)
<arjanb>maybe some function modifier that garantees that the return value only depends on the argument values
<bonniot>i don't think so, you seemed to be going quite well so far
arjanb: yes, that could be14:39
only i'm afraid it would be a pain to declare, and so not used enough
and that doesn't deal with changeX(this)14:40
that could be taken care of by a 'const' modifier
wait, back to final fields14:41
properties also can be final (e.g. there is only get)14:42
so maybe we could start with implementing inference for final fields, then extend it to read-only properties when there are implemented14:43
one would still need to copy non-final fields, but that would be a step (and encourage people to use final fields, which is always a good idea)
hum?14:44
<arjanb>i agree with doing only final fields to start with
<bonniot>works with <constant expression>.finalfield14:45
where <constant expression> ::= constant local variable | <constant expression>.finalfield
no
<inferrable expression> ::= local variable | <inferrable expression>.finalfield14:46
and we take care of assignments to local variables to reset the inferred type
like this it is a generalization of the current implementation
makes sense?
<arjanb>yes14:48
<bonniot>rubber: ?
<rubber>yes, that would be a good start...14:50
<bonniot>and now it's better specified than it was
:-/
<rubber>Why :/
<bonniot>i think we are back to the same point for the implementation14:51
well, i'm sorry it was not clearer from the start
<rubber>class S {
void g() {}
}
class A {
final ?S b = new S();
void t() {
}
}
Once again:14:52
class S {
void g() {}
}
class A {
final ?S b = new S();
void t() {
}
}
??? Sorry...
class S {
void g() {}
}
class A {
final ?S b = new S();
void t() {
if (b != null) {14:53
g(b);
}
}
That should work after all..., right?
<bonniot>right :-)
<rubber>one } missing.
<bonniot>the no :-)14:54
then no :-)
<rubber>why doesn?t work the followin:
class S {
A a;
}
class A {
S s = new S(this);
}
I haven't encountered this, but just now by accident.
<bonniot>new S(a: this);
isn't that what the error message says?14:55
<rubber>~/Work/WorkingDirectory/e3m-debugg/src/com/test.nice:9:27:
this is not declared
<bonniot>ah ok
yes, this is not implemented
<rubber>Ok, I thought, there is a reason, I did not see.14:56
<bonniot>wait
that's a recursive use of this
that could be unsafe14:57
:
class A {
S s = new S(a: this);
String s = "foo";
}
class S {
A a;
// Initializer
{ int i = a.s.length; }14:58
}
s (the String) would not be initialized yet
NPE
(the two fields should have different names, sorry)
get it?14:59
<rubber>Yes, but what about the following:15:00
class S { String s; } class A { final ?S s = new S(s: this.b); String b = "b"; }
Error: "this.b is neither a valid expression nor a valid package15:01
Their is now recursion, and I assume this is what you mean is unimplemented?15:02
<bonniot>no, i said that before i realized the recursion
this is the same case
what would be "this" ?
<rubber>Also recursion?
Well, if I remind correct, what Sun does, it is the new generated class?15:03
<bonniot>well, that "this" is not available, because it's not ready yet
your example would NPE, (well, put null into s.s)
the construction rules in Java are completely unsafe15:04
it's not what you want that s.s has value null, right?15:05
that's what would have to happen if this was allowed15:06
<rubber>class Test 15:07
{
String g = "g";
Test2 t = new Test2(this.g);
public static void main(String[] args)
{
Test tttt = new Test();
System.out.println(tttt.t.s);
}
private class Test2
{
String s;
Test2(String s)
{
this.s = s;
}
}
}
That works anyway... But I admit, it might be unsafe.
well, if I look at the examples... why was it unsafe?15:10
recursion is clear to be unsafe...15:13
<bonniot>in your example you put g before t, while it was afterwards above15:17
also, it might work for simple values like String, but break with other cases (a new instance)
<rubber>Uuups... 15:18
<bonniot>it's unsafe because you assume the other field are already initialized
<rubber>That was not knowingly...
<bonniot>OK :-)
you could even have a case of mutual dependency, so that it clearly cannot be done15:19
<rubber>I thought Sun would have resolved all "dependencies"...
Yes, that would be possible.
I'll have to look at the Wiki about the CC's... 15:20
But Ok. We are right at the beginning ;)
...beginning of our implementation problem...15:22
<bonniot>i think in Java the fields initializer are just executed in order of appearance15:27
arjan, wouldn't you look at using reflexion for getStackTrace so that we can build on JDK 1.3 again?15:44
<arjanb>i can try15:46
<bonniot>thx15:48
<arjanb>cvs down again?16:25
what's a easy way the trigger usage of that getstacktrace thing?16:26
<bonniot>add 'throw new Error();' anywhere inside the constructor16:46
inside the compiler
for instance in AST.java
<CIA-3>03arjanb * 10Nice/src/nice/tools/util/source-lines.nice: Use reflection in printStackTraceWithSourceInfo.17:05
<rubber>I have to go now. My sister has problems with her PC and needs help... :)18:01
We'll see us tomorrow...
bye
* rubber leaves
<bonniot>arjan, do you know why the "complete" example is empty in nice-swing?18:23
<arjanb>no18:24
what are your plans with syntax changes like "let" and "->" for closures?19:12
<bonniot>not sure yet19:14
i suppose what should be done is to set up a page about those changes and ask for opinions19:15
syntax changes are very subjective
so it matters a lot how people feel about them
<arjanb>true but waiting long isn't a good idea19:17
<bonniot>yes19:18
but i think there is time to ask people and wait a few days :-)
do you want to setup the page?19:37
<arjanb>started but not a good writing day today19:40
<bonniot>ok, thx19:47
Bryn or me might help later ;-)
i'm working on improving the maven plugin atm19:49
<CIA-3>03xoltar * 10Nice/web/manual.xml: Minor corrections.20:08
* bonniot leaves22:31
* bonniot joins22:38
* bonniot leaves22:39
* bonniot joins23:51
/msg MemoServ LIST23:56

Generated by Sualtam