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

Using timezone: Central European Time
* zzorn_ joins00:04
* zzorn leaves00:14
* zzorn_afk leaves00:55
* CIA-2 leaves01:22
* CIA-2 joins01:23
* CIA-5 joins01:25
* CIA-2 leaves01:27
* bonniot leaves02:39
* arjanb leaves02:58
* cocoblico joins03:27
* bonniot joins08:30
* Bluelive joins09:47
<Bluelive>im thinking about if two part references would work09:51
one part as a type indentifier and the other part as an instance identifier09:52
that way i could have instances that dont have heap space
that way i could have atleast a bit efficient integers as objects
and can have token like objects that dont consume memory in any way other then the size of the reference variable pointing to it09:53
<bonniot>but then references would be bigger, right?09:54
i guess i would use 8 bytes for an reference
so that would be a pointer to a typestruct in memory, and either a int or pointer to another struct09:55
you could place it into a single int but that would need alot of processing at runtime
<bonniot>hu? then you need to allocate the struct
<Bluelive>typestruct only have one instance for a type09:56
<bonniot>i guess you just mean 4 bytes for the type and the int or pointer
<Bluelive>im searching for an article studying this
<bonniot>i parser pointer to (typestruct in memory, and either a int)
<Bluelive>cant find it yet
<bonniot>YOU ARE BUILDING A vm?
sorry for the caps
<Bluelive>this would be both usefull in a vm or native compiled i think09:58
<Bluelive>but ill start with a vm
<bonniot>what do you think about a boxing implementation that would guarantee there is only one instance per boxed value?09:59
<Bluelive>if you could optimize away the calls you still have an additional layoer of indirection10:01
<bonniot>what calls?10:02
<Bluelive>also you share the addressspace with objects so you couldnt represent the whole range of integers without thashing the cached object instances
a.add(b) where a and b are boxed integers. you might optimize that into a.value + b.value
but that still is a level of indirection for the .value
<bonniot>well, you unbox them10:03
<Bluelive>yes,thats what i did, because i dont use the value anywhere else in the example i dont localy store the a.value 's result10:04
<bonniot>i think the cost only matters inside a loop10:05
so you can unbox once, and you are fine
<Bluelive>eh its a choice of tradeoffs10:06
<bonniot>i think arithmetic on the boxed versions is not the most critical anyway
the problem of your solution is that it has a cost even if you never box
<Bluelive>at the expense of reference sizes i save some heap usage and less nonlocal memory reads10:07
<bonniot>if all references are doubled, heap usage might well increase (think of an Object[] array: mem size doubled)10:08
but youll never have a page fault for reading a Integer10:09
and an array of a final type doesnt need to store the type pointers10:10
so an array of int isnt double in size
<bonniot>yes. it all depends if that happens often. again: I think cpu intensive arithmetics will be monomorphic, so they have no penalty
then how do you pass an int[] array to a <T> T[] method?10:11
reading through an accessor for all object based arrays might be a bit expensive10:12
how does java do that btw ?10:13
a char[] to a <T> T[] ?
<bonniot>java doesn't do it
nice does, with boxing of elements10:15
<Bluelive>well there are a few options, dont support it, use accessor methods when not sure what solid implementation is used, allways use 8byte references
i wouldnt use the last option
that way a byte[] would be 8 times larger then expected
<bonniot>yeah, bad
Nice has wrapper classes for this10:16
<Bluelive>so i guess i would support the second option if i needed to use an array in that fashion
how do you wrap an array ?
hmz, even better dont support using an int[] as T[] array, but use a List<int> like wrapper class10:18
<bonniot>in an object that has the array as its field10:19
yes, that object implements List
T[] is compiled as Object in bytecode
<Bluelive>ow, btw i decided on multiple inheritence from baseclasses with no instance variables or constructor and single inheritence from the other kind10:20
not sure hwat thats called
mixin maybe
<bonniot>how does that differ from Java?10:21
<Bluelive>not much, interface methods may have an implementation10:22
then it's like Nice10:23
you have all the good ideas build into nice right ? :)
<bonniot>sure ;-)10:26
<Bluelive>im still wondering about memory management
im warming upto reference counting10:27
you know about cycles?
<bonniot>ref counting has been tried many times. and abandoned many times10:28
with a good GC, performance is not even a problem
<Bluelive>well im just thinking that mark and sweep is O(n) over the number of objects, refcounting only over the number of objects used
ad you get dependable finalizationg
and i dont think mark and sweep is memory friendly10:29
a full application memory sweep would cause loads of pagefaults
<bonniot>but mark and sweep is not the state of the art10:30
at least not by itself
so my issues with it are solved for some current automatic gc's10:32
<bonniot>generational collectors have different techniques for new objects (most of them die very soon)10:34
and long lasting objects
GC is a very complex subject, especially if performance is the issue10:35
<Bluelive>im looking into a way to have good memory locality
the only gc im familiar with is mark and sweep, and that is very bad at it ;)10:36
* zzorn joins10:39
<Bluelive>anyways, i want to write an os in it, and i doublt that gc'ing a kernel is an option10:40
<bonniot>leaking memory is?
<Bluelive>i can still gc once in a while to find and resolve memory leaks
hey you can allways write bad software
<bonniot>but then it's less efficient that doing GC
there are parallel gc that do no require stopping the program10:41
<Bluelive>doesnt that require synchronizing the stack ?
<bonniot>i don't really know how it works
<Bluelive>hmz, if i write it right it should be easy to switch form refcnt to something else10:42
<bonniot>aren't you afraid the project is too broad?10:43
<Bluelive>eh, ill have a few decades left to complete it10:45
<Bluelive>if i only should write something that is managable, popular, moneymaking, and wanted
i couldnt write anything as a hobby10:47
<bonniot>unless you team up with others...10:49
<Bluelive>true true10:51
<bonniot>still sure you don't want to add your talents to the Nice team? ;-))10:52
<Bluelive>but programming in a team is very different then programming for yourself
im not sure what the goal of nice currently are10:53
<bonniot>sure. you need more communication in a team ;-)
but then it's a great feeling to work together, to know that things are improving in other areas that the one you touch at that point10:54
<Bluelive>eh, i have that at work allready ;) for me its more about more advanced knowledge and design10:55
<bonniot>goals? what about: be a better Java! innovate with more expressivity and more safety. good performance
<Bluelive>ah :)10:56
but i feel we differ on what a better java is
<bonniot>for instance?
<Bluelive>well nice is very rich in syntax
<bonniot>too complex? what would you remove?10:57
<Bluelive>im not sure if i would remove something11:01
but method syntax forexample
<Bluelive>why arent they bound to a class ?11:02
<bonniot>you can declare them inside a class if you want11:03
but multi-methods are more powerful
<Bluelive>but why support both ?
1. it's common to define a bunch of methods together with a new class. defining them inside the class is somewwhat more concise11:04
2. that's what most people expect of OO languages. so yes, one can define the purest language, but if nobody uses it, what's the point?11:05
it's just a convenience, you can chose your style
<Bluelive>i guess the problem is that nice requires its users to be smart and knowledgeable11:07
with optional syntax you only need to use one, but you need to understand both
inferance is a great tool, but the user still needs to understand what happens11:08
if (a!=null) for example has a compile time side effect on how 'a' is treated forexample11:09
<bonniot>isn't that pretty intuitive?
<Bluelive>only if the programmer itself expects the compiler to resolve such things because its very obvious to the programmer11:10
but i dont think most programmers are that familiar with nice
<bonniot>the thing is that other languages are not null-safe11:11
<Bluelive>pluk is ;p
how is java not null safe ?
<bonniot>Nice is, but with such inference, it will only signal a possible error when it makes sense
String s = null;
int i = s.length();
<Bluelive>it throws an expception if the state is illegal
yes, and nice guarantees that this never happens
this is what safety is about
<Bluelive>i see it more as contract validation11:13
<bonniot>what do at runtime what can be done at compile time?
<Bluelive>very true
<bonniot>it's the same thing as static typing, only further11:14
when you can't do it statically, then yes contracts at runtime are great
<Bluelive>what are the future goals of nice ?11:17
<bonniot>for 1.0, main features are visibility and properties11:18
after that, there are ideas about a clean macro system
the package repository thing to make sharing and reusing code real easy11:19
some performance improvements, for instance with primitives
<Bluelive>sounds like a good list
<bonniot>it could be cool to have a clean, generic backend for generating code. could target different architectures11:20
and of course it all depends on who wants to contribute. we are open to new ideas ;-)
<Bluelive>ill be happy to contribute ideas and discuss features, but im not sure i want to implement11:21
<bonniot>oh, and there is the eclipse plugin in the works
that's a good start ;-)11:22
what about the code generation library? i guess you will need one too. couldn't this be something we can collaborate on?11:23
<bonniot>how does pluk generate code? and what architecture?11:24
<Bluelive>pluk generates generic C89
<Bluelive>with a few libraries for posix, linux and cygwin
i would want to do a binary assembly generator next, but i cant really find any good examples on google11:26
<bonniot>reimplement gcc?11:27
<Bluelive>the gcc toolchain has loads of stuff i wouldnt use11:28
optimizing for example
<bonniot>i mean, what's wrong with reusing gcc?
<Bluelive>except being forced into gpl ?11:29
idneed to write c code to interface with its backend
and im not sure how easily i can still compile for windows then11:30
<bonniot>you can fork a process for gcc (or any c compiler). not integrate it in your compiler11:31
<Bluelive>so still generate c, but not to fs but directly through cc into a .o ?11:32
if you want to share the code generator we would need to agree on a list of primitive actions and definitions11:37
* Bluelive leaves11:38
* Bluelive joins
soryy, that was the cat :)11:39
i would need a library implemented in Java/Nice...11:40
<Bluelive>hmz point
im wanting to go selfhosting with only the bare minimum working11:41
<bonniot>i guess that's a problem11:48
why don't you like working in a team?
<Bluelive>im stubborn about how things should work11:49
<bonniot>well, as you as you're right, you should be able to convince the others to do it like you want ;-)11:51
well thats the problem with open source
unless you have some sort of critical mass you have no position to convince others about approches
<bonniot>you mean inside a project?11:54
<bonniot>why not? you cannot *force* people, but there are always discussions about how do design the product11:55
<Bluelive>hmz, how would you do rational numbers in nice ?12:09
<bonniot>dropping the subject? ;-)12:13
<Bluelive>yup, subtle ;)12:14
rationals: type-wise, or what?12:15
i'd indeed like to add them at some point
<Bluelive>well is there a rational type and what would a literal look like
<bonniot>there would be a rational type of course12:18
literal: ideally that would be 1/2
but that poses a backward compatibility problem with integer division12:19
<Bluelive>1R/2R ?
1R/2 would do i guess
<bonniot>yes. still not very pretty
i wonder if that compatibility if a big problem, though12:20
<Bluelive>better then the string based sollution i saw for java while back
<Bluelive>well you can make literals rationals by default and demote then to integers later
<bonniot>if / is normal (rational) division, what could be int division?
<Bluelive>div ussually12:21
<bonniot>demote: yes, but explicitely?
what about // ?
just joking
<Bluelive>good joke, never make it again ;)12:22
<Bluelive>geh looks more like a logical or operator12:23
<bonniot>int(a/b) would be the orthogonal way to do it12:24
yeah, that was not serious either
<Bluelive>too few characters on a keyboard12:25
continuations ?12:28
<bonniot>do you think people would be upstead to have / as the rational division? it would certainly be the cleanest thing from a mathematical point of view
<Bluelive>it would confuse the C people, go for it ;)
it might eat a bit of preformance, and some libs might assume integer divisions so run regression tests to be sure12:29
it would allow for more advanced compiletime statics unrolling12:30
hmz, no thats not true
<bonniot>how would it lose performance? compared to what? it's not implemented at the moment12:32
int division could still be done as fast
<Bluelive>compared to integer math
<bonniot>yes, but you can still do integer math12:33
<bonniot>so if you don't need it, you don't lose anything12:34
if you need it, it's better to have it than not ;-)
<Bluelive>maybe use inference on the expression to determine the type of division needed ?
double a= 1/2 -> a=0.5
<bonniot>yes, it's possible12:35
java has special rules like that, only for literals
<Bluelive>having typing flow upstream seems a bit weird to me
<bonniot>it's powerful
hard to implement too ;-)12:36
<Bluelive>hard to understand
but intuitiv
the math people might like it12:40
" you can now do rational math in combination with exsisting javacode using nice "12:41
<Bluelive>add a few symbols to it and you can handle a few irrationals, altough that gets tricky fast12:56
add imaginaries to and go for broken ;)12:57
<bonniot>5 + 3i13:02
<Bluelive>or j for the electrical engineers13:03
<Bluelive>hand writting the parser13:05
it might not be flexible, but its more fun then using antlr
<bonniot>what's your syntax like?
<bonniot>or it is going to be a surprise (for you too) when the parser is finished? ;-)
<Bluelive>eh, no i write parts of example code and then build the parser to match the examples.
and fail on the non examples13:07
altough im not yet decided on the syntax for properties and method type definitions13:08
id rather support first class methods in a way that doesnt involve additional type definitions13:09
something like interfaces, but which you can implement multiple times with different names
sounds a bit like public member classes, that didnt really work well in java13:10
<bonniot>yeah, looks familiar ;-)13:15
* arjanb joins13:18
<Bluelive>hi arjan
i guess i could not support first class member functions, but do support delegates, but explicitly require implementing a type of delegate before allowing assignment
so then a delegate type becomes a sort of one annonymous method interface13:21
* zzorn_ joins13:27
* zzorn leaves13:30
* zzorn joins13:39
<Bluelive>btw, does yield, instead of return make the method using it into a continuation ?13:40
<bonniot>wouldn't that rather be a coroutine?13:49
<Bluelive>i must admit that i still dont understand continuations13:51
looking around google sugest stuff like biderectional exceptions and other totally noncomprehendable suggestions13:52
<arjanb>Bluelive: http://mail.python.org/pipermail/python-dev/1999-July/000467.html
* zzorn_ leaves13:54
<bonniot>my take at the moment is that continuations are an obscure enough feature to not justify compiler support. unless i'm mistaken, you can always get the same behaviour with closures if you need to13:59
<Bluelive>the example from that python thing suggests to me its abit like dataflow programming14:00
well closures may need something like a tree like stack thats garbage collected14:24
but so do continuations probably
hmz, closures might also be a nice way to write generators14:26
<bonniot>you mean like nice.functional generators.nice?14:27
<Bluelive>number two14:43
nicely done ;p
<bonniot>2? i get 414:44
Similar pages
Similar pages
Advanced Programming Language Design - $83.30
... Available on demand. Institutional and Volume Pricing. Save to My Account. Request
an Instructor or Media review copy. Advanced Programming Language Design. ...
www.awprofessional.com/catalog/product. asp?product_id=%7B92E30B39-5D91-45F9-9919-D202BE6341F9%7D - 52k - 3 Mar 2005 - Cached - Similar pages
The Nice programming language
Nice is an advanced programming language that extends Java with parametric types,
functional programming and more! The Nice programming language. ...
nice.sourceforge.net/ - 13k - 3 Mar 2005 - Cached - Similar pages
<Bluelive>ah those books, i ignore the commercial entries
<bonniot>first language, too ;-)
they are normal urls i think
<Bluelive>ego browsing ?14:48
<bonniot>funny to see referers in httpd logs14:51
<Bluelive>any nice examples ?
how+to+be+nice !!!
<bonniot>methods+outside+classes <-- pretty much to the point for a change14:54
* Tatou joins14:57
* Tatou leaves14:58
<Bluelive>hmz ?
* Tatou joins15:01
* Tatou leaves
<Bluelive>hmz, i have a pattern of statements that i might want syntax for ;))15:08
noticed that i often write something like this
boolean busy = true15:09
* Tatou joins
<Bluelive>while (busy) { busy = false; if a then {something; busy = true } if b then { somethingelse; busy = true}}
* Tatou leaves
<bonniot>yes, it's common. that can be done at the lib level i think15:22
<arjanb>how far do you want to go with adopting java syntax for generics?16:10
<bonniot>as much as possible, provided that is not problematic16:14
is there any problem?
<arjanb>i think having both T extends ... and T super ... is confusing16:15
and the only place where wildcards are useful in Nice is for local variables16:16
<bonniot>what would you use instead of super?16:17
and what about:
int size(List<?>);
<arjanb>that's just an abbrevation of <T> int size(List<T>);16:19
X super Y is Y extends X
further java syntax doesn't allow arbitrarily constraints16:20
<bonniot>as far as I know, ? is always equivalent to introducing some type parameter with a unique name16:21
the whole point is that if you don't need to use it anywhere else, ? is more concise
did I miss something?
<arjanb>that's right16:22
<bonniot>so it's not different in Nice as in Java
about super, I think the point is that the first type is the one being introduced16:25
so <X extends Y> is <X | X <: Y>16:26
while <Y super X> is <Y | Y <: X>
which is not the same thing
while <Y super X> is <Y | X <: Y>
which is not the same thing
it's a good question how to represent general constraints16:27
either still with | or something else
i'd agree not to support super in a first step16:30
maybe we can allow
<Foo extends T>16:31
<arjanb>i understand the reason for java like syntax but i don't want to make it a complicated mix
<bonniot>for introducing the type parameter T
mix with what?
especially since there is a request to not allow <String> as a way to shadow an existing class16:32
<arjanb>with the 'old' Nice syntax
<bonniot>but that could be deprecated16:34
<Bluelive>pre 1.0 and allready legacy syntax ;)16:36
* arjanb is looking up the java generics limitations
<bonniot>Bluelive: better do it now than later!16:38
allrighty, less see if i can finish the parser today16:40
<arjanb>"A wildcard can have only one bound, while a type parameter can have several bounds.16:53
A wildcard can have a lower or an upper bound, while there is no such thing as a lower bound for a type parameter.
Forward references to type parameters are not permitted. The type parameter cannot be used in the entire type parameter section, but only after its point of declaration."
<bonniot>3rd is normal16:56
1st: i think we don't need that16:57
how does a TP get several bounds?
T extends Foo & Bar ?
but both upper and lower isn't possible
<bonniot>in Nice we can16:58
we don't need to copy their restrictions ;-)17:00
<bonniot>i wonder why ? extends A&B poses problem
<arjanb>their typesystem is minor extension to the variances one in the prototype17:01
afaik ? extends A was +A then17:03
so the problems left are readable multiple bounds and good rules for how type params are introduced17:04
A extends T extends B doesn't look good to me17:09
<bonniot><T | A extends T, T extends B> ?17:11
does Java 5 accepts <String> ... ?17:13
* zzorn_ joins17:20
* zzorn leaves17:32
<Bluelive>arjanb: that article you posted, its author makes loads of great remarks on the python list, thanks for the link18:27

Generated by Sualtam