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

Using timezone: Central European Time
* CIA-3 leaves01:49
* CIA-3 joins
* bonniot leaves04:26
* CIA-3 leaves06:45
* CIA-3 joins
* CIA-3 leaves08:16
* CIA-3 joins
* arjanb joins11:32
* bonniot joins13:00
shouldn't the testing things that bryn has put in be moved to testsuite/lib13:22
and the license in using.nice is different13:24
<bonniot>for testing: no, we should only use the testsuite for things that cannot be tested by unit tests13:30
this way the tests are closer to the code they test, so they can evolve together13:31
and this is the way users can test their own code
license: right, it should be the same (linking exception)13:33
i'll write to bryn
<arjanb>idem for nice.functional13:34
* bonniot leaves14:02
* bonniot joins14:05
* CIA-3 leaves15:03
* CIA-3 joins15:04
* CIA-3 leaves15:45
* CIA-3 joins
03bonniot * 10Nice/ (2 files in 2 dirs): Fixed a typing bug for abstract interfaces with type parameters.16:00
* CIA-3 leaves17:18
* CIA-3 joins
<CIA-3>03xoltar * 10Nice/stdlib/nice/ (3 files in 2 dirs): Fixed license headers.18:33
i totally dont get xoltar's generaters
<bonniot>did you read his short article?19:18
(have you ever tried a lazy language?)
<Bluelive>i read some thngs he posted on his weblog, with a few examples, never worked with a lazy language19:19
<bonniot>yes, i was speaking about the weblog19:20
you don't see the interest, or you don't see how it works?
<Bluelive>the first part of the example i get (although i think it breaks scope19:22
but then there spring all sort of methods on the generator into exsistence
<bonniot>scope: these are the normal lexical rules for closures19:23
methods: map, filter, ...?
i guess they are standard functions available in lazy languages ?19:24
<Bluelive>a then i understand a bit better
<bonniot>they are defined in his library19:25
so it's the names that are confusing to you?
<Bluelive>the 'var int num' makes it a instance field on the class with a private view to the method ?
well the type is ()->int, which says delegate/function pointer to me, having methods on it just seems a bit weird to me, as you cant really create a class of the type19:26
<bonniot>logically, it's a local variable of the method
that's a class centric point of view :-)19:27
(your last comment)
<Bluelive>just translating to concepts im comfortable with ;)19:28
but you see this is a low-level point of view, or one some values (objects) are treated as a special case19:31
in Nice, a method operates on several values, that's simple
and everything is a value :-)
<arjanb>closures are strange the first time you see them but become soon intuitive when using them
* ChanServ leaves20:53
* ChanServ joins20:55
<bonniot>arjan, what are you up to these days? did you start that parser idea?21:28
<arjanb>well i'm a bit reluctant to start bigger things21:34
<bonniot>lots of work at uni?
<arjanb>no this week nothing at all21:35
<bonniot>it's a cool uni!21:36
<arjanb>just an exam week and i don't have one21:37
<bonniot>ok :-)
<arjanb>so do you know some smaller things?21:41
and what is the release schedule?21:43
<bonniot>i'm waiting for the constructors discussion to settle down21:44
it's better not to release it if we might still change that feature
of course we could release 0.9.6 and not document it :-)21:45
smaller things, let me think...21:46
there is still that feature to set the per-package policy for importing Java types21:47
expression variables (is that a bigger thing?)21:48
<arjanb>for constructors i don't have any ideas more
<bonniot>yes, but we are still discussing with Brin on the wiki
<arjanb>i'm looking at exp vars now
<bonniot>and somebody else said he would send an email
ah ok, great21:49
<arjanb>but i'm not sure about the syntax
type ident = ... can look quite similar to an expression21:50
<bonniot>well no, becuase of the type21:52
<arjanb>but it would require a non fixed lookahead21:53
<bonniot>we have semantic lookahead already
LOOKAHEAD(type() ident())
<arjanb>i have a bad feeling about this one22:01
<arjanb>because it's the only sematic lookahead i can't avoid in my parser experiments22:04
<bonniot>did you already write a prototype?22:05
<arjanb>just some tests22:07
a<b> c looks very similar to a<b<c22:09
<bonniot>it's unambiguous when there is a keyword:22:10
using(val x = ...) { ... }22:11
<arjanb>right what about not allowing the case without a keyword (at least for now)?22:12
<bonniot>would be fine for me
<arjanb>so (let|var) [type] ident = expression
only i'm not sure if we should allow 'val' too22:13
using(let x = foo()) { ... }
sounds a bit strange
<arjanb>making val a keyword could break quite some code22:14
but we're not Java either :-)
<arjanb>val is a typical local variable name
<bonniot>better now than later if we must do it
<bonniot>and true too (your point) :-)
you can always implement the feature, that point can be changed easily22:16
wouldn't it be possible to accept val here without making it a keyword?22:17
<arjanb>tricky but could be possible22:18
but if let can be replaced with val in this case why not in all cases?
<bonniot>well, let makes sense in a statement more than in an expression22:20
<arjanb>to me val or let don't make a difference in making sense22:24
but let is easier distinguishable from var22:25
<bonniot>the difference is that "let x be ..." is a whole sentence in english22:48
so it is logical to use it as a statement22:49
but: "using let x be ..." is incorrect
anyway, we'll ask for other opinions
<arjanb>value 'x' is ...22:50
<bonniot>yes, val can make sense as a statement22:52
what i'm saying is that let does not as an expression
<CIA-3>03bonniot * 10Nice/src/bossa/parser/Parser.jj: Minor: removed useless tests.22:55
<bonniot>for (i:0..e.length) e[i].zero;23:29
that will do a bound error, no?23:30
<arjanb>yes .. is inclusive
<bonniot>in this case it can be23:32
for (x:e) x.zero;
but the other case cannot, because there are two arrays
<arjanb>where do you refer to?23:45
<bonniot>it's Isaac's rings23:51
<CIA-3>03bonniot * 10Nice/src/bossa/parser/Parser.jj: Allow X <: Y <: Z in constraints.23:54
<arjanb>it's a mutable data structure so you can't use something like e = e.zipWith(o.e, (a,b)=>a.plus(b));23:58
<bonniot>well, it looks like you could create a new array if you want23:59
if I understand the problem, you actually need to anyway
if o.e is longer than this.e
<arjanb>right isaac simplified it compared to the original c# code00:05
<bonniot>ah ok00:06
I didn't look at the original
i'll send a work-around for that example tomorrow, still needs some bug fixing ;-)00:07
good night00:27
<arjanb>good night
* bonniot leaves00:31

Generated by Sualtam