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

Using timezone: Central European Time
* bonniot leaves03:30
* arjanb joins11:11
* bonniot joins11:19
hi11:23
<arjanb>hi11:26
<bonniot>do you have plans for now?11:43
<arjanb>a have a few other things to do first but i think i will try expression local variables11:45
<bonniot>ok
have you ever used Dylan?12:57
<arjanb>no but i have browsed through the manual13:12
that's where i have the idea of overloaded constructors from
<bonniot>do you have an idea how they would implement the new Point example?13:13
<arjanb>no
<bonniot>the simple approach loops13:15
i thought it might be with next-method (super), but I can't get that to work
it's still an idea for us, to use super
for instance:13:18
new Point(x,y) = cache.get((x,y)) || super;
instead of
Point(x,y) = cache.get((x,y)) || new Point(x, y);13:19
but that does not help for origin, for instance
<arjanb>var ?Point origin = null13:26
new Point(x,y)
{
if (x==0 && y==0)
return origin || (origin = super);
return super
}
<bonniot>yes, but that makes origin mutable13:28
but what about:13:29
new Point(0,0) = origin || super;
<arjanb>maybe we need getter and setters for global vars too
<bonniot>it's more general if that method can be defined in a different package than origin13:30
i think this last solution works
it's just strange because origin is not supposed to be null
but i'm not sure there is any way to handle recursive global values with acknoledging they might not be initialized13:31
how does that sound?13:36
<arjanb>wdym?13:37
<bonniot>(allow super, and have only one kind of constructor call)
<arjanb>better than the other proposals13:38
<bonniot>do you see any problem with it?
<arjanb>only in case the constructor is overloaded twice with the same signature13:40
<bonniot>you mean same bytecode signature, or same param names too?
<arjanb>same param names13:41
<bonniot>and what is the problem
<arjanb>where does super point to then
<bonniot>that's not specific to constructors. think about doing the same with methods
<arjanb>right13:44
<bonniot>so it's a separate issue
we'll have to deal with that too, but that's for later13:45
<arjanb>the open problem left is syntax CC vs OC
i thought of using the same syntax and inside a class it's an CC and outside an OC13:48
<bonniot>that would prevent CCs outside the class, in a different package...13:49
it could also be good to have a clear syntax difference:
a CC must compute values for fields and call this(...),
while an OC must return a value13:50
that's very different, so it should be obvious which one you are doing
any proposal?13:55
<arjanb>not yet13:56
<bonniot>we can postpone the syntax debate and ask for proposals and comments13:57
let's write new Point(...) for OC and Point(...) for CC, just so we know what we are talking about :-)13:58
semantically, the use of super only is less general than before, because it does not allow arbitrary code to be sure to create a new instance13:59
but that can be a good feature: if you design a caching system, you might want to make sure people don't create new instances by accident14:00
<arjanb>the syntax for OC is good only the choice between this(...) and new(...) isn't made so the difficultie is make OC looks different14:01
<bonniot>(you can always write a new OC and call super if you _really_ want to, and limiting the visibility of the constructor would even allow to prevent that)
<arjanb>super is quite a good solution is if someone finds a better one we can reconsider it14:02
<bonniot>sure :-)
i don't understand how this(...) or new(...) affects the syntax of OC?14:03
<arjanb>this(...) or new(...) can only be inside OC14:04
<bonniot>no, inside CC
<arjanb>right i meant CC14:05
<bonniot>ok, so what is your point again?14:06
<arjanb>if the last known bug case of CC is solved then the CC feature could be announced in nice-info for testing and maybe that will help the feedback for OC14:11
<bonniot>yes
the Wiki info should also be updated to present our current proposal for constructors14:12
(btw, it's not really a bug, it's more like an unimplemented feature :-)14:16
<arjanb>true
and why are CC implementations given a dummy argument even when there is no ambiguity?14:18
<bonniot>because that's how the default constructor can be reloaded from a compiled package at the moment14:19
that could/should be done differently, of course14:20
<arjanb>it makes a difference when using from java14:21
<bonniot>i know
i'm planning to implement the subclasses first, as I think it's more urgent14:22
(a bit tricky too)
i'm discussing with a dylan guy...14:57
so that's it :-)15:53
<arjanb>your conclusion?15:55
<bonniot>they have a problem with global values!15:57
and it's quite a pain have your program fail silently
but for the design, I see that they indeed use super too, and that looks good15:58
you?
<arjanb>i can't follow everything16:04
<bonniot>in your new retypings for Collections, why are synchronizedCollection and friends contra-variant? that seems unsafe to me16:56
<arjanb>right they should non-variant16:57
<bonniot>yes
singleton are unmodifiable too it seems, so that's ok16:58
i'm not sure i like all the other contra-variances17:01
for instance replaceAll
the value to replace should also be a T, since it is inside a List<T> list
<arjanb>it's the same with contains, remove, indexOf17:03
<bonniot>yes17:12
what would be the problem with expecting the user to check the type before the call?17:15
?17:33
<T,U | T <: U> List<U> singletonList(T)
can be simplified to
<T> List<T> singletonList(T)
since that is equivalent
<arjanb>right
<bonniot>idemt for ListItaretor.add17:34
.set17:35
Comparator should be declared as a contravariant class17:38
that would simplify many methods, and be more flexible
<arjanb>maybe17:41
<bonniot>arjan, please, please, give arguments when you say things like this, or you can we discuss?17:52
<arjanb>sorry i had to look first whether there are cases where contravariant is possible17:59
<bonniot>ok. it's a good idea to let me know, then :-)18:07
wdym, "contravariant is possible"?
<arjanb>there are more classes that look contravariant at first sight but aren't in some usages18:09
<bonniot>Comparator is contravariant, that's a simple fact you can see it is definition: T only appears as an argument to its methods, never in the result18:10
examples?
<arjanb>java.lang.ref.Reference18:14
<bonniot>in Reference, T appears as a result in get18:15
so it cannot be contravariant18:16
<arjanb>covariant in case of reference18:17
<bonniot>ok
and why is it not safe?
<arjanb>hmm i don't why anymore18:20
<bonniot>it does look covariant
(get should return an option type, but that's a different aspect)18:21
if the value cannot be modified (besides being cleared), then I think it is indeed covariant18:22
<arjanb>how should i retype the SortedSet.comparator() method18:23
<bonniot>if comparator is made contravariant?18:24
<arjanb>yes
<bonniot>let see18:25
now it is:
<T,U | U <: T> ?Comparator<U> comparator(SortedSet<T>) = native Comparator SortedSet.comparator();
<arjanb>that's incorrect
<bonniot>y?
i think it's correct18:26
the result is a Comparator<T> (something that can compare values of type T) for sure
<arjanb><T,U | T <: U> TreeSet<T> TreeSet(Comparator<U>) = native new TreeSet(Comparator);
this is the old constructor
<bonniot>but if you want to consider it as a Comparator<U> for a smaller U, that valid. if it can compare Ts, it can compare Us18:27
(it it can compare Widgets, it can in particular compare Buttons)
with a contravariant Comparator, you can simply say:18:28
<T> ?Comparator<T> comparator(SortedSet<T>);
everything will be simpler
<arjanb>and the constructor then?
<bonniot><T> TreeSet<T> TreeSet(Comparator<T>)
basically, you were expressing the comtravariance of Comparator in all the methods using it18:30
if you declare the class as contravariant, it's so much simpler :-)18:31
<arjanb>the retypings become simpler but i find it harder to understand
<bonniot>i think you are just confused by the old retypings
<arjanb>covariant things looks natural to me but contravariant not18:32
<bonniot>you are trying to make sure that both forms are equivalent, right?
ok, let's explain that
a Comparator<T> is something that, given two values of type T, tells you which one is smaller, right?18:33
<arjanb>yes18:34
<bonniot>so, if you have a Comparator<Widget>, you have something that can compare buttons
sorry, ... compare widgets :-)
if it can compare all widgets, it can in particular compare button widgets, right?18:35
<arjanb>yes18:36
<bonniot>so, your comparator is something that can compare all buttons. Hey, that means it is a Comparator<Button> !
we have just proved that every Comparator<Widget> is also a Comparator<Button>18:37
this means that Comparator<Widget> is a subtype of Comparator<Button>18:38
<arjanb>i understand this
<bonniot>and this was true because all Buttons are Widgets. that is, because Button is a subtype of Widget
<arjanb><T> TreeSet<T> TreeSet(Comparator<T>)
<bonniot>the same reasoning goes for every type T and U such that T <: U18:39
ok
now what this says is that a TreeSet<T> needs something to compare Ts
it needs a Comparator<T>
right?
<arjanb>here i get confused because is it T before or after contravariance is taken in account
<bonniot>you are complicating things. it's T that's all18:40
a TreeSet<T> needs something to compare Ts, agreed?18:41
<arjanb>yes but i tend to look at things how they work on the inside18:42
<bonniot>that what I call complicating things :-)18:43
it's a good thing to do to understand how things work
<arjanb>i need to undo an old hack before i can make comparator contravariant18:45
F:\Nice\stdlib\nice\lang\collections.nice: line 179, column 12:18:47
T is not declared
class NiceComparator<-T> implements java.util.Comparator<T>
{
final (T,T) -> int comparator;
<bonniot>that's your hack, right?18:49
<arjanb>yes18:50
<bonniot>either we temporarily restore the unsafety, or we need to implement the variance checks18:51
<arjanb>the first i think18:58
<bonniot>ok with me
<arjanb>class typeparam variance isn't documented so problems won't happen18:59
<bonniot>agreed19:02
<arjanb>expression local variables are not for today23:39
do you have the use of an CC in superclass working?00:05
<bonniot>no00:08
* Bluelive joins00:22
<bonniot>hi00:24
<Bluelive>ellow
<arjanb>back with questions?00:26
<Bluelive>you make it sound like a bad thing00:27
;)
no
just the start of a boring weekend and was wondering if there were developers alife
<arjanb>:-)
<bonniot>what about a thrilling we instead? :-)00:28
we = week-end
<Bluelive>depends on what would make it thrilling
<bonniot>you choose!00:30
<Bluelive>you cant make me ;)00:31
still a bit worried about some c++ i wrote at work00:32
i really need a good faq about lieftime of objects
<bonniot>btw, i got an answer from frank, he is still working on nicedoc :-)00:41
<arjanb>without access to the docstring?00:42
maybe it's time to discuss some nicedoc design things with him00:44
<bonniot>i told him the support was almost ready00:46
but having the docstring yet or not should not change much in the design, it's just one more info to attach
we had some discussion by email00:47
it could be done on nice-devel
<arjanb>true but i'm just curious to the design
<bonniot>and if you have ideas, you can put them on the wiki page00:48
i'll leave you now. good night
<arjanb>good night00:49
* arjanb leaves
<bonniot>good night Bl
* bonniot leaves
<Bluelive>and thus the boredom starts00:56