<sneek> 22:12:16 up 49 days, 23:08, 0 users, load average: 0.00, 0.01, 0.05 ***fangism is now known as fangism-hawngry
<taylanub>looks like bipt pushed the latest state of the guile-emacs repo :) <nalaginrut>taylanub: last year I can work on it, but sometimes halt, how about now? ;-P <taylanub>nalaginrut: startup time reduced since it really uses Guile to eval Elisp now! bipt said Stefan Monnier (current Emacs maintainer) wants to test it out. <taylanub>nalaginrut: (do you mind if I correct your English? "last year I could" would be correct) <nalaginrut>I'd love it, Guile would make me love Emacs more <nalaginrut>since I'm not a native English user, there maybe many ridiculous grammar bugs <nalaginrut>taylanub: and it's appreciated a lot, please don't hesitate to point it out ;-) <homo-eroticaXL>taylanub, I would go so far as to say "I was able to work on it" <nalaginrut>yes, it sounds like "I was able to help to work for it" ***homo-eroticaXL is now known as LordProtector
***LordProtector is now known as McBurgerMc
<dsmith-work>My internet seems to be down at home. No sneek for a while. :( <janneke>one most brilliant guy in my team that i am trying to move from c++ <janneke>was so much inspired by my move to guile that he started workin on our core problems <madsy>janneke: Move someone from C++ to what language? <madsy>As an absolute replacement, or only for a specific task? <janneke>however, he complains about lacking eclipse and debugger support <janneke>(that's why all my emacs/guile/debug patches) <janneke>i converted 65.000 loc of c++ to 2500 lines of Guile <janneke>and also, he complains about compile-time strict typing <madsy>Yeah, the debugging issue is a good one <janneke>and compiler support wrt typing mistakes, type-safety <madsy>I like guile for prototyping, but not for actual code I want to deploy <janneke>so now he is proposing and pulling a move from Guile to Scala <madsy>Because dynamically typed languages does the type checking in runtime. <madsy>The only way around that is to make really tight coverage tests <madsy>davexunit: I didn't mean to claim it isn't. <janneke>i have about 82% coverage for my guile code <janneke>the C++ code has about 5% coverage (and strict typing support) <madsy>Nor did I mean to start a battle. janneke asked me for my reason <janneke>i am fairly blonde about scala or strictly typed functional languages <janneke>davexunit: i don't want a battle, i want to hear some perspectives <janneke>davexunit: i have that sentiment too: "boo" <davexunit>if you lose the battle for guile, try to adopt Clojure over Scala. <janneke>davexunit: but i need something "better" to convince someone who boo's Guile for lack of strict compile-time typing? <davexunit>yes, and i'm not sure what to suggest to you. <madsy>janneke: Well, you could appeal to making proper unit tests and coverage tests. Or that it's possible to make your own typing system in guile. <davexunit>yeah, you'd have to find or write a type system. <janneke>davexunit: i wonder about the latent typing thing... <boycottg00gle>is there any paper with hard facts about number of bugs caught with compile time type checking? <janneke>i know that values are typed, rather than variables... <janneke>but what if you would restrict yourself to: one variable, one type? <janneke>(possibly elevate nil or #f to be any type) <janneke>who needs or wants (define a "boo") .... (setq a (lambda (x) 'bla)) <davexunit>(define/typed (foo (string? bar) (number? baz)) ...) <boycottg00gle>was hard core c++ coder myself and used the the compile time type check argument myself / after conversion I doubt it really is that important especially if you see plopping up bypassig mechanisms all the time <janneke>davexunit: define/typed? is that something? <janneke>davexunit: i meant: what if you dropped that possibility of a variable changing types <davexunit>boycottg00gle: I don't know of any hard evidence. I also don't know if evidence either way would convince many people. <janneke>couldn't you compile to .go with errors/warnings about types? <boycottg00gle>davexunit: when i started to switch from c++ to scheme i was worried <davexunit>but for a lot of cases, you will not know what the types of your variables are until runtime. <janneke>it seems to me that it would be *so* nice if you could use strong compile time typing if you choose, and ignore it if you don't care <madsy>davexunit: I'm always open to evidence. I'm open to try extended type checking for lisp-languages just as I'm open to try it for statically typed languages. <janneke>(...that's where C++'s auto foo = ssomething (); seems to be going ...) <madsy>The goal is to squash bugs and preferably prove the code correct. <janneke>boycottg00gle: is there any paper about agility and KLOCs? <janneke>boycottg00gle: i.e., maintainability? <janneke>I reduced our codebase by 95% and people say: "I don't care, I like some redundancy" <davexunit>janneke: the problem is that guile is dynamic, and you can't prove certain things at compile time. <davexunit>if you were already using a dynamic programming language, it would still be hard. <davexunit>because people are afraid of all those parens <janneke>davexunit: i can't see right through that, .. but I imagine that you could do more than we do now? <janneke>and i was afraid of those parens too <janneke>i have learned to love them, with paredit.el *janneke is very happy with the support here <madsy>I'm currently investigating Coq and Idris. They're a bit annoying to use, but if one likes design-by-contract and code proof checking, it's pretty good. <davexunit><foo>bla bla</foo> <!-- comforting and familiar --> <madsy>People shouldn't care about syntax, but they do. It's about familiarity *janneke wants to run and hide and play ostrich <janneke>madsy: shouldn't are useless, do's ar interesting <janneke>so...no compelling arguments against Scala ... nalaginru? <davexunit>I can't argue against scala because I've never really used it. <davexunit>I looked into it once and found if off-putting <janneke>it has strong typing at compile time <janneke>it supports pattern matching natively <janneke>and with strong typing+native pattern matching, you can do nice things <madsy>Strong static typing is kind of boring in my opinion. Extended Type Checking (ESC) is what's interesting :) <davexunit>yeah, the eclipse stuff is because it runs on the jvm <davexunit>janneke: is its pattern matching as good as scheme's? <janneke>i personnaly don't care about eclipse <janneke>what i really miss in guile/scheme is the differentation between tuples and lists <janneke>i would love [] or () to mean: list/tuple <davexunit>'(#(0 0) #(10 10) #(20 20)) ;; a list of "tuples" <madsy>Clojure uses [] for vectors. It helps split up the code syntax somewhat. <janneke>but a *list* usually means: guaruanteed to be of *one* type <janneke>and you can write functions that take a *list of string* <janneke>guile only has 'tuples that can be extended' <janneke>(and tuples of fixed size; i.e. vectors) <davexunit>I don't think it usually means that, lists can easily be heterogenous <janneke>in Scala lists are homo-lists, tuples are fixed-size, any type <janneke>Scala has a data-type that looks a lot like Scheme's list, but it can only be of one type <janneke>then you can write functions that take those types <madsy>janneke: But if you want a homogenous list, can't you just make an insert function which checks that before inserting? <janneke>madsy: it's about the functions that work on those lists <janneke>madsy: you can have your compiler warn you that the function gets the wrong type <madsy>Right, so still compile-time <janneke>(define (foo (a <symbol>) (b <number>) (c <string>) ...) <janneke>and have the compiler complain if you call foo with something else <boycottg00gle>you meant "but a *list* usually means: guaruanteed to be of *one* type" <davexunit>boycottg00gle: that s-exp sounds like could be in "the little schemer" <janneke>boycottg00gle: tuples can be nested too <boycottg00gle>janneke: so in your example it is a tuple of strings or tuples? <janneke>boycottg00gle: not sure if there's a "list of string-list" type <janneke>boycottg00gle: i think everything is written as "constructors" <janneke>maybe wingo has some good arguments against/Scala / for Guile ;-) <wingo>there are good arguments all ways :) <janneke>thought that i had 3 of my team moved from C++ to guile <davexunit>it's hard to convinve people to use a niche scheme implementation instead of a widely popular language. <janneke>now one of them commits mutiny and starts to suggest Scala :-( *janneke wonders if he should just join a group of people who love guile in the first place <wingo>scala is a jvm thing, which makes me twitch <davexunit>wingo: why does it make you twitch? don't sweat it if it's a long answer. :) <janneke>davexunit: yeah...well...i also need a way to pay my bills <davexunit>janneke: of course. no one's ever paid me to write guile. <wingo>davexunit: it's really heavyweight, and has a big startup time penalty <wingo>well-engineered but not really part of the world i want to live in ;) <davexunit>wingo: ah okay, I've heard those reasons from others as well. <davexunit>guile master starts up lightning fast, I've noticed. <janneke>wingo: it has very nice eclipse integration and debugging support <janneke>goess a long way in the corporate world... <janneke>(that's why my debugger/emacs integration patches) <janneke>wingo: also, scala has compile-time strong typing and built-in pattern matching <janneke>so any function looks like a goops-style function where parameters are pattern-matched by using their constructors <davexunit>do they define pattern matching the same way that we do? <janneke>i am hoping that moving my code to goops and writing eclips support (after the emacs support has been integrated) is going to hold scala at bay <janneke>say, case class OnStat(event: String, stat: Guarded) <janneke>then you can construct an OnStat using: OnStat ("a string", <a Guarded--whatever that is>) <janneke>def foo (statement: Statement) = statement.match { ... } <taylanub>janneke: it sounds like you're missing static typing in Scheme; have you looked into Typed Racket? (so you can help port it to Guile :P) <janneke>i.e., it uses the just-defined constructor to guarantee type-safety <janneke>taylanub: i'd have to look into that <janneke>taylanub: don't know about typed racket <janneke>i would like to have something like goops: use static typing if you want and ignore it if you don't...without using goops <janneke>and with more helpful compile time error messages if you do use it <janneke>that, or I should learn a way to convert people away from the idea of type safety *janneke personally is happy with guile <janneke>taylanub: it provides pattern-matching-like functionality at function-level <taylanub>I mean GOOPS and static typing are orthogonal <janneke>taylanub: yes, it's not static, but at least typed <taylanub>it just provides a type *hierarchy*, Scheme values already are rather strictly typed <janneke>(define (foo (a <top>) (throw "barf"))) <janneke>(define (foo (a <string>) <do something useful>)) <janneke>taylanub: how to do this without goops? <taylanub>ah, that just seems to be the syntax used by GOOPS, it's not intricately related to GOOPS if I'm not mistaken <taylanub>if you want static typed Scheme you'd bake it deeper into the language I think *janneke would love to use that without goops <taylanub>GOOPS just uses that syntax for dynamic type-based dispatch, not static typing. one could use the same syntax for static typing, but that's just incidental so to say <taylanub>(correct me if I'm wrong on GOOPS, I never really used it or know it well) <janneke>yes, but dynamic dispatch already solves half of the request, I feel <boycottg00gle>janneke: couldn't follow your thinking above - i ended up in "he wants to use it but doesn't want to use it" <mark_weaver>janneke: fwiw, if you feel that static typing is important to winning your argument, I'd also suggest looking at typed racket. <mark_weaver>I'd be in favor of adding something like that to guile, but it probably won't happen fast enough to help you right now. <mark_weaver>as for why we can't restrict all of our variables to a single type, the problem really arises when dealing with things ike generic list manipulation procedures, like 'map'. <mark_weaver>'map' contains variables that refer to individual elements, but we cannot restrict that to be of a single type, or else we'd need a separate 'map' for every type. <mark_weaver>ditto for a large number of other procedures in our standard library. <McBurgerMc>How does typed racket do that? Is that parametric? <mark_weaver>the author just mentioned it in passing on guile-user a few hours ago. <wingo>very neat, i will have a look <wingo>what are you hacking on these days, mark? <mark_weaver>I just got finished with the big housing move, and what little hacking I've done recently has been on GNU Guix so far. <mark_weaver>but I have a big Guile TODO list that I hope to start working on soon. <wingo>is "rewrite psyntax" on that list? :) <mark_weaver>actually, I have been thinking about that very thing. *wingo tries skills of liminal suggestion ;) <wingo>it's more than subliminal, you see <mark_weaver>among other things, I'd really like error messages to include the history of local macro expansions. <wingo>and a stack of source expressions! <wingo>and source locations for everything, even raw symbols! <wingo>master has a couple failing tests, related to source locations -- and it's because of psyntax <wingo>(and because the compiler should be a bit better at reifing source info but if everything had source info that wouldn't be necessary) <mark_weaver>the other thing I'd like to do is finish my "fixing-letrec-reloaded" work and get it in finally. <mark_weaver>I have a working patch from ages ago, but never posted it for a few reasons. <wingo>well now at least in master you have ~unlimited stacks :) <wingo>for that scc code anyway, if that's useful <mark_weaver>the main one being that it would effectively rearrange the order of inits to do the right thing, thus encouraging sloppiness and incorrect letrecs. <mark_weaver>yes, I need to rewrite the scc code to be less gross, thanks to the expandable stacks. yeah! :) <mark_weaver>and finally, I wanted to generalize the algorithm to support 'define-values' efficiently. <mark_weaver>I'm really torn on the time frame for the 2.2 release. on the one hand, there's great stuff in there and it would be good to get it out sooner rather than later. on the other hand, I'm tempted to take some time to get some more backward-compatibility-breaking things in there so we don't have to wait for 2.4 for those things. <mark_weaver>phase support is an example of something that would require code changes. although it would help a lot with recursive modules, among other things. the poor handling of recursive modules is causing us some headaches in guix, for example. <wingo>i have not been helping 2.2 come any sooner <wingo>i keep noodling away at optimization passes <wingo>it's less great if no one can use it ;) <mark_weaver>our front-end really needs some improvements, as you say. <mark_weaver>it would be good to vastly improve error messages in 2.2. I think it would be worth waiting for. <mark_weaver>I have a big chunk of free time coming up in about a week. I will try to get my nose to the grindstone. <wingo>i don't think we'd be ready for a 2.2.0 for another 3-4 months <wingo>though i would hope we can start with 2.1.x in a shorter amount of time <wingo>no, i mean the prerelease series <mark_weaver>maybe it's better to have major releases much more frequently than we've been having them, or maybe it's good that they aren't too frequent. I just don't know. <mark_weaver>there is certainly a cost to the community, in porting effort, for each major release, which seems to argue for not having them too often. <mark_weaver>on the other hand, if they were more frequent, the cost of each port would be less, so dunno. <mark_weaver>another part of me is thinking "let's just get 2.2 out now and save this other stuff for 2.4" <wingo>at least we need prereleases <mark_weaver>sounds good to me. one thing I really need to do is to followup on the thread-synchronization-in-I/O-primitives discussion, and try to find a compromise that we can agree on. <mark_weaver>I agree that there are serious problems in 2.0 that need to be addressed. <mark_weaver>I think it should be possible to avoid crashes, for example. <mark_weaver>and there needs to be a dedicated lock associated with each port, even if it is the user's responsibility to lock it. <mark_weaver>and we need a reasonable solution for reporting errors and warnings from multiple threads. <mark_weaver>(the most common, justifiable case for writing to the same port from multiple threads) ***fangism-hawngry is now known as fangism
***cluck` is now known as cluck
<McBurgerMc>mark_weaver, the way the forall binds in that syntax is interesting <McBurgerMc>As in, it seems to bind over the S-expression it is in, and the following definition <mark_weaver>I confess I haven't looked very closely at typed racket -- I recommend it because I respect the racket folks -- but I don't see 'forall' mentioned in the docs, only 'All', and it has syntax like (All (A) (-> (Listof A) Integer)) <mark_weaver>McBurgerMc: where do you see the 'forall' syntax you described? <McBurgerMc>But it also binds within the body of the definition following it seemingly. <McBurgerMc>It even refers to the other a as shadowing the former a. <mark_weaver>it says "the type variables are bound in the body of the definition that you annotate" <McBurgerMc>I wonder if they are also bound if there's another definition in between or if that's even possible. <paroneayea>my copies of Little Schemer and Reasoned Schemer arrived :)