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

Using timezone: Central European Time
* zzorn_sleep leaves00:00
<bonniot>is stdlib/nice/lang/inline/ReferenceOp.java:87 really needed?00:27
it seems no testcase breaks without it
<arjanb>it's there because gnu.bytecode does bookkeeping of the stack00:29
<bonniot>but I commented it and I get no failure00:30
<arjanb>but now most code uses SimpleIfExp which i added later it might hard to trigger anymore00:31
my comment is confusing but gnu.bytecode depends on the stack types in quite a few places00:37
<bonniot>yes, i know about the stack types01:11
good night01:57
* bonniot leaves02:09
* arjanb leaves02:13
* Bluelive leaves03:05
* CIA-1 leaves05:26
* ChanServ leaves
* bangoola leaves
* ChanServ joins05:27
* CIA-1 joins
* bangoola joins
* zzorn joins08:09
* bonniot joins11:21
* arjanb joins13:28
* ArtemGr joins14:57
Speaking of assertions "point": if assertions aren't always enabled, then it is not even logical to treat "assert false" as an imperative exit from a method, on the contrary, compiler should expect the execution to continue after "assert false" becouse assertions are optional. And if assertions aren't optional in Nice, you should state it loudly, becouse it isn't what the general programer expects15:05
<bonniot>i think it makes sense to have a way to say "I guarantee this point will never be reached, and therefore I don't need to do anything in this case"15:11
technically, as we have seen, this means the compiler must throw an exception if that point is reached, even if assertions are not enabled15:12
<ArtemGr>throw new InternalError - will guarantee unreachability
<bonniot>technically that's correct. it just looks less declarative, less high-level to me15:14
arjan also suggested that a method that 'ensure false' is a way to declare that the method never returns
<ArtemGr>And I use it consciously (as it is recommended in some assertion papers) - where it is important to maintain a contract, I just do "if( condition ) throw exception", so that the check is permanent, and where I wish to do optional checks about the sanity of the program, i use assertions...15:15
Well, high-level can be bad if it have no logic. Are assertions optional or not?15:16
<bonniot>(continued) I don't see an equivalent with using exceptions. and assert false not returning is consistent with that
<ArtemGr>throw new Exception is treated as imperative exit by java compiler, so why isn't it equivalent?15:18
<bonniot>it's equivalent in statements, but you cannot use it in a postcondition
<ArtemGr>If you want a more self-documenting syntaxis, great, but wy should it then be merged with _optional_ assertions?15:19
<bonniot>assertions are optionally checked. but yes assert false would be always failing
do you have other ideas? assert false looked like a logical candidate15:20
<ArtemGr>It's a contradiction in terms.
<bonniot>it's a special case ;-)
in Java, a statement after while(...) {} is considered reacheable, unless the condition is true (and there is no break)15:21
that's a similar special case15:22
<ArtemGr>assert is an optional statement in all languages i know, and when this topic is explained by different authors a lot of attention is given to that that assertions should not modify the usual program logic, becouse they are optional. Having assert false to be not option wreaks havoc to carefully designed schemes in the programmer's mind.
<bonniot>I do see your point, though
if I remember correctly, somebody complained about assert false not leading to unreachability. it was intuitive to them15:24
<ArtemGr>while( true ) is not a special case, becouse nobody saying thet the cycle can not be infinite. But peoples are saying that assertions are optional...15:25
concretely, I don't think this would create unexpected errors, though15:27
<ArtemGr>I agree with that: assertions aren't intuitive, exactly becouse their are optional they are hard to live with. But you should either remain them to be optional, all of them, or you may say that in Nice all assertions are always have effect, which will make the Nice language simpler, less errorprone and more intuitive. But should not you have some assertions optional and some not.
"concretely, I don't think this would create unexpected errors, though" - it did already, aren't you remember the bug report? : )15:28
<bonniot>that was a code generation error, and it has been fixed ;-)
we need to distinguish the design from the implementation15:29
<ArtemGr>Fixed by introducing the contradiction in terms, it is more of a Microsoft style of fixing. ;-p
<bonniot>what I meant is that if you try to "clean up" after an assert false for the case assertions are not enabled, the compiler would let you know there is a problem15:30
<ArtemGr>In the way of AssertionError exception? What is the point of avoiding NullPointerExceptions then?
<bonniot>"In the way of" ? I don't understand15:31
i don't see the connection. the point of avoiding NPE is to catch as many errors as possible at compile time
<ArtemGr>Well, the clean up code is needed to awoid exception, and you are just forsing me to throw it..
<bonniot>you can always implement that behaviour if you want15:32
<ArtemGr>It's not important what I can implement. What's important is that your language became less obvious and surely less intuitive, i don't longer now and can't deduce from the code what assertions and postconditions are optional and what not.15:35
<bonniot>that's an overstatement, if only 'assert false' always has effects15:36
<ArtemGr>You saying that "assert false" always have evvect and "assert 0==1" not is intuitive?15:37
And obvious?
<bonniot>similarly to while (1==1) not being the same as while(true)15:38
in the Java specification
<ArtemGr>while( 1==1 ) and while( true ) will work exaclty the same (but without (useless) unreachability error), while assert 0==1 will not throw by default, and assert false will.15:40
Again, what is the point of saying "in the Java specification". We wheren't speaking about Java, but about intuitiveness. If you want to speak about Java, ok, why your assert false works different from Java?15:43
<bonniot>i don't think Java is perfect, as you may know ;-)
the point was to show that it would not be the first time that a constantly true expression is treated differently from true itself15:44
indeed, in a different context, as you point out
it's indeed not the most satisfactory, but it does serve a point (see http://sourceforge.net/tracker/index.php?func=detail&aid=1090913&group_id=12788&atid=112788)15:45
is there a realistic situation in which this can lead to something bad happening?15:46
if it's the case, then it would be worth reconsidering. otherwise, the theoretical uglyness seems to be worth the benefits15:47
<ArtemGr>My humle opinion is that while( true ) handling in Java specification is a cripple outbreak into optimization area. In C++ such things are implementation-depended and are warnings, not errors.
<bonniot>isn't the point about reporting a bug? (truly unreachable statment is unlikely voluntary)15:49
<ArtemGr>The point is that "assert false" is logically is optional statement to anyone understanding assertions. And bug report from a programming not understanding assertions should lead to making assertions behavior in Nice more intuitive, but not to introduce contradictions.15:51
Suppose we have "?assert" form which is optional, and "assert" which is not.15:52
<bonniot>what did he not understand?
is that a proposal?
<ArtemGr>It would be intuitive both to those who don't know about optional assertions and to those who does know and use them.
He didn't anderstand that assertions are optional and assert false should not always throw.15:53
<bonniot>that's what we are discussing. you cannot suppose it is the case ;-)15:54
<ArtemGr>I mean a lot of programmers can't understand assertions, as a lot of programmers can't understand threads, see http://www.softpanorama.org/People/Ousterhout/Threads/sld005.htm http://www.csd.uch.gr/~hy527/papers/threads-ousterhout.pdf15:55
So bug report from them is not a reason to make things worse.
Making assert always working and introducing optional "?assert" is an example of how bad things can be made good without making them worse. : )15:57
<bonniot>i agree every single opinion is to be taken with a grain of salt. to me this one suggested that it was natural to him to cover an impossible case with just assert false. it's not the first time, since another one such comment was the origin of the feature15:58
it's a proposal worth considering15:59
<ArtemGr>It was natural to him just becouse he didn't remembered at the moment that assertions are optional. As soon as he remembers that.
As soon as he remembers that he will thinks his code is wrong. Or he must always have to keep the "special behavior" in his head. Oh, I'm repeating myself. : )16:01
arguably, assert someExpression is fundamentally different from assert false16:03
in the first case, you have some condition that you think (hope) is true, and you want to be told if it's not when in debug/test mode
for assert false, you obviously already know that false is not true, so you are really saying: this point is not reachable16:04
so ideally you would have a different keyword: unreachable. but i'm not sure it is worth it16:05
still, my question remains: is there a realistic situation in which the current behaviour can lead to something bad happening?16:06
<ArtemGr>I still think the language abstractions should work uniformely. But giving our proporsal developed today, "assert false" WILL work as expected by general programmer, and "?assert false" will work as expected by experienced assertions user...16:07
The answer is: yes, but indirectly. A programmer can forget about a special case which differ from the general paradigm. Or the special case may mislead a new programmer to thinking that assertions are always on.16:10
If the assert false is in the end of the block/method, this will lead to different program behaviour.
<bonniot>i'm thinking it would probably be more logical if assert false threw something else than AssertionError when assertions are not enabled16:20
this would make clearer that it was not an assertion failing, but a supposed unreachable point that was reached16:21
<ArtemGr>What's the difference, I should catch this special exception in every method? Practically useless, IMHO.16:24
<bonniot>you should catch it in the same way as you might catch, say, StackOverflowError.16:26
<ArtemGr>I usually catch all exceptions on high level, to me any exception will rollback current transaction and will be reported to the user. Catching special exceptions and making workarounds is seldom practical, and ESPECIALLY for "assert whatever" exceptions which are put there just to check the sanity of the program and AREN'T expected to throw.16:28
<bonniot>yes, so that would be caught by that mechanism. i don't expect it to be treated specially16:30
<ArtemGr>BTW, can't your language have mechanizms to do something like "operator `unreachable` throw UnreachableException"? I've seen operators in stdlib, but have no luck to define my own ones, is it possible?
<bonniot>you would want it to unconditionally fail?16:32
`...` is a way to use symbols as method names16:33
inline ... is a mechanism to generate special bytecode, and is used to define lowlevel operations16:34
<ArtemGr>"you would want it to unconditionally fail?" - 'unreachable' - probably yes, 'assert false' - no.
operator `+`... That means that I can write:16:36
void anotherMethod( String, String );
void someMethod = aString" anotherMethod "aString";
<bonniot>no, at the moment things are hardwired in the parser16:37
but you can overload + for your own types if you want
there are ideas about code generating functions ("macros") that would give lots of expressivity, for the long term...16:39
<ArtemGr>macros( a, b ) = a.plus( b ) ?16:40
macros plus( a, b ) = a.plus( b ) ?16:41
#macros plus( a, b ) a.plus( b ) ?16:43
<bonniot>you don't need a macro for that ;-)
<ArtemGr>But with macro I should be able to write "a plus b", and with method I don't..16:45
<bonniot>the general idea is a function that's executed at compile time, with parameters being the AST of it's parameters in the source, and that generates the code that is then compiled
that's a syntactic aspect, which is a different question. and with C macros you cannot, for instance16:46
what I'm talking about is closer to C++ templates
(some part of it. templates are a big mess)16:47
<ArtemGr>Well, inlining of usual generic methods is close to C++ templates, but functions on AST seems to be more of a language plugins then of the part of the language itself?16:50
<bonniot>yes, you can see it that way16:52
<arjanb>it seems to me that Nice is moving to a point where assertion are considered always on17:06
* ArtemGr leaves
<arjanb>by having assert x != null and assert x instanceof ...17:07
* ArtemGr joins17:08
<bonniot>arjan "by having assert x != null and assert x instanceof ..."17:16
assertions can be turned off for optimization pruposes, but the compiler is allowed to believe they will succeed17:19
arjanb: i've implemented comparisons of possibly null values to primitive values, in the case of boolean assignment (not the optimization when inside tests)18:08
<arjanb>i think the optimization is not needed in that case18:18
<bonniot>but can we avoid it?18:20
<arjanb>avoid what?18:21
<bonniot>is it a choice not to handle the optimized case?18:23
it seems to me it's the client of ReferenceOp which calls compileJump instead of just compile18:24
<arjanb>yes just don't implement the Branchable interface18:25
* Atomixx joins
<bonniot>for ReferenceOp? then no comparison will be optimized!
<arjanb>maybe ReferenceOp could be split up18:26
<bonniot>no, because you don't know what kind of comparison it will be until you have the arguments18:29
but actually this gives me an idea for a simple implementation
in this case, in compileJump, just call compile, then based on the boolean do the jump or not18:30
it will be the same as no optimization, even when compileJump is called
<bonniot>that will save lots of work ;-))18:31
and error prone one, too
<arjanb>yeah i'm not so happy with the duplications there but i see no simple alternative18:33
<bonniot>i'll be away for the evening...19:04
<Atomixx>hi, i've got a question19:05
<Atomixx>to build the nice.swt.jar i fetch the nice.swt.zip and then i run maven nice:compile19:06
or must i do somthing other?
<bonniot>sorry, i don't remember just now, and as I was saying I must run19:07
<bonniot>leave me an email, i'll answer as soone as possible
* ArtemGr leaves19:24
* Atomixx leaves19:54
* bangoola_ joins21:54
* bangoola leaves21:55

Generated by Sualtam