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

Using timezone: Central European Time
* arjanb joins09:53
* cm_ joins11:07
* bonniot joins11:09
<cm_>hi bonniot, Is all code related to nicedoc in nice/tools/doc and the ant task?11:13
<cm_>Ok, not much :)
<cm_>Is anyone working actively on it?
<bonniot>that's in part because nicedoc uses the components of the compiler as a library to parse and analyse source code. so this part does not need to be duplicated11:19
yes, frank barber
but if you want to contribute, it's surely possible
<cm_>Ok, is the commiting frequently? Otherwise is the risk of conflicting patches quite high11:21
<bonniot>not very frequent11:22
and cvs is made to handle conflicts anyway, so I wouldn't worry about that
on the other hand, it makes sense to coordinate about what you want to do, so as not to duplicate efforts11:23
<cm_>Yes (a syntactic smart diff would however be great)11:24
<bonniot>right. i think that could make a big difference in large projects11:25
you can see the commit history: http://cvs.sourceforge.net/viewcvs.py/nice/Nice/src/nice/tools/doc/?sortby=date#dirlist
<bonniot>what would you work on?
<cm_>In nicedoc?11:27
<bonniot>yes, wasn't that your idea?
<cm_>heh yes. General improvments like those we spoke about yesterday11:28
And improving the layout perhaps11:29
<bonniot>could you subscribe to nice-devel?
or you can read it though gmane11:30
as you prefer
the thing is that there should be coordination about who is doing what, as soon as there is more than one commiter ;-)11:32
<cm_>Yes true. Is it correct that the last message dates from 13 aug in nice-devel?11:33
<bonniot>yes, it seems so11:34
arjan and i communicate a lot on #nice :-)11:35
but reports are also forwarded there, but it seems not RFEs (since frank submitted one recently)
i know frank is working on grouping by source file, so it might not be a good idea to work on grouping at the same time11:43
but i think @hide would be fine11:44
<bonniot>it might be a good idea to pick a higher level keyword, like @optimization?
it could be documented as: "@optimization can be used to tag features that do not modify the behaviour of the program, apart from speeding it up. Therefore, generated documentation can be made to ignore it for simplicity reasons"11:48
it sounds less "sneaky" than @hide
still there?12:59
<cm_>Back from lunhc13:01
Does ClassDefinition.Class contain the doctags?13:02
<bonniot>bossa.syntax.Definition has a field docString13:03
from there it's nicedoc's job, and I don't know how it handles tags13:04
<cm_>Ie parsing the docstring?
<bonniot>that's done inside nicedoc
<cm_>Ahh i got confused as the variable c was refined in a block (was ClassDefinition.Class later Comment)13:07
Is it valid to redefine variables in a subcontext?
<bonniot>no, it's an error
what is the code fragment?13:08
<cm_> if(c.docString() != null) {
comments = notNull(c.docString());
//Note: the comments is deliberately not htmlEncoded because I want people
//to be able to put their own html in the comment.
Comment c = new Comment(commentStr: comments);
<bonniot>is the outer c a field or a local variable?13:09
<bonniot>it should be OK for fields
then it should not be allowed13:10
let me check
right, redefining an argument is not caught yet13:11
<cm_>Ok, it is not valid in Java btw13:13
<bonniot>yes, and rightly so13:14
i'll commit testcases13:23
you should fix the code, so it does not fail when the rule is enforced
<CIA-3>03bonniot * 10Nice/testsuite/compiler/statements/variables/scoping.testsuite: Testcases for multiple definitions of local variables and method parameters.13:25
<bonniot>btw, it's usually a good idea to commit independent changes in different batches13:33
I think that you have define a datastructure that can hold the syntaxtree in memory prior to the doc. generation phase. Something similar to javadoc. 14:01
In order to make it flexible14:02
bossa.* is perhaps sufficient14:04
<bonniot>i think so too14:14
and the great thing is that it cannot get out of date ;-)14:15
<cm_>Is a set of bossa.modules.Package root of everything?14:23
<cm_>Why is eg nice.lang reparsed several times during compilation? (for different targets)14:27
<bonniot>for bootstrap14:28
<cm_>aha ok14:31
<bonniot>but bootstrap is especially twisted as parts of the compiler are in nice and parts in java
<cm_>Ok, but even when compiling nicedoc is nice.lang parsed14:34
<bonniot>it's the compiled version that's "parsed" so it's minimal
<cm_>Ok, I thought that it was the source code.14:35
<bonniot>i agree it's misleading
<cm_>Some string formatting function in nice such as printf?14:52
<bonniot>what do you want to do?14:54
<cm_>To create html strings. Instead of xyz + abc etc15:04
Do nice have varargs?15:05
no need for them if you have concise array literals15:06
do you use java 1.5?15:08
<cm_>Not 1.5, what if a "concise array literals"?15:09
is a15:10
<bonniot>you can skip + if you are mixing string literals and variables15:12
for instance:
<cm_>What is the type of println then?15:14
<bonniot>"<code>"name"</code>" has type String15:15
same as "<code>" + name + "</code>"
it's lighter syntax, and more readable especially if you have syntax highlighting15:16
<cm_>But then you can't interpret individual values?
* arjanb still doesn't like this feature
<cm_>For formatted output, eg "%2.2f"
<bonniot>for this you can use code that does special formating15:18
<cm_>You could however impl. printf as: printf(String, List<Object>).
eg printf("%s, %2.2f",["foo",112.23])
<bonniot>sure, but that's a hack, don't you think?
and weakly typed15:19
<cm_>Yes very weak, you have to improve the type system ;-)
<bonniot>there are ways to type this kind of construct, but i'm not sure it's trying to solve the right problem15:20
<cm_>But pragmatic. The ocaml printf is very crazy. The use introspection with special primitives to go around the type system
<bonniot>i didn't know
<cm_>The -> They
<bonniot>reinforces my feeling that printf is a hack15:21
and I don't think it's especially desirable that you separate the formatting from the values themselves
you need mental gymnastics to map a value to its place in the output15:22
I guess you could implement printf in Haskell as. Formatable a => printf :: String -> [a] -> String
<bonniot>in nice too :-)
but that's still weakly typed
<cm_>How, you can create instances to existing classes in Haskell15:25
<bonniot>yes, in nice too
<cm_>It should be existing types
<bonniot>see the last part of the manual15:26
abstract interfaces
<cm_>ok, checking...
Very nice indeed15:27
I often have the feeling that type systems oppose you.15:33
<bonniot>it shouldn't be like that
<cm_> for ((String key, String val) : arguments)15:36
arguments : List<String,String>
=> syntax error
Should be: arguments : List<(String,String)>15:37
i suppose that case is not handled in the parser
you can use:
arguments.foreach(((String key, String val)) => ...);15:38
<arjanb>right deconstructing a tuple in a 'for' isn't handled by the parser15:40
for ((String,String) pair : arguments) should work15:41
<cm_>Ok, I and arjan discussed this "extra" parenthesis pair a while ago (in the foreach case)
I thing we agreed that those could be removed - generally.15:43
thing -> think15:45
* cm_ cm_ is in desperate need of an irc spell checker15:46
Another problem: If you have the classes: class A { String x; } and class B extends A {}. How to initiate x in B, implicit, without having to define a constructor?15:57
<bonniot>(you'd need a grammar checker for this one, the spelling was correct)
<bonniot>but a function of one argument which is a tuple is not the same as a function of two arguments...
how would you handle that?15:58
for the second question, what's wrong with writing a constructor?15:59
<arjanb>you can do that when it's a final field16:02
class A { final int x;}
class B extends A { override int x = 1;}
<cm_>It seems to a general agreement to constuct instances that way16:04
<cm_>About the tuple case: int a, int b => ... is a function of two arguments and (int a, int b) => .. is a function of a tuple 16:05
First case absent of ()
<bonniot>that wouldn't play well with type inference for anonymous functions, when it is added:16:08
foo(x, y => z);
that would be ambiguous
either foo(x, (y => z)) or foo(x,y => z) 16:09
what you could do is write a version of foreach that accepts a Collection<A,B> and a function of two arguments (A,B)->void16:12
<arjanb>field overrides could be extended to allow default value override of non final fields16:16
<bonniot>yes, i'm only unsure abut the syntax16:17
<CIA-3>03fbarber * 10Nice/web/manual.xml: Added a section explaining the absence of class casting in Nice.16:18
<arjanb>i think yet another syntax construct is worse than reusing override16:20
<CIA-3>03fbarber * 10Nice/web/manual.xml: Added myself to the authors paragraph.16:21
<bonniot>arjanb: yes, but with what syntax?16:22
<arjanb>class A { int x;}
class B extends A { override int x = 1;}
<cm_>About the ambiguity: Why not interpret foo(x, y => z); and foo( (x,y) => z) as a tuple?16:23
The first as foo(x, (y => z))
<bonniot>arjanb: the question is whether to include the type or not
with the type as you need, it's a bit misleading: when looking at B, you can think the type is being specialized16:24
cm_: possible, but that's inconsistent with foo( (int x, int y) => z) *not* using a tuple16:25
sorry, i'm mistaken16:26
the first one is inconsistent with foo(int x, int y => z) as a call with one argument, while foo(x, y => z) is a call with two arguments16:27
i'm afraid it's asking for confusion
don't you like the idea of the new foreach method?16:29
<arjanb>leaving the type away for value overrides looks good to me
<bonniot>yes, it might be the best16:31
<cm_>If think the current syntax is confusing. In haskell you use \ to differentiate lambda expression from values which correspond to explicit typing in nice. Or?16:33
<bonniot>how does that syntax go?
<arjanb>*away for a few hours16:35
* arjanb leaves
<CIA-3>03bonniot * 10Nice/web/manual.xml: Cleanup.16:42
<bonniot>cm_: ?16:44
<cm_>Haskell: \x -> x :: a -> a, Nice: Int x -> x :: Int -> Int16:47
<bonniot>ok, i see
\ is already taken though16:48
<cm_>My point was that you have a explicit syntax to express lambda expression in Nice too. <Type> x -> ...16:50
ie no ambiguity in foo(x, y => z)16:51
a mean, foo(x, <type> y => z)16:52
I mean
<cm_>Hmm In haskell you write: f (\x -> x) so that could correspond to f (x, (int x -> x))
Should be: f x (\x -> x)16:54
<bonniot>but I would like the explicitly typed and inference versions as close as possible (just not mention the type)16:55
<cm_>Redundant syntax is not my cup of tea :-)
<bonniot>and the current notation is consistent with the fact that method parameters are listed inside (...)
i guess it's the f(x) vs (f x) syntax debate16:56
<cm_>Yes, not to mention the lisp syntax :-)16:57
class A {16:59
A() {}
A is not declared
What is the problem with this?
<bonniot>that's Java syntax ;-)
new A() { this(); }
at the package level
that would only be useful if your custom constructor has args, though17:01
<cm_>First: new A() { this(); } => 17:04
Ambiguity for symbol this. Possibilities are :
nice.tools.doc.A <init>()
nice.tools.doc.A <init>()
Second: new A() {} => Syntax error
<bonniot>yes, you need args
otherwise there is ambiguity with the default constructor
and a custom constructor needs a call to this17:05
<cm_>Strange though the the second results in a syntax error.
<bonniot>and a custom constructor needs a call to this17:06
i guess
what's the error?
<cm_>Encountered "}".
Was expecting one of:
I would vote for a semantic error ;-)
you should submit a RFE, or better add this on the wiki page about better error messages
<cm_>Yes but you would have to change to grammar so it accepts empty statments in constructors17:13
<bonniot>yes, i'm aware of that17:15
<cm_>Little strange that methods and constructors don't share a common reduction rule - or?
<bonniot>the 'new' part is also specific17:16
looking at the def, there is simply a + for the list of statements, so that at least one is expected17:18
so that should be easy to improve
<cm_>[ LOOKAHEAD(ExplicitConstructorInvocation()) ExplicitConstructorInvocation() ]17:20
This one I guess
<bonniot>he, where does that come from?17:21
<cm_>From ConstructorDeclaration()
<bonniot>you're looking at the Java grammar
<bonniot>no, it's Parser.jj, line 1138
<cm_>What is the nice syntax file called?
+ -> * perhaps?17:23
only maybe some code assumes that the list cannot be empty, so it should be checked that it fails gracefully17:25
i'll leave in a few minutes and be away for the evening17:33
<cm_>Nullable types :-)17:39
<cm_>Such that you have to check that statment isn't null17:43
Aha you meant empty. If thought that it could be null17:44
<bonniot>you know that Nice has type-safe handing of null, right?17:45
(in this case it does not apply because that code might still be writte in Java)17:46
<cm_>Yes, that was my idea. Great feature btw.
Isn't it called nullable types?17:48
<bonniot>depends by whom ;-)17:49
they are called option types in the manual
ok, see you later17:50
good luck!
<cm_>True, thanks, later.17:58
* cm_ leaves19:50
* arjanb joins21:17
<CIA-3>03arjanb * 10Nice/src/bossa/ (parser/Parser.jj syntax/tools.nice): Give semantic error on empty custom constructor.23:23

Generated by Sualtam