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

Using timezone: Central European Time
* bonniot joins10:07
<CIA-12>03bonniot * 10Nice/debian/ (control changelog): Depend on ant instead of libant1.6-java, since the former is in Debian main now.11:35
03bonniot * 10Nice/bin/nicec: 11:39
Changed bashism (SIGHUP) into POSIX syntax (HUP).
Removed french language in comment (oops!).
03bonniot * 10Nice/debian/changelog: Changed bashism (SIGHUP) into POSIX syntax (HUP).11:42
03bonniot * 10Nice/NEWS: Closed 0.9.1211:49
03bonniot * 10Nice/debian/ (control changelog): Upgrade to Debian policy 3.6.2 (no changes).12:06
03bonniot * 10Nice/debian/rules: Use ant.jar directly, now that we can depend on ant.12:13
* ArtemGr joins12:42
* raboof joins14:50
are you aware of other languages that have non-null references like nice natively?14:55
C# and Java have them only as an "add-on" (using ESC/Java or Spec#), it seems14:56
* bonniot leaves15:05
* bonniot joins
hi Artem!15:10
<bonniot>how are you doing?
<ArtemGr>don'no. was looking at Haskell last few days.15:12
<ArtemGr>conflicts with my greed of low-level optimization, and i'm still wondering about Java integration, but the language itself is very nice and i'm going to use it soon as an input data preprocessor for some project15:16
what do you think about internal program representation in Nice? i mean, all this bytecode Scheme staff is not a best way to represent the program, i've dreamed about some intermediate tree representation to optimize, etc..15:18
<bonniot>yes. ideally some third-party format would be good for the lowlevel representation. with advanced optimization and multiple backends15:20
but i'm not sure how easy it is to combine this with integration with Java/other libraries15:21
but don't be too greedy about optimization. the jvm is doing some wicked advanced things these days
<ArtemGr>it doesn't to tail recursion still, and i don't think it is going to very soon15:23
and if you look at GCJ, amount of optimizations it can make is limited, it should check if the class was initialized on every static method invocation, for example; this might improve, but it's not like the things C++ can do with templates...15:25
"conflicts with my greed of low-level optimization" - FFI inverface in Haskell (to plain C libraries) is very simple to use, though (good)... % )15:27
<bonniot>the thing is: do you know for sure if those add up to significant differences in your domain?15:29
(I'm also starting to see more and more of Java faster than C, because of runtime optimization. I think it's ahead in the shootout now)15:30
unfortunately i'll have to go soon
<ArtemGr>yeah, Java in shootout would be more like C if they've used decend benchmarks, that is, given a JIT compiler time to optimize. what i wonder about is if these optimizations are enough for heavy functional language. at least tail recursion should be implemented in a functional language, as it seems...15:32
i know a certain IBM jvm did it
but if it's critical, we could implement the basic case in nicec15:34
<ArtemGr>"the thing is: do you know for sure if those add up to significant differences in your domain?" - i know that Haskell laziness place it in a totally different domain, it's pointless to optimize it... : ) but to interoperate Haskell parts with more efficient main program is what i want... no easy way here, as it seems...15:35
"but if it's critical, we could implement the basic case in nicec" - i think we should...
i can be a nice "selling" point too;-)15:36
<ArtemGr>yeah, it is a kind of disillusionment currently, i think - can't program in functional style without a stack overflow fear...15:37
<bonniot>i se15:38
so let's do it
i'M sorry, i really have to go
see you soon
<ArtemGr>see you
* bonniot leaves
* raboof leaves17:08
* ArtemGr leaves18:49
* bonniot joins21:47
* bonniot leaves22:21