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

Using timezone: Central European Time
<bonniot>back00:00
arjanb: i've been looking at allowing polymorphic let without explicit type
properties should also be implemented00:01
and i hope that somebody can work on a visibility library, that can then be used to implement visibility
<Bluelive_>http://cal018000.student.utwente.nl/wakka/wakka.php?wakka=ForeachStatement00:05
is this a bit clear ?
im totally not sure that this is understandable
<bonniot>it is00:11
sometimeS
implicit typing is useD
what does "Specifying the type adds to the type checking" mean?00:12
* arjanb leaves00:20
* arjanb joins
polymorphic let is that including polymorphic vars?00:32
<bonniot>you mean 'var x = ...' ?00:36
<arjanb>yes00:37
<bonniot>(wow, i wonder how i got that reversed mark !)
why?
<arjanb>just thinking wether that's useful or even possible00:39
<bonniot>why not possible?00:41
<arjanb>i guess you could tricky cases
<bonniot>it's a well known theory00:45
you must not allow the type variables to be instantiated to different values
then it is safe
<arjanb>i see00:49
* arjanb leaves02:15
* bonniot leaves03:24
* arjanb joins11:15
* CIA-3 leaves11:19
* CIA-3 joins
* bonniot joins11:36
<arjanb>daniel some text is missing before "i have used the JavaCC" in your blog14:38
<bonniot>fixed, thanks14:41
missing "
which shows that it's much better to report an error than to silently ignore it...
* fcb joins14:51
<arjanb>hello14:57
<fcb>hello15:00
how are you going?
<arjanb>good15:02
<fcb>excellent :)
I'm the nicedoc person, by the way
Daniel mentioned that I should come on here a couple of nights ago15:03
<bonniot>hello Frank!15:04
<fcb>Hi
<bonniot>how are you doing?
<fcb>good thanks, you?
<bonniot>great!15:05
at the moment i'm looking at allowing 'let x = ...' in all cases (when there are type parameters)15:06
<fcb>well, I've got cvs working and I'm just starting to get my head around the code again
<bonniot>:_)
what are your plans?
progressively improve the code? or a rewrite?15:07
<Bluelive_>is the nice doc part of the compiler or seperate ?15:08
<fcb>I don't normally go for a full rewrite unless things get drastic
having said that, the code is pretty awful at the moment
<bonniot>fcb: agreed, that's my approach too. i just thought you mentioned a rewrite earlier
Bluelive_: nicedoc uses the core compiler for parsing and resolving names. it has a separate frontend and documentation generator15:09
<fcb>my understanding is that nicedoc uses the compiler for parsing, but isn't actually part of it - is this right daniel?15:10
<bonniot>depends by what is meant by 'part of it' :-)
<fcb>you (daniel) suggested a couple of changes previously, so I'd like to incorporate them15:11
and work on improving the code at the same time
<bonniot>in my view, it's that there are libraries (packages) to manipulate Nice source files, and tools can be built upon then (compiler, editor, nicedoc, ...)
fcb: sounds good :-)15:12
<fcb>fair enough
<Bluelive_>im working on something similair for alpha atm, but im not sure if i should just first output some xml document that just contains the information and write a second tool to make some formatted htmll15:13
<bonniot>it's logical, but i don't think this modular approach is used as much as it should in the real world
by using multi-methods, we should be able to move code generation outside of the core compiler, and get a truly modular framework ;-)15:15
<fcb>I've just gone straight to html, mainly because I don't have enough knowledge of xml, but I think the xml approach is probably better
<bonniot>producing xml might be an unecessary intermediate step. once you have the info in memory, you can process it to different backends15:16
<Bluelive_>well it would make indexing and automated searching much easier
<bonniot>xml would basically be a serialization of the info in memory
<Bluelive_>(and in case of alpha the xml might allow some compiles to be faster because we dont have to recompile its source but just take its allready resolved interface15:17
<bonniot>fcb: are you familiar with stylesheets?
<fcb>yes, absolutely15:18
<bonniot>i guess they would be a good idea to keep the html straightforward, and use stylesheets for formatting15:19
but anyway that's not the first thing on the agenda ;-)
<fcb>yes, I really like stylesheets - good fun for users as well to allow customization15:20
<bonniot>btw, i already wrote the small glue to integrate nicedoc with maven. so when generating a site for a package, nicedoc is called automatically and the output linked to15:21
you can see an example at: http://packages.sourceforge.net/info/nice.swt/
Link= JavaDocs
<fcb>Link= JavaDocs ?15:22
<bonniot>on that page, you have to click on "JavaDocs" to see the docs
<fcb>oh, yes, very nice15:23
anyway, I've got work in the morning - is there a regular meeting time on here?15:25
<bonniot>what is convenient for you?15:26
i think we are mostly there in the afternoon and evening/night GMT15:27
<fcb>well, seeing as I'm +8GMT, about the latest I can really do it is 14:00GMT15:28
<bonniot>which is about now, right?
<fcb>(need to be going to bed about 15:00GMT)
yep
<bonniot>for instance today i was here at 10:30 GMT15:29
from then to now...
<fcb>yeah, ok, so basically I'll just drop in breifly in the evening15:30
<bonniot>sounds fine :-)
<fcb>(my evening)
cool
ok, see you all later then :)
<bonniot>ok, good night!
* fcb leaves15:31
* magnus-- joins16:21
hi16:29
<arjanb>hi16:30
how is your project going?16:31
<magnus-->I got too busy, too many labs (cause i was studying too many courses at a time) so I abandoned it16:33
<arjanb>i see16:35
<magnus-->I'm thinking about inheritance16:42
<bonniot>hello magnus16:43
<magnus-->if one could redefine methods on member variables, there would be no need for inheritance
<bonniot>sounds like prototype based languages16:44
that'll only work for single-dispatch, though
<magnus-->I knew this was the place to ask:)16:45
an example would be16:47
class Superhero {
String whoami() { return "some superhero"; }
}
class Superman {
Super super {
String whoami() { return "Superman"; }
};
}
Another problem I can see is if you want to assign Superman.super to some other Super
<bonniot>what is 'Super' ?17:08
<magnus-->Sorry, should be Superhero17:09
<bonniot>that needs some special handling, no? so this is some weird kind of inheritance. what is the advantage?17:21
<arjanb>magnus: have you taken a look at the Self language?18:00
* CIA-3 leaves18:09
* CIA-3 joins
<magnus-->http://slate.tunes.org this language seems to combine prototype OO and multiple dispatch21:49
<arjanb>both dynamic delegation and multiple dispatch, haven't seen that before21:56
<bonniot>seems to be a successor of self and smalltalk22:53
does addSlot modify objects at runtime? if so, i guess it is quite flexible, but you have no guarantee of safety (and get a performance penalty...)22:54
<arjanb>yes very flexible but hard to reason about22:55
* CIA-3 leaves22:56
<magnus-->This is odd because I thought the tunes project want a language that you can prove things about programs in
* CIA-3 joins
<arjanb>i think the dispatch rules are too complex: http://slate.tunes.org/doc/progman/node8.html#SECTION0003330000000000000023:05
<bonniot>yes, it's very complex23:22
both confusing, and very hard/impossible to implement efficiently
<Bluelive_>magnus-: hasnt godel proven that something like that isnt possible todo for all programs?23:36
<magnus-->Yes I guess so... but it may be possible for some programs?23:39
They are mainly concerned about security
<bonniot>i thouhgt it was about metaprogramming23:40
<magnus-->I mean for the proving
But I may be wrong
<Bluelive_>security can be guaranteed by sandboxing
nice can be run like that in a jvm, in an applet context for example23:41
<arjanb>http://www.cincomsmalltalk.com/blog/blogView interesting blog especially the java vs smalltalk posts23:53
<bonniot>arjanb: don't you want to start blogging? ;-)00:07
<arjanb>not really because i first need to learn to express myself better00:11
<bonniot>learning comes from practice ;-)00:12
<arjanb>true00:13

Generated by Sualtam