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

Using timezone: Greenwich Mean Time
* bonniot leaves
* arjanb leaves04:53
* arjanb joins12:43
<Bluelive>he hoi12:44
hmz, ik zit een beetje te lezen over hoe jullie die methods doen
zit me af te vragen hoe je dat doet met namespaces
en of ze precedence hebben over lokaal gedefineerde methods
<arjanb>er is geen precedence voor bepaalde methods12:46
<Bluelive>je kan toch een this.call() hebben en een multimethod call() ?
<arjanb>daar zit geen verschil in12:47
zijn multimethods namespace gebonden ?
<arjanb>a.call(b) is hetzelfde als call(a,b)
volgens mij horen multimethods bij een package maar het zou ook globaal kunnen zijn nog12:48
* bonniot joins12:50
are multimehtods bound to a namespace ?
<bonniot>they are in the global namespace12:52
<Bluelive>well, im just wandering about the age old problem of global identifiers
talked with arjan alot during the weekend12:53
<bonniot>methods are disambiguated by the type of their arguments, so clashes are no problem
<Bluelive>and now im musing about includeing multimethods in my own language12:54
<bonniot>what is it?
<Bluelive>but multimethods are basicly untyped on their arguments right ?
<bonniot>what does that mean?12:55
mm are fully typed
<Bluelive>ehmz, partly inspired by nice, its basicly my own take on java but producing c code
<bonniot>so you have been knowing Nice for some time?12:56
is your language public?
<Bluelive>ive posted a few question along time back
i inted to make it public domain
<bonniot>ok. you know you can produce native code with Nice?12:57
option -o (which uses gcj)
<Bluelive>didnt know that one, but i tried gcj
<bonniot>what is your motivation to make a new language?12:58
<Bluelive>because i can basicly
<Bluelive>but also a frustration with other languages
<bonniot>that's a good reason
is Nice also lacking?
<Bluelive>well it uses the jvm12:59
(it's an implementation detail. just use gcj)
<Bluelive>ive had some problems in the past with deployments of applications because clients dont have the jvm and more such13:00
<bonniot>again, gcj is your friend
<bonniot>maybe it was not up to the task at that time, but it is quite good now13:01
so, objection answered. why don't you come and help us with Nice, bringing your own great ideas and skills?13:02
<Bluelive>well lets see what buzzwords i can use to give a few differences between our projects
<bonniot>i'm ready in buzzword eating mode ;-)13:03
<Bluelive>inline c, operator overloading, delegates, everything an object, metadata, multiple inhertitance, inline xml, verbatimstrings, with and after this weekend im seriously thinking about aspects, and thats on top of things like generics/parametrics, and the maybe null modifier13:04
<bonniot>lots of work :)13:05
we have lots of this already in Nice
what do you mean by inline xml?
<Bluelive>well i did have part of the code generator, which i rm'ed after i decided to do parametrics right :)13:06
<bonniot>how long have you been working on it?
<Bluelive>ehmz, basicly just a fancy way of constructing a tree of objects
more then half a year now i think
<bonniot>and what is the status?13:07
<Bluelive>what status's are available ? :)
it did a hello world, but really, about half way the core compiler i guess13:08
<bonniot>beware, the second half is longer than the first ;-)13:09
<Bluelive>i took that into account :)
but i really hurt myself with the paramterics, they are so horribly much complexer then i thought13:10
especially when casting them, or when constructing an item from a templated type
<bonniot>yes, a powerful type system is quite a big project
<Bluelive>well for some reason, generics causes it to be a weakly typed system13:11
just the simple T x(T a) function
<bonniot>you mean you have a bug in your type checker?13:12
<Bluelive>no, but i need to do quite alot of runtime checking
<bonniot>Nice does not13:13
<Bluelive>take the case of a collection class List which basicly is a List<Object>
if i make a List<string>, i think i should be able to use it as a parameter to a function with List<Object>
List should be invariant, if you can modify it13:14
<Bluelive>thats the problem i found :)
<bonniot>otherwise, yes, you will have runtime type errors
<Bluelive>but that would imply that strongly type generic collections to be pretty useless
<bonniot>no, because you can call polymorphic methods13:15
<bonniot>I can make methods that take List<T>, not List<Object>, so they can be called with any List
I can also have a method13:16
<Foo T> void foo(List<T>);
which can take a List<T>, for any subtype T of Foo
<Bluelive>how is that different from a void foo(List<Foo>) ?13:17
<bonniot>that one you cannot call with a List<FooBar>
(because it might write a Foo into the list)13:18
<Bluelive>so in nice you can implicitly cats, aslong if its not a parametric ?
<bonniot>the first one can, but the type system guarantess that there is no write
i don't get that
x(Object a) x("hello");
<Bluelive>is an implicit cast
<bonniot>ok, i see
yes. this is the theory of subtyping
String is a subtype of Object, but List<String> is not a subtype of List<Object>
there are good reasons for this, as you found out13:20
<Bluelive>well in alpha i just decided to not check the parametric type at compile time, just at runtime, this is also partly because of multiple inheritance in which i cant guarantee that types will stay disjointed
<bonniot>what I was trying to show with foo is that you can still do useful things, when the type system checks that you make no mistake
<Bluelive>well it accepts foo and up13:21
<bonniot>that's an easier way, but it is not as safe
<Bluelive>for reads
but it should accept foo and down for writes
<bonniot>a write only method?13:22
that's also possible
<Bluelive>there are also alot of writing code that stays type safe
for example a sorting algo
<bonniot>with your typechecker you mean13:23
<Bluelive>well it might throw an runtime exception13:24
i agree that the compiler should do the work, im just not sure how
not sure if its even posible
<bonniot>as I said, it's not an easy topic
it is possible: the typechecker of Nice does it13:25
<Bluelive>how does your <Foo T> make it safe for read/writes ?
<bonniot>both read and write in the same method?
a sorting algorithm for example13:26
a sort(List<Comparable>) for example
<bonniot><Comparable T> void sort(List<T>)
while (must exchange i and j)13:27
T temp = l[i];
l[i] = l[j];
l[j] = temp;
that will typecheck
it is safe, because the value you write has type T, which is the type of the elements of the list13:28
<Bluelive>that would also be safe in alpha
<bonniot>and inside the method, the type variable T is known to be a subtype of Comparable, so you can compare the values
sure, but alpha will not detect the unsafe cases, right?
<Bluelive>the implementation of the method is not really the problem, you could replace all the T's with Comparable here13:29
ah ic
<bonniot>for typechecking?
<Bluelive>T is more restricted of course13:30
<bonniot>yes, T stands for some unknown type, that is surely a subtype of Comparable13:31
<Bluelive>what happens when i call a method from within the function with a parameter typed as T ?
<bonniot>the type checker verifies that there is a solution to the constraint generated by supposing that T is smaller than the type of the formal parameter13:32
<Bluelive>but can you do an assignment to a T type ?13:33
<Bluelive>but T could be a subtype of comparable13:34
so you wouldnt know what types would be allowed till runtime ?
<bonniot>the value assigned must be known to be a subtype of T
in this sort method, for instance, only T is a subtype of T
in a more complex case, it could be another type variable known to be a subtype13:35
<Bluelive>but how can you know that a type is a subtype of T 13:36
T isnt decided till runtime :)
<bonniot>yes, but there is static typing information
for instance:
<T, U | U <: T> void foo(T, U);13:37
here U is constrained to be a subtype of T
<Bluelive>i c13:38
thats one mother of typesystem ;)
<bonniot>yes :-)
I'm doing a PhD on it, you know, and it keeps me busy alright :-)13:39
<Bluelive>still, is it usable ?13:40
i mean, can an average student understand it ? :)
<bonniot>as a user of the language?13:41
i hope so at least. Arjan seem to be going fine :-)
arjan and me did go to an european programming challenge a days travel away13:42
<Bluelive>well, thats not very average :)13:44
it's not a proof of the contrary, either
<Bluelive>thats true :)13:45
do you have a considerable userbase ?
<bonniot>i think that for a lot of cases, you can go with monomorphic types, and simple polymorphic types like collections
things like <T, U | U <: T> are good to have, but most people will not write such code everyday, so it is no major problem I think13:46
<Bluelive>thats true
thats why i think i can do it the cheap way :)
<bonniot>still, when you need it and it's not possible at all, it's restricting
it's also easier to use a method with that type than to write it13:47
<Bluelive>im not sure how i would represent that in my ast though
<bonniot>yes, but for instance the List<Foo> problem is frequent
it's like ArrayStoreException in Java13:48
yes, implementing this is not trivial
there is about 30K LOC for the typechecker in Nice
<Bluelive>how red are you going to be if i try to implement it ? :)13:49
<bonniot>why would I be red?
if you feel sorry for you, that's all! :-)
<Bluelive>but i thinki the multimethod syntax is just a bit too exotic
<bonniot>i have plans to make the syntax more mainstream
instead of13:50
foo(f@Foo, b@Bar)
it would be
foo(Foo f, Bar b)
less exotic, no?
<bonniot>seriously, about the typechecker, I think that's why it makes sense to try to collaborate with an existing project, that has already done some things right, and focus on something where you can make a real difference13:52
<Bluelive>well its just that i would like to have worked 6 months to just drop it all
<bonniot>i know13:53
on the other hand, if you work two more years on it, the loss gets bigger
<Bluelive>and lose a few of my core reasons becasue it ofcourse would be an composit of ideas that conflict
definitly true
<bonniot>i believe in modular compilers
<Bluelive>i really do like the idea's behind nice, except for a few fine points in the syntax, but i really believe java is the base platform13:54
<bonniot>so it should be possible progressively to implement "plugins", that handle one part of the language by doing a pass on the AST
<Bluelive>and that i dont like that aspect :)
how is the design of the compiler ?13:55
<bonniot>it's a pragmatical choice: it makes generating code easier, while having quite decent performance, with the current JITs
<Bluelive>is it possible to convert the current source in a modular/plugin design for ast processing ?
<bonniot>and other good point is that there is access to lots of libraries
it's possible to convert it, but of course this means work13:56
i think it can be done progressively
<Bluelive>well the libraries mostly need wrapping, and jars wont be very helpfull? and alot of libraries are also available for other platforms
<bonniot>there are already features that are implemented by "macros"
that is, you define the signature of a method, and say that instead of source code, it is implemented by a class, that knows how to generate the bytecode13:57
during the generation, it can look at its arguments, to decide what to generate
this is a first level of plugability
<Bluelive>well, its just, im more of a practical person, and i would like to envision that my language could be used for my job, and i just dont see that much java being used in applications i like13:58
<bonniot>what kind of applications?13:59
<Bluelive>most things i make are either server applications, big gui applications on windows, or solutions for programming problems14:00
<bonniot>on the server, Java is already quite strong, isn't it?
<Bluelive>not for standalone applications
it just isnt that unix friendly14:01
<bonniot>because you need lowlevel access to the OS?
<Bluelive>in part14:03
also some stuff with threading/processes14:04
and the eternal complaining about memory size and bandwidth
<bonniot>i don't have much experience on this domain. But Sun is quite a big Unix provider, so I would think they make Java suitable for this kind of environment
I think native compilation can help a lot with memory size14:05
<Bluelive>i tried that with early versions of gcj
but then it feeled asif a version of a jvm was compiled into the binary14:06
<bonniot>well, it needs to compile the base classes of course. they can be linked both statically or dynamically, depending on what you need14:07
you might want to try a more recent version too, I think they made a lot of progress14:08
about GUIs, I think using SWT is a very good solution now, better than Swing in most cases14:10
<Bluelive>but you dont think java is flawed ?
<bonniot>the language or the platform?14:11
<bonniot>for the language, i think it's decent, reasonable, but of course out of date now, if you look at, say, ... Nice :-)14:12
the platform is fine. it's a good idea to have some bytecode as a universal format, which you can then compile to native JIT or ahead of time14:13
i'm not saying it's perfect of course14:14
but it's quite a good compromise
<Bluelive>personally i would use ansi c99 as an universal execution format ;)
<bonniot>but then any single library you use can crash your application, or worse corrupt your data14:15
<Bluelive>dont get me wrong btw
ive been using java dayly for years :)
thats true even for java programs14:16
<bonniot>no to the same extent. if you have some private data, it cannot be touched by accident
<Bluelive>and even then, your compiler can generate all checks needed to allways throw an exception instead of segfault14:17
<bonniot>with pointer arithmetics?
how does it detect poking around in the memory of the program?14:18
<Bluelive>even then
if the compiler is trusted, it can generate checks for every operations
thats true even for c
but ehmz14:19
<bonniot>suppose you pass a void* pointer, what checks can it do to know if the function is not interpreting an integer as a pointer?
<Bluelive>no application im running at this moment checks the validity of every operation, because it isnt needed to,
when its used as an pointer to fetch data you can check validity14:20
<bonniot>(and it would be prohibitively expensive)
<Bluelive>(is it pointing to stack data, static data or a data piece of malloced data, etc)
it would be to expensive for final binary's14:21
<bonniot>yes, but it could be pointing to data it is not supposed to touch
<Bluelive>but valid during testing/debugging
<Bluelive>gcc does this
<bonniot>i don't see what information the runtime checker will use to know which data it can point to and which data it cannot
<Bluelive>-fmemory-valid-check or something
a very large amount of data :)14:22
its not very practical i agree
<bonniot>pointer arithmetic is quite a flaw for an universal format, don't you think?14:23
<Bluelive>its a valid part of the design of c
its just that we shouldnt be using c (in the way it is common)
<bonniot>yes, designed for writing an OS, but that is not a good feature for writing applications14:24
<Bluelive>well a large part of the very good coders i know use c exclusivly14:25
in ways that potentially could cause the most horrendous bugs in the wrong hands
<Bluelive>while (*(j++)) and such
<bonniot>i believe that higher levels of abstraction can bring more benefits that such low-level tricks
<Bluelive>when im in c mode i also create such code, its just so much fun14:27
well i believe they dont like the abstractions, and really think in tricks and assembly
<bonniot>yes, it's fun once in a while, and you can try the obfuscated C contest
but for real applications, i don't see the beenfit14:28
while I see very well the pains (reding other people's code)
tricks and assembly are fine, they can contribute to an OS kernel and such :-)14:29
<Bluelive>its not that simple14:30
you need a system in which you can combine them
<bonniot>why? to build interesting systems, you need to build upon abstractions
<Bluelive>trying to much to optimie like the c people is just wrong, but libraries should really be optimized like that14:31
but the implementations of those abstractions
should be very good
<bonniot>just to save a few % of performance?
a librarie is used so many times by so many people that it adds up14:32
<bonniot>yes, but a bug in a library also adds up
<Bluelive>but becasue of the high usage the probability of bugs not being detected and fixed is very low14:33
<bonniot>and the capacity to evolve the library easily is often more important
<Bluelive>and because its an library its also updated without to much pain
well you cant really evolve a library
just look at java
more just obsolete14:34
and provide an alternative elsewhere, increasing bloat and dead code everytime
<bonniot>i think the wrong approach in Java is the centralization of so many libraries
<Bluelive>and not telling new coders with old code not to use it anymore
<bonniot>i agree
<Bluelive>what would you do ?14:35
versioning ?
<Bluelive>how ?
<bonniot>most packages do not need to be tied to a particular JVM, they are pure java doc
pure java code14:36
so you could say: look, we made a design mistake in java.net
the current version is called 1.1, it will stay available for ever
we now public java.net 1.2, and we advise you to upgrade, when you find it convenient
when writing a new prg, you use 1.214:37
but you can keep your old ones with 1.1, if you don't need/want to upgrade
lets all just pray for the day of 2.0 when all the old falls away14:38
<bonniot>that could be good
but I think that we don't need to depend on Sun
<Bluelive>i think we shouldnt
<bonniot>it's possible to have a more decentralized approach to libraries14:39
<Bluelive>btw i saw that nice is under the gpl
<Bluelive>why ?
<bonniot>i want people to be able to contribute to it and know that it will stay open source14:40
is that a problem?14:41
<Bluelive>i thought the gpl didnt work for java
<bonniot>that's a misconception
<Bluelive>because jar's didnt qualify for the dynamic link requirement
ow well
<bonniot>for the compiler, you just need to run it, no problem
<Bluelive>personally im more of a public domain/bsd license person
<bonniot>the parts needed at runtime (very few) are GPL + linking exception, so you can use it as you wish14:42
<Bluelive>well if you write code in nice you will need some librays with it to be usable ?
<bonniot>you can use java libs. the nice libs have the linking exception, so no problem
BSD is fine too14:43
but don't complain is MS embraces and extends :-)
if MS ...
<Bluelive>well i think its better to run on karma then on legal protection
<bonniot>what does it mean?
<Bluelive>well basicly what linus does
<bonniot>he uses the GPL
<Bluelive>that doesnt mean that nobody can steal it away from you14:45
<bonniot>what are you thinking of?
<Bluelive>it just means they cant legally make money of off it
well sya ibm adopt the current kernel, branches it and start distributing its own version and updates it and add s allsort of things people likes14:46
<bonniot>then they have to release it under the GPL
but it wont carry linus's face anymore14:47
<bonniot>so how is it "stolen"?
<Bluelive>we'de call it imb's linux, not linus's linux, in material terms there would be no theft, but to people the image would have changed14:48
<bonniot>you can call it as you want
people still associated Linux with Linus, although most of the work is done by other people now
<Bluelive>its more about control and politics then ownership14:49
<bonniot>yes, but there is no control problem: anybody can fork if they want
<Bluelive>i dont think gpl is different from bsd in that
sure there is a control problem
to have anything of quality you need some force to counter the entropy of continual branching14:50
<bonniot>nobody can steal from Linus, because he will not have lost a bit
if people prefer the forks, yes
but that's a good part about it
you are free to do as you please
<Bluelive>as it should be14:51
<bonniot>in your scenario, Linus can freely put IBM's changes into his tree if he wishes
with BSD, that would not be guaranteed
that's a bug difference
big/bug :-)14:52
<Bluelive>but the 'karma' of the 'linus' main branch causes it to reveive patches, instead of only being branched from
<Bluelive>i propose the same sort of thing for the library's of for example nice
that would show sun how to inovate ;p
<bonniot>i agree "karma" is very important too. I think having the law with you cannot hurt, but I can understand your view14:53
what do you mean? versioned packages?
<Bluelive>for me gpl doesnt feel all that free
no just a main branch, of which you think that the contents are of high quality and functionality
<bonniot>that's a good proposal, of course!14:54
are you going to help? :-)14:55
<Bluelive>i think that force is laking in 'linux the os'
well if my experiment fails you can ask me again :)
does nice have continuations btw ?
<Bluelive>oing to have ?
<bonniot>but you could do them explictitely with anonymous functions, right?
<Bluelive>well, where would you store the state information ? and typing out the whole pre, switch, post is pretty ugly :)14:57
<bonniot>i don't plan on continuations in the main language at the moment, but it might be doable as macros/plugin14:58
does alpha have them?14:59
still thinking about it though
its not an itch ive been wanting to scratch really
until now, most of your work is in the basic infrastructure, or do you have fancy features?
<Bluelive>its all a bit intermingeld15:01
what would you consider a fancy feature ?
<bonniot>something not in Nice :-)15:02
<Bluelive>most of the things are in nice :)15:03
operators ?
<bonniot>we have them, but only a fix set15:04
<Bluelive>i put them into interfaces
and gave them some require/ensures
<bonniot>that is, you can define a new meaning for % for instance, but you cannot declare +==+ as a new operator
<Bluelive>does nice do that ?:
inherit require/ensure's from overriden methods ?15:05
ah yes, same here
otherwise the parser/lexer would be having a headache :)
<bonniot>require/ensure are given at method declaration
if you implement/override the method, you inherit them, yes15:06
<Bluelive>as it should :)
<Bluelive>is nice enjoining some popularity ?
or is it not ready for that ?15:07
<bonniot>it's already growing
everything is relative, of course
i do not advertize it yet broadly, but for people interested in advanced languages15:08
<Bluelive>well i did point an ibm swede to your site so maybe it'll take off
<Bluelive>he was talking about aspectj
<bonniot>for the life of the project, it had 4000 downloads of the compiler
<Bluelive>aspects really seem like a nice way to replace a preprocesser15:09
<bonniot>and currently there are about 4-5000 page views per month
<Bluelive>unique's ?
<bonniot>that's SF stats
i think it's page views, not visitors15:10
so it's not bad already, there is a user base
even some use in industry already15:11
<Bluelive>do you know any good language development sites ? LtU is fun but they talk lisp way to much for my liking
<bonniot>LtU is the best I know
<Bluelive>anything you would have done different with nice if you could start over ?15:12
<arjanb>a group of people each making their own language: http://groups.yahoo.com/group/langsmiths/messages
<bonniot>I would probably not have started from scratch, but tried to extend an existing compiler15:13
which one ?
<bonniot>really, it's a lot of work to get to the point where you can start the fun of the most advanced features
Nice :-))
now, that's a bootstrap, with time travel and all :-))
<bonniot>dunno, maybe pizza, but i'm not sure how open it was at the time
or a basic java compiler, just to get the basics working
<Bluelive>but still jvm based ?
<bonniot>yes, i don't regret that at all. i was not even enthusiast in the begining, i wanted to write it in Caml15:16
i think i finally chose Java because a typechecker I could extend was written in Java
<Bluelive>nice was intended a mariage of ocaml and java
<bonniot>it's a way to see it, yes (ML and Java)15:17
although the most special features are in neither (multimethods, null types...)
<Bluelive>alpha is more an modernized java backported in to something c++ ish
null types ?15:18
<bonniot>it is easy to use existing libraries?
the ?String
<Bluelive>writing the libraries is half the fun
<bonniot>ok, but to do serious stuff you cannot write everything15:19
<Bluelive>you allways need contributions
<bonniot>that makes the difference between a toy language and a usable language
true. but it's quite difficult toget contributions until you have something fairly usable15:20
<Bluelive>no, the difference is when a hunderd people you dont know use your language
i wont have to write very hardcore code, i can still use the ansi c99 libc functions
<bonniot>yes. i meant it's one of the requirements to get past the toy language stage, which you know you have done when many people use the language15:21
<Bluelive>and mainby some posix2 stuff
im even nuttier then this btw, i intend to write an os in it
<bonniot>how much time do you think is needed until, say, you can use it in your work?
i seeeeee.....15:22
<Bluelive>1000 work houres i guess
<Bluelive>nothing to stupid, ill use linux for the kernel
<bonniot>and glibc, and posix, and gnu tools? :-)15:23
<Bluelive>yups :)15:25
<bonniot>already saw that somewhere...15:26
btw, what do you do?
<Bluelive>sitting behind a pc, what do you mean ?15:27
<bonniot>for a living/studies
<Bluelive>ah, student
<bonniot>(not "what are you doing?" :-)
<bonniot>i would have guess that part :-)
<Bluelive>i think the same as arjan15:28
he lives a sneeze away
<bonniot>and he did not try to convince you to switch to nice?
<Bluelive>currently im being treated for depressions and such
<Bluelive>not really that much of a student either, just cant keep my mind away from my real intrests
<bonniot>which are?15:30
<arjanb>that's a familar problem
<Bluelive>basicly programming
and being depressed
its a hobby, job and life
<bonniot>that's not so interesting, is it?
<Bluelive>not really i guess, neither is studying15:31
<bonniot>too bad. when you have good teachers and books, it can be
<Bluelive>well LtU has been a good teacher
<Bluelive>but IRL teachers really seldom take the time to make anything intresting15:32
<Bluelive>in real life15:33
<bonniot>so you have to make interesting things on the side15:34
<Bluelive>well its worse than that
leaving things on the side is the difficult part
these things tend to get dominant15:35
<bonniot>you mean not doing them full time?
yes. alpha?
<Bluelive>well i have to work on not working on them for more then 10 houres a week
and not talking for houres about it to anybody that understands anything about programming15:36
<bonniot>10 h is quite OK
yes, it might become boring for them :-)
although if they have an open mind and you can picture things in a colorful way... :-)15:37
its more that they either dont understand what im saying, or they arent really interrested
<bonniot>which is understandable. not everybody is a hacker15:38
<Bluelive>well it would be fun to find a few15:39
<bonniot>here we are :-)
<Bluelive>ellow :)15:40
do nested parametric types work 15:43
with the constraints as earlier with the foo method ?
<Bluelive>for example
no i dont have a good example question :)15:48
<bonniot>in short: the typechecked is not ad-hoc, it handles arbitrary types and constraints
<Bluelive>is the check during definition or during use?15:50
<bonniot>during definition :-)
unlike C++
<Bluelive>c++ templates are so powerfull, yet so horrible15:51
the whole new type stuff, and no definition checking
<bonniot>I think type parameters + hygenic macros are way superior15:52
<Bluelive>when did arjan join in the development ?15:54
and stuff like pointers ?15:55
delete that last line :)
about 1 year i think15:58
<arjanb>i found Nice about a year ago and got commit rights in March i think
<bonniot>some recent jvm benchmarks: http://www.spindazzle.org/benchmarks/16:32
gcj bring very interesting performance in some cases16:33
* Bluelive leaves19:56
* Bluelive joins
<arjanb>daniel: why doesn't typecheck() use an additional info argument as analyse() does?20:31
* Bluelive leaves21:01
* Bluelive joins21:02

Generated by Sualtam