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

Using timezone: Central European Time
* arjanb leaves01:58
* bonniot leaves02:42
* ArtemGr joins06:56
* Artem joins10:30
* Artem leaves10:32
* ArtemGr leaves10:39
* ArtemGr joins10:42
<CIA-3>03artemgr * 10Nice/ (3 files in 2 dirs): ?String getMessage(Throwable) retyping.11:09
03artemgr * 10Nice/ (4 files in 4 dirs): Forced assertions (RFE 1153220) and automatic assertion message.11:14
* bonniot joins11:19
<bonniot>about running ant in the tester: why are you throwing away the exit code with 'exit 0' ?11:27
<ArtemGr>by mistake; should be "exit $?", probably.11:29
<ArtemGr>what's the problem with today tests? i've checked on Linux, doesn't fail at with "EOF at Project 21" for me
<bonniot>it's a local change11:31
i'll commit it when it's working
running now
<CIA-3>03artemgr * 10Nice/NEWS: Forced assertions (RFE 1153220) and automatic assertion message.11:32
<bonniot>don't you need parser changes to support that?
<ArtemGr>It's a followup, forgot to change NEWS in the first commit.11:33
<bonniot>yes, but i didn't see a parser change on nice-commit11:34
could be that the mail is taking it's time ;-)11:35
<ArtemGr>I've notices sourceforge fails to send email's from time to time.
<bonniot>fails? i thought it just arrives with a long delay11:36
we'll see
anyway, i'm not sure we should have three syntaxes for two semantics, that could be confusing
what about dropping ?assert ?11:37
<ArtemGr>nay, i had about 7 messages about Visibility at gmane, and only 2 at mailbox. Yesterday there was commit i've seen in CVS but not on gmane.
<ArtemGr>just checked, my changes to Parser.jj are in CVS.11:43
so, what about ?assert ?11:48
<ArtemGr>what do you mean?11:49
<bonniot>see my questions above
<ArtemGr>ah, missed them. I've implemented only "!assert" first, then added the "?assert" for completeness. the point is that it is similar to sure/maybe types and it is clear from the code whether the assertion is optional or not. i think it's worth it to keep "?assert" for users who just likes to write it so, to remind themselves that it is optional11:55
originally i've thought also about "?assert false" behaviour, in theory it might be different from "assert false" so that the assertion is truly optional.11:56
<bonniot>that would further complexify the situation. on the other hand, i really want 'assert false' to statically never finish, so if such behaviour is needed, ?assert false would be the logical way to get it12:02
<ArtemGr>All right, i'll remove the "?assert" now.12:03
<bonniot>if you want, i can live with it too12:04
<ArtemGr>i will try to make the parser replace the "?assert" with the "assert", so that no special "?assert" handling is required anywhere.12:07
<bonniot>ah, so there would still be three syntaxes, just two methods?12:08
<ArtemGr>yes, the syntax seems all right and the additional complexity will be limited12:10
* arjanb joins12:11
<bonniot>and so no special meaning for ?assert false ?
hi arjanb
<ArtemGr>bonniot: yes
<bonniot>bonniot: positive answers to negative questions are always confusing (me, at least)12:12
you mean: "yes, no special meaning", or "yes, a special meaning" ? ;-)
<ArtemGr>"i mean no special meaning" 8 )12:13
<bonniot>(in french and hungarian at least, there are different words for yes in those two situations)
<ArtemGr>how about that:12:14
( t = <ASSERT> | t = <SUREASSERT> | t = <MAYBEASSERT> { t = symb("assert",t) } )
<bonniot>i actually think it would be better to keep !assert and ?assert as the method names, since that's techinically the clearer12:15
then in the parser, understand assert as ?assert12:16
<ArtemGr>"and so no special meaning for ?assert false ?" is an expression (assumption, assertion); if expression is true, the answer is yes, otherwise it is no...12:20
<bonniot>i agree in a logical setting
i think the english language works the other way
not 100% sure12:21
so in any case, it's better to clarify ;-)12:22
mabye we should just speak french for clarity purposes ;-)
<ArtemGr>i think it is a special case: "yes, there are" means "no", while "yes" means "yes". : )12:23
no problem to clarify, of course.12:24
<bonniot>and "no" means "yes" ?12:25
<ArtemGr>yes : )12:27
oh. no, it doesn't! : )12:28
what about automatic message format, is it ok?12:31
<bonniot>what does it look like?12:32
or the whole idea?
<arjanb>what is the automatic message format?12:39
* ArtemGr leaves12:49
<CIA-3>03bonniot * 10Nice/src/bossa/syntax/analyse.nice: Removed duplicate retyping for User.error12:55
* ArtemGr joins13:17
arjanb: "what is the automatic message format?" - automatic message is generated for assert statements without a message, that is { assert false; } will have an automatic message, while { assert false : "foo"; } will have a foo message.13:20
currently the automatic message for "assert 0 == 1" looks like "`==`(0, 1) failed at c:/spool/whatever/main.nice: line 9, column 14".13:21
<arjanb>i think that's a good idea13:22
<ArtemGr>it was suggested somewhere on the Wiki, although i can't find were.13:29
<arjanb>here too http://sourceforge.net/tracker/index.php?func=detail&aid=1096734&group_id=12788&atid=11278813:30
<ArtemGr>ah, that's where i saw it, and not on the wiki.13:31
<CIA-3>03artemgr * 10Nice/src/bossa/syntax/tools.nice: A fix for "Removed duplicate retyping for User.error".13:43
03artemgr * 10Nice/ (4 files in 3 dirs): 13:47
Replace "assert" with "?assert" in the parser
(so that there are two assert idents instead of three).
<ArtemGr>bonniot: no Parser.jj changes in gmane.comp.lang.nice.cvs, again.13:57
<bonniot>ArtemGr: tools.nice: thanks, i was going to fix it ;-)14:07
can't see the message, yes. looks like it's sf delaying14:09
<CIA-3>03artemgr * 10Nice/regtest/regtest: "echo -e" seems to be redundant and is not supported on FreeBSD...14:10
<bonniot>weird: it does look like escapes are recognized even without -e14:12
i'm going to report a bug on the manpage...14:13
<ArtemGr>there is an -E option on Linux, used to _not_ recognize escapes, and "-e" is just a counter-option for clarity...
no problems with man page i have14:14
(that is, no bugs)
<bonniot>i get that behaviour, but the manpage here is not up to date
what linux?
what distribution?14:15
<ArtemGr>" -e enable interpretation of the backslash-escaped characters listed below
" -E disable interpretation of those sequences in STRINGs
" ...
" Without -E, the following sequences are recognized and interpolated:
don't know, it's not mine, and "uname -a" on Linux often omits the distribution...14:17
uname -a: "Linux jeka 2.4.28-gentoo-r5 #2 SMP GNU/Linux"
even "dmesg" have no distribution displayed on startup14:18
<bonniot>cat /etc/motd ?14:19
<ArtemGr>cat: /etc/motd: No such file or directory
<bonniot>cat /etc/issue14:23
<ArtemGr>"This is \n.\O (\s \m \r) \t" 8 )14:24
<bonniot>weird system14:25
<ArtemGr>found /etc/gentoo-release: "Gentoo Base System version 1.4.16"14:27
ArtemGr: you forgot to login on sf? ;-)14:34
<ArtemGr>yes. : )14:36
sf usually remembers me automatically, but this link from Arjan has probably mislead it.
<ArtemGr>or maybe not. i've just tried, and sf doesn't 'remember' me.14:37
<CIA-3>03bonniot * 10Nice/stdlib/nice/lang/range.nice: Added missing List method implementation.14:51
* raboof joins15:30
i just read about nice, haven't used it yet, but it seems really, well, nice! :)
too bad there isn't type inference yet, but still :)15:31
<ArtemGr>what have you read?15:32
<raboof>i came from http://www.xoltar.org/misc/static_typing_eckel.html , after that i browsed though some of the tutorials 15:38
<ArtemGr>type inference is, in fact, implemented15:43
<raboof>oh, coolness15:44
the `academic research page' still says `The presentation is much simpler, and it includes type inference, which is not yet present in Nice.' - maybe there's some subtle difference there, or it needs to be fixeD?
<bonniot>hi raboof 15:49
type inference is actually partially implemented15:50
you can usually leave out the type of local variables
there are still a few known bugs with that, which is why we are not shouting it too loud yet ;-)15:51
<bonniot>also, unlike java 5, you never need to specify type parameters, that's already completely inferred15:52
<raboof>still i'm certainly going to try out nice soon ;). proper static typing is kindof a hobby-horse of mine, haven't seen many `real' languages get it right yet :)
except for the function gang of course
nice is trying to bridge that gap15:53
note that nice is in a way more ambitious than most functional languages, since it supports atomic subtyping (subclasses), null without wrapping, multi-methods, ...15:58
<raboof>i assume the design-by-contract features are run-time?15:59
<bonniot>yes. that's precisely for the properties that we don't know how to express and check statically16:00
but we do as much static analysis as possible16:01
for instance for possibly null values
<bonniot>do you have other uses of DbC in mind?16:04
<raboof>well, http://secure.ucd.ie/products/opensource/ESCJava2/ does DbC-like things that are checked statically16:05
pretty cool stuff, but not exactly mainstream :)16:06
the reasoning system that's at the basis of it is some highly academic thing written in Modula-3 iirc :)16:08
for null values, i think it's more elegant to handle it at the type level16:12
<raboof>i totally agree
<bonniot>for numbers it's of course harder
one thing i would want to introduce it custom numeric subtypes16:13
<raboof>like `even integer smaller than 10'?
<bonniot>mainly, numbers with a certain semantic in the programmers view
so you can't mix an age and a price, for instance16:15
so, opaque subtypes
<raboof>yeah, that's nice in general
<bonniot>but still represented by primitive values at runtime
<raboof>doesn't sound that hard conceptually, but practice is often different :)16:18
<bonniot>yeah ;-)16:19
giving it some thought, it indeed seemed not too hard
what I wonder is if it's enough in practice to make the type a mere subtype of the parent, with explicit conversion the other way around16:21
let a = age(10);
a has type age
a+1 has type int
with the declaration: class age extends int;
<arjanb>i don't think it's a class16:30
<bonniot>that's a syntactic detail16:31
<arjanb>it's more like a subtype with a conversion function16:32
<bonniot>but it's more consistent to use class that something else16:33
yeah. subclasses are subtypes in nice
<arjanb>well we need some way to declare type aliases too
<bonniot>from prelude.nice: class int extends long = native; ;-)16:34
<arjanb>yes but in that case the user doesn't have to write a conversion function
<bonniot>yes he does: int int(long). it's in nice.lang16:36
<arjanb>age age(int x) requires x > 0 = cast(x); the cast doesn't look nice16:37
<bonniot>that conversion function would be provided automatically16:38
which does not leave room for the precondition16:39
<arjanb>and you may want non trivial conversion
<bonniot>you do, otherwise it should not be a subtype16:40
i.e. age(0) should be really the int 0, otherwise you'll be surprise when you use it as an int
<arjanb>oh right16:41
<bonniot>see you later all16:58
i totally love the `safe version of instanceof' idea. actually i dreamed that up a few weeks ago and wished more languages did it like that :)17:09
<ArtemGr>you mean type and nullness inference from instanceof and assert statements?17:17
<raboof>ArtemGr: yeah17:20
most languages have a `classcastexception', which is usable, but when you're casting in any proper type system it's usually more of a case destinction rather 17:21
in other words, a `failed cast' isn't really `exceptional'
so it's great to actually be able to write it like that17:22
<ArtemGr>http://sourceforge.net/tracker/index.php?func=detail&aid=1096725&group_id=12788&atid=362788 was recently implemented17:24
<raboof>sweet. why doesn't the whole world use nice instead of java? :)17:25
<ArtemGr>see also http://sourceforge.net/tracker/index.php?func=detail&aid=681385&group_id=12788&atid=36278817:26
if( foo == null ) foo = new Foo(); analysis actually works. it's not that important, but pleasant.17:28
<raboof>yea ;)17:29
* raboof -> home17:30
<bonniot>raboof: "why doesn't the whole world use nice instead of java?" just wait, it's coming ;-))18:39
* ArtemGr leaves22:11