IRC channel logs

2014-08-13.log

back to list of logs

<dsmith-work>!uptime
<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
<nalaginrut>morning guilers~
<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
<nalaginrut>I mean doing my work on it
<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.
<nalaginrut>ooh~
<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>taylanub: please correct me if you will ;-)
<taylanub>ok :)
<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"
<homo-eroticaXL>"Last year I could work on it" reads like a conditional.
<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
*wingo summons civodul
<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?
<janneke>to guile
<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>madsy: we're a startup
<janneke>i converted 65.000 loc of c++ to 2500 lines of Guile
<madsy>nice
<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
<janneke>*help* ?
<janneke>madsy: why is that?
<madsy>Because dynamically typed languages does the type checking in runtime.
<madsy>The only way around that is to make really tight coverage tests
<davexunit>guile is just fine for production code.
<janneke>i need *help*
<janneke>;-)
<davexunit>let's not start this old battle here
<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
<davexunit>scala, boo.
<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.
<davexunit>Scheme uses latent typing.
<janneke>yes...
<davexunit>there's no magic way around that.
<janneke>davexunit: ah, isn't there, really?
<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.
<janneke>yes, i am not even using goops
<davexunit>yeah, you'd have to find or write a type system.
<janneke>davexunit: i wonder about the latent typing thing...
<janneke>or lazily typed
<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)) ...)
<davexunit>^ ugly, heh
<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?
<davexunit>janneke: I made it up
<janneke>ah, okay
<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.
<davexunit>the issue seems almost a religious one.
<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>madsy: i'm not sure
<janneke>boycottg00gle: is there any paper about agility and KLOCs?
<janneke>boycottg00gle: i.e., maintainability?
<boycottg00gle>janneke: i was serious
<janneke>I reduced our codebase by 95% and people say: "I don't care, I like some redundancy"
<janneke>boycottg00gle: i am too!
<davexunit>janneke: the problem is that guile is dynamic, and you can't prove certain things at compile time.
<davexunit>janneke: you're fighting a tough battle.
<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>davexunit: *exactly*
<janneke>and i was afraid of those parens too
<boycottg00gle>+1
<janneke>i have learned to love them, with paredit.el
<davexunit>people afraid of ))) but not })}})
*janneke is very happy with the support here
<davexunit>the latter being javascript
<janneke>davexunit: yes, amazing
<janneke>or <foo> bla bla </foo>
<janneke>which equals (foo bla bla)
<davexunit>(foo bla bla) ;; frightening
<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: that's nice
<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>very good eclips (debugger) support
<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>davexunit: it is better
<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>a tuple is just an array
<davexunit>in guile, a vector
<davexunit>'(#(0 0) #(10 10) #(20 20)) ;; a list of "tuples"
<janneke>davexunit : yes...
<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>davexunit: okay...
<janneke>in Scala lists are homo-lists, tuples are fixed-size, any type
<davexunit>sorry, I guess I just don't understand.
<boycottg00gle>nested lists are somehow important ;-)
<janneke>davexunit: naming is a bitch
<janneke>Scala has a data-type that looks a lot like Scheme's list, but it can only be of one type
<janneke>list: '("foo" "bar" "baz")
<janneke>tuple: (list 'foo 1 "baz")
<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
<boycottg00gle>janneke: but that doesn't nest?
<janneke>(define (foo (a <symbol>) (b <number>) (c <string>) ...)
<janneke>and have the compiler complain if you call foo with something else
<janneke>boycottg00gle: what do you mean?
<boycottg00gle>"nested lists are somehow important ;-)"
<boycottg00gle>you meant "but a *list* usually means: guaruanteed to be of *one* type"
<boycottg00gle>(there are (so many) trees out there)
<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>probably there is
<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>that group of people is here.
<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
<janneke>some people want that
<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>davexunit: no, it's native
<janneke>if you declare a class
<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>then, you can write a function
<davexunit> https://gnu.org/software/guile/manual/html_node/Pattern-Matching.html#Pattern-Matching
<janneke>def foo (statement: Statement) = statement.match { ... }
<janneke>and the ... looks like
<janneke>case Onstat (string, guarded)
<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: yes, exactly
<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
<taylanub>don't think GOOPS is relevant...
*janneke personally is happy with guile
<janneke>taylanub: why do you think that?
<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
<janneke>taylanub: nice...enlighten me
<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>taylanub: ah, okay
<janneke>yes, but dynamic dispatch already solves half of the request, I feel
<boycottg00gle>gauche has define-method: http://practical-scheme.net/gauche/man/gauche-refe_68.html
<boycottg00gle>guile, too no?
<boycottg00gle>ah - that is goops - now lost
<janneke>boycottg00gle: yes .. define-method
<boycottg00gle>janneke: couldn't follow your thinking above - i ended up in "he wants to use it but doesn't want to use it"
<janneke>boycottg00gle: good question
<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>yes
<mark_weaver>see ther "polymorphism" section of http://docs.racket-lang.org/ts-guile/
<mark_weaver>s/guile/guide/ :)
<mark_weaver>wingo: fyi, someone is working on a JIT compiler for Guile 2.0: https://github.com/wedesoft/aiscm
<wingo>mark_weaver: whao!
<wingo>whoa rather
<mark_weaver>the author just mentioned it in passing on guile-user a few hours ago.
<mark_weaver>he says "comments and suggestions are welcome"
<davexunit>whoa!
<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.
<wingo>ah cool
<wingo>whew, moving is terrible
<wingo>nice but terrible
<mark_weaver>but I have a big Guile TODO list that I hope to start working on soon.
<wingo>excellent
<wingo>is "rewrite psyntax" on that list? :)
<mark_weaver>heh :)
<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
<davexunit>heh
<mark_weaver>among other things, I'd really like error messages to include the history of local macro expansions.
<wingo>yes!
<wingo>and a stack of source expressions!
<mark_weaver>and I'd like to add support for phases.
<wingo>and source locations for everything, even raw symbols!
<mark_weaver>yes, of course :)
<mark_weaver>(I was typing that next before you beat me to it :)
<wingo>haha ;)
<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.
<wingo>yeah!
<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.
<wingo>ah, interesting. indeed.
<mark_weaver>so it needs to detect those errors and report them.
<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.
<wingo>cool
<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>yeah dunno there
<mark_weaver>s/code changes/code changes in some user code/
<wingo>i have not been helping 2.2 come any sooner
<wingo>i keep noodling away at optimization passes
<mark_weaver>I think that's great! :)
<wingo>it's less great if no one can use it ;)
<mark_weaver>yeah, it's a tradeoff.
<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.
<wingo>well, we'll see i reckon
<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
<mark_weaver>2.3.x?
<mark_weaver>oh, sorry.
<wingo>no, i mean the prerelease series
<mark_weaver>yeah, makes sense.
<wingo>dunno, will depend on time
<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>yeah many tradeoffs
<wingo>at least we need prereleases
<wingo>we can start from there
<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>mark_weaver, search for (All I guess
<McBurgerMc>Yeah, ALl
<McBurgerMc>All is a universal type qualifier it seems
<mark_weaver>it looks similar to the syntax for 'lambda' to me.
<McBurgerMc>But it also binds within the body of the definition following it seemingly.
<mark_weaver>can you show me an example?
<McBurgerMc>As in, it scopes over inner functions
<McBurgerMc>one moment
<McBurgerMc> http://docs.racket-lang.org/ts-guide/types.html#%28part._.Lexically_.Scoped_.Type_.Variables%29
<McBurgerMc>Check the [x : a]
<McBurgerMc>That's the same a, I assume
<McBurgerMc>It even refers to the other a as shadowing the former a.
<mark_weaver>ah, I see what you mean.
<mark_weaver>it says "the type variables are bound in the body of the definition that you annotate"
<mark_weaver>interesting
<mark_weaver>anyway, I have to go offline for a while. ttyl!
<McBurgerMc>I wonder if they are also bound if there's another definition in between or if that's even possible.
<paroneayea>welp
<paroneayea>my copies of Little Schemer and Reasoned Schemer arrived :)
<davexunit>yay!
<civodul>Hey hey!