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

Using timezone: Central European Time
* arjanb leaves00:11
* arjanb joins11:25
* bonniot joins12:10
<arjanb>hi12:15
<bonniot>hi
<arjanb>i was thinking about how to translate static methods to Nice12:17
and i think we are missing a way to arrange them12:19
<bonniot>methods belong to a package12:21
so that's a way to arrange them
that will be reinforced when we allow to fully qualify methods12:22
<arjanb>well a few more observations:12:28
in java classes are scopes as well and this is not an somewhat odd combination,12:30
i think relating private to sourcefiles is not ideal12:32
, packages tend to be quite big12:33
<bonniot>in what language?
<arjanb>java, nice12:34
<bonniot>I mean that with different rules, you can end up using a different style, we have to keep that in mind12:35
<arjanb>yes
<bonniot>for private, I don't think it should be related to files, but to a notion of module12:36
each package is made of one or several modules, which each contain definitions12:37
it's practical to think of them as files in a batch implementation, but for instance in Eclipse it could be presented differently
<arjanb>so i was thinking like adding a local scoping construct like module name { defs; }
which would translate to a static class
<bonniot>yes, it's possible12:38
but I don't see the point of the static class. in the bytecode?
<arjanb>hmm that not needed indeed12:39
<bonniot>ok
<arjanb>but the module name could be used in a qualified name
<bonniot>what about a clash between a module name and a subpackage name?12:40
<arjanb>error because of incorrect module name12:41
maybe module should start with a capital letter
<bonniot>that complexifies the model quite a bit12:42
and I don't see what concrete problem it solves
about static methods, it is really a complexity in Java, because you always have to differentiate between static on non-static methods12:46
it's confusing to many beginners12:47
<arjanb>easier to reuse the same name within package and the qualified name is more self documenting
<bonniot>(I taught some Java courses to beginners in Uni)
<arjanb>i don't want distinction of static methods back12:48
<bonniot>ok :-)
but what if we can fully qualify the method with the package name?12:49
if you want to reuse the same name twice inside the same package, either that's overloading and then it's OK, or you might want to use a more specific name
<arjanb>we'll have to see if package name is enough to qualify12:50
<bonniot>agreed
i think we should start with a clean implementation of packages with qualified method names and visibility12:51
and it should be easy to extend in case we want to refine it later
<arjanb>it doesn't make sense to make a package for an enum but module name can be usefull sometimes: WeekDay.monday12:52
<bonniot>that's redundant to me. Monday is unanbiguous12:54
and overloading can be used to find out which enum we are refering to if needed
<arjanb>WeekDay.monday vs WorkDay.monday12:55
overloading is not a problem is only about readability12:56
<bonniot>there should be only one Monday!
with WorkDay <: WeekDay
<arjanb>true but subtyping is tricky for enums12:57
<bonniot>it's possible to handle it right13:06
so it's not a reason to introduce other features13:07
we could have:13:17
enum WorkDay { Monday, ..., Friday }
enum WeekendDay { Saturday, Sunday }
enum WeekDay extends WorkDay, WeekendDay {}
and that gives WordDay <: WeekDay and WeekendDay <: WeekDay13:18
<arjanb>if you have a method defined on WorkDay and you put a WeekDay in then you can have undefined cases13:20
<bonniot>yes, but luckilly you cannot do that ;-)13:23
because you have WorkDay <: WeekDay, not the opposite
<arjanb>yes i was confused13:24
<bonniot>yes, it's the opposite of classes
<arjanb>the makefile needs some refinement to allow bossa.syntax classes to be converted to Nice14:34
<bonniot>yes, surely
are you using the makefile?
<arjanb>no14:35
atm the parser is compiled before the Nice part of bossa.syntax
<bonniot>yes, the parser needs to know about all the classes14:38
i think a good idea would be to start with expressions14:39
and they could be in their own different package
<arjanb>why in another package?14:40
<bonniot>would be clearer14:41
when you work on the toplevel part, it does not matter what form of expressions exist
and expressions are also pretty independent from the rest14:42
<arjanb>it might require more change elsewhere
<bonniot>what?
<arjanb>moving to another package
<bonniot>i think bossa.syntax.Expression should still exist, and subclasses be in the new package14:43
i think it's very rarely if ever that a specific expression is used by the toplevel part14:44
<arjanb>bossa.syntax split up in expressions, statements, toplevel and maybe types?14:47
<bonniot>the real types are already in mlsub.*14:49
but yes the types before resolution are in bossa.syntax14:50
dunno how it would bring to get it out
for statements, yes, it's the same situation as expressions
but i'm not sure if there should be 2 pkgs for them14:51
<arjanb>reorganizing the packages can easily be done later14:53
* fcb leaves15:12
<bonniot>so it seems a good premilinary work would be to limit the coupling to simplify the bootstrap process15:18
<arjanb>wdym in more concrete terms?15:21
dependency between packages?15:22
<bonniot>yes. that we can build bossa.syntax before building the parser15:23
<arjanb>i guess no tool can draw depencies diagrams from mixed java/nice source15:24
<bonniot>no problem: there are that work on the bytecode15:26
<arjanb>do you know one?15:29
<bonniot>i remember one used by maven works like that15:31
http://packages.sourceforge.net/info/nice.swt/jdepend-report.html15:33
i think we should separate the interface of the parser with its implementation15:43
<arjanb>i have that tool working now15:46
hmm bossa.util depends on many packages
<bonniot>depends or is depended on?15:48
<arjanb>both so that's not optimal15:49
<bonniot>it's normal that many depend on it15:50
what does it depend on?
<arjanb>bossa.syntax, bossa.parser, bossa.modules, gnu.expr15:51
<bonniot>does that pose a pb atm?15:53
<arjanb>not direct15:54
but i think i need to draw diagrams to see if what the indirect problems are15:55
<bonniot>yes
probably some tools could draw the graph, but i don't know them
<arjanb>a tools won't help much because drawing on paper becomes a big mesh with only half of the dependencies16:55
<CIA-3>03arjanb * 10Nice/src/bossa/ (parser/Parser.jj parser/Loader.java util/Location.java): Make bossa.util not depend on bossa.parser.17:07
<bonniot>it's a problem of mono-methods: you tend to put methods inside a class, although they should really belong to a different package17:13
<arjanb>nice.tools.util.ClassLoader.java could be put in gnu.bytecode17:17
<bonniot>or nice.tools.code17:18
that's the package where we should put backend-related code17:20
is that OK with dependencies?
<arjanb>i want to avoid gnu.* depend on bossa.* and it does now through nice.tools.code17:21
<bonniot>that might not be easy to do17:23
<arjanb>true
i'm trying to get trivial dependencies away first17:26
<bonniot>good idea ;-)
if they are wrong of course
* ChanServ leaves17:28
* ChanServ joins17:29
<bonniot>i'll look at cutting the dependency on the parser, OK?17:54
<arjanb>yes17:55
i think bossa.util should be made an indepent package so that all error message / location stuff can be used everywhere without introducing spurious dependencies18:02
<bonniot>independent of what?18:03
<arjanb>of other packages18:04
<bonniot>sounds logical18:06
i could build the core without a parser ;-)18:20
<CIA-3>03arjanb * 10Nice/src/bossa/util/Location.java: Make bossa.util not depend nice.tools.util.18:31
<bonniot>hum, I don't think removing dependendies should be done at the expense of duplicating code, like this last change, and the Location creation in Loader...19:07
bossa.util and nice.tools.util have the same function, they should even be merged19:23
a cool thing is that by having a parser parameter instead of a static link to it, we don't need to pass storeDocStrings all around, that info can be directly stored in the parser, where it belongs19:31
that feels right
i got a working compiler now :-)19:47
<arjanb>another thing that could be merged is bossa.util.debug with the debug things in mlsub.typing19:59
and the dependency of mlsub.typing on nice.tools.typing shouldn't be20:02
<bonniot>agreed about the second. don't remember the details, but I knew it when I added the dependency, so probably it's not easy to remove20:05
for the debug parts, it should not add new dependencies20:06
<arjanb>mlsub.typing and bossa.util depend on each other now so i want only dependency in one direction20:07
<bonniot>ideally, mlsub.* should not depend on {bossa,nice}.*20:13
<arjanb>except on bossa.util20:14
<CIA-3>03arjanb * 10Nice/src/ (6 files in 3 dirs): Make bossa.util not depend mlsub.typing.20:32
<arjanb>i don't want to change the typing part but i see mlsub.typing depend on bossa.syntax on only 3 lines20:37
<CIA-3>03bonniot * 10Nice/bin/ (nicec.bat nicec): Start the JVM with 8MB of memory, to reduce initial garbage collection.20:48
<bonniot>i think it's time to release 0.9.8, in the state before this batch of changes...20:50
<CIA-3>03bonniot * 10Nice/NEWS: Closed 0.9.820:51
<arjanb>hmm look at new bugreport first20:52
a npe in the compiler but i don't see how that could happen there20:53
<bonniot>is this a regression?
<CIA-3>03bonniot * 10Nice/debian/changelog: Closed 0.9.820:54
<arjanb>not tested yet
yes an regression20:56
though i get the npe at another place20:57
0.9.7 seem to work in that case
<bonniot>at gnu.expr.FindCapturedVars.capture(FindCapturedVars.java:179) ?20:58
<arjanb>yes
but Bryn gets another npe strangely
<bonniot>yes...20:59
anyway that should be fixed, and then we can see if that fixes it for him too21:00
unfortunately I will be away for at least 2 hours now
<CIA-3>03arjanb * 10Nice/testsuite/compiler/designByContract/methods.testsuite: Testcase for bug #982048.21:21
<arjanb>odd this goes wrong:21:30
class A { ?int foo; }
void bar(A a) requires a != null {}
but this not:21:31
class A { ?int foo; }
void bar(?A a) requires a != null {}
i guess it has something to do with compiling methods inside classes21:34
* bonniot leaves21:46
* bonniot joins21:52
* CIA-3 leaves23:11
* CIA-3 joins
<bonniot>did you find anything about the bug?23:56
<arjanb>only that it's related to compilation of methods inside classes00:02

Generated by Sualtam