IRC channel logs


back to list of logs

***karswell` is now known as karswell
***michel_mno_afk is now known as michel_mno
<civodul>Hello Guilers!
<ArneBab_>moin civodul
***karswell` is now known as karswell
<wingo>davexunit: morning :)
<davexunit>wingo: ooh a morning treat!
<wingo>no transients yet tho
<davexunit>you are a data structure master
<wingo>lol, just reading clojure's source code
<wingo>dunno to what extent that makes this a derived work
<wingo>will think about that later
<davexunit>ah yeah, that's an interesting question
<davexunit>hey civodul
<davexunit>I started experimenting with parser combinators last night
<davexunit>they are really neat
<wingo>yeah the eclipse public license does not appear to be gpl compatible :/
<davexunit>uh oh...
<wingo>dunno what that means tho
<zacts>davexunit: are you doing clojure?
<wingo>i could go back and read bagwell papers i guess
<davexunit>zacts: no
<wingo>see if things are exactly the same as in the paper, in that case it might as well be an independent implementation
<ArneBab_>wingo: to be safe you might have to do a whiteroom implementation: someone reads the code, describes the concepts, someone else reads the description and writes the new code.
<ArneBab_>but the paper is good, too :)
<ArneBab_>or ask the author of the code in question whether he/she would offer that part under GPL, too.
<wingo>or as MIT or something
<wingo>there is a CA in clojure so there is only one person to ask
<civodul>wingo: which Bagwell paper describes it?
<wingo>civodul: the one that introduces the Hash Array Mapped Trie
<davexunit>clojure has CA? ugh.
<davexunit>the FSF is pretty much the only organization that I would assign copyright to
<davexunit>since Clojure is under the EPL, can people even write GPL applications with Clojure?
<davexunit>sounds like a licensing nightmare.
<wingo>davexunit: i think they can't; hard to know tho
<davexunit>yeah, if so, another strike against Clojure.
<ArneBab_>davexunit: I’d also only assign copyright to FSF, because their CA limits their options to “use this to help free software”.
<davexunit>oh boy, it's apparently time for my periodic annoyance with static typing proponents.
<civodul>davexunit: having an argument with a coworker or something? :-)
<davexunit>read a John Carmack tweet
<davexunit>"First changes to my server code since the conversion to Typed Racket, already feeling the benefits over plain Racket. Types are good."
<civodul>which is not completely untrue, if i may ;-)
*civodul hides
*wingo agrees with civodul :)
<civodul>sorry for ruining your day ;-)
<ArneBab_>typed racket is just “I can define the types of the function as additional safeguard”
<davexunit>I'm not worried about you folks, you work on dynamic languages all the time.
<ArneBab_>davexunit: the answer “types are good” is a bogus result from that
<davexunit>but the "static type everything" crowd drives me nuts
<ArneBab_>I would have loved to have optional types for the Python code I currently use: Just to have it scream at me when I keep a numpy value.
<davexunit>to generalize: Haskell users
<ArneBab_>just to be able to say “every event has to be a tuple consisting of either tuples of ints, floats or strings”
<ArneBab_>though that’s just a hack to keep Python from using references into huge arrays as numbers (keeping the whole 13000-element array in memory to use a single value).
<civodul>gradual typing as with {Typed,} Racket sounds nice to me
<davexunit>I agree with "types are good", as in creating distinct types to represent objects. I do that all the time with record types.
<ArneBab_>“gradual typing” ← sounds *nice*
*wingo sometimes wants the compiler to help me prove something about my program
<davexunit>the static type people don'tlike that
<wingo>that's why iam interested in types
<davexunit>compilers helping to prove stuff is good, but it seems to me that static typing comes at too high of a price.
<ArneBab_>I like gradual typing (stealing the wording from civodul here ☺), as for example in cython.
<ArneBab_>add types, and if you add enough to make it possible to infer everything, the function gets compiled down to plain C.
<davexunit>I find writing C to be frustrating because I have to specify all of the damn types all the time
<davexunit>some people are happy to declare the types for everything, but for me, static typing comes at the expense of actually enjoying programming.
<ArneBab_>davexunit: same for me… for many tasks that’s unnecessary typing overhead.
<ArneBab_>and with C++11 they added an “auto” keyword, so most declarations will be “auto <something>;” ← unnecessary ceremony
*ijp shakes head and sighs
<mark_weaver>actually, 'auto' has been a keyword in C since before many of you were born, but no one ever uses it
<mark_weaver>maybe it wasn't in C++, dunno.
<civodul>"many of you" :-)
<mark_weaver>the reason no one uses it is because it is the default for local variables
<lloda>it was also a kw in C++, but it was deprecated & repurposed
<wingo>davexunit:, now with transients
<wingo>could be faster i guess but it's ok i think
<wingo>note that by default it uses hash and equal
<wingo>i don't know what the right defaults are
<davexunit>sounds like a good default
<paroneayea>gradual typing is what Common Lisp has had for ages right?
<paroneayea>ie, optional typing basically right
<davexunit>what do you think about some syntax, let's say called 'fash', that is sugar over 'alist->fash'?
<davexunit>wingo: ^
<wingo>davexunit: sounds fine to me
<davexunit>(fash (key value) (other-key other-value))
<wingo>and fashq and fashv to make eq? and eqv? hashes
<davexunit>yeah, that would work
<davexunit>wingo: doesn't look like alist->fash can choose the hash and equality procedures?
<davexunit>still reading the source, set me straight if need be. :)
<wingo>davexunit: good point
*wingo fixes
<wingo>davexunit: check again
<wingo>this is the worst source control strategy ever
<wingo>literally overwriting a file and scping it to the server
<wingo>what is wrong with me
<wingo>*when developing a functional persistent data structure*
<davexunit>wingo: get with the times! we all use RCS now!
<ArneBab_>wingo: *gg*
<ArneBab_>wingo: don’t you have it locally in a git/hg repo?
<wingo>for one file? nope
<ArneBab_>sure - doesn’t hurt, can be blown away later ☺
<ArneBab_>or use emacs backups ☺
<davexunit>wingo: nice use of record type printers
<davexunit>I was about to suggest it and then I looked at my REPL and noticed you were way ahead of me ;)
*wingo goes afk for a while, ciao
<davexunit>ooh, but there's an improvement that could be made
<davexunit>(fash ('foo "foo") ('bar "bar"))
<davexunit>$2 = #<fash ((foo . foo) (bar . bar))>
<davexunit>should print: #<fash ((foo . "foo") (bar . "bar"))>
<davexunit>wingo: when you get back, change "~a" to "~s" in your 'print-fash' and 'print-transient-fash' procedures.
<davexunit>and thanks so much for working on this and fectors
<davexunit>they are lovely
<ijp>wingo: you did know I already wrote hamts...
<civodul>pfds is a nice collection
<paroneayea>might be cool to have more pfds stuff in guile proper, but maybe that desire just comes out of missing more packaging of stuff in guile :)
<davexunit>I think useful data structures are a good thing to include in guile core
<mark_weaver>but IMO, I'd like these data structures to be as fast as we can make them, within reason.
<davexunit>sounds reasonable
<paroneayea>it's certainly a big selling point of languages these days to have fast functional datastructures
<davexunit>I'm really liking these transient fectors and fashes :P
***dje is now known as dje42
<davexunit>wingo: let's make this dev workflow even worse, here's a patch for fector.scm that isn't a patch, but rather a paste:
<wingo>ijp: could be yours are better!
<wingo>i just wanted to understand how they work
***michel_mno is now known as michel_mno_afk
<daviid>no GUILE_SITE_CCACHE_DIR in guile.m4 right?
<mark_weaver>daviid: if you put GUILE_SITE_DIR in, then GUILE_SITE is marked for substitution. you can put both .scm and .go files thre
<mark_weaver>that's what Guix does, whose build system was written by civodul, our resident autotools expert
<daviid>mark_weaver: tx, i already updated guile.m4 locally to get it :)
<mark_weaver>I confess that I don't see what magic ensures that the .scm and .go files are installed there
*mark_weaver is still mostly ignorant about autotools
<daviid>here is what i added locally to my guile.m4 file, review welcome and if usefull i can send a patch
<davexunit>wingo: I noticed that the argument order of fector-fold is different than fold. was that intentional?
<davexunit>and do you think it would be useful to be able to pass an arbitrary number of fectors to fector-fold?
<wingo>i don't like srfi-1's order; i more often want to fold over multiple seeds than multiple lists
<davexunit>wingo: okay, so it's a deliberate choice. that's fine. :)
<davexunit>just curious.
<mark_weaver>wingo: I've had need for both
<mark_weaver>I think we need both
<mark_weaver>oh, I didn't read the whole context. I'm not saying that we need both in the fector library...
<mark_weaver>nevermind me :)
<davexunit>I used fector-fold to write fector-map and fector-filter, but they are limited to a single fector, which is probably fine, but I dunno.
<ArneBab_>when I open a guile file with emacs which uses shell-indirection, emacs starts in sh-mode. Is it the same for you - and if not: how did you change it?
<mark_weaver>M-x scheme-mode
<davexunit>ArneBab_: add "-*- scheme -*-" in the block comment with the shebang
<ArneBab_>davexunit: ah, yes - thanks!
<davexunit>so that emacs will automatically use scheme-mode
<mark_weaver>ArneBab_: right, you can put that on the second line, within whatever comment syntax is appropriate.
<mark_weaver>e.g. see the 'guild' script
<ArneBab_>I started with experiments for benchmarking datastructures - currently mostly wrapping (statprof) in nice syntax
<mark_weaver>sounds good! :)
*davexunit is having fun writing parser combinators
<paroneayea>I had things set up so that I could run guix and emacs integration on my debian machine, and I broke it again!
<ArneBab_>mark_weaver: I’m currently struggling with making a syntax case macro take #:let as argument - it was named “illegal”
<ArneBab_>after some experimenting I caved in and used :let
<ArneBab_>but I’d prefer #:let, to make it look conventional
<ArneBab_>(benchmark thunk #:let ((var 1)))
<ArneBab_>let binds the variables the thunk needs
<ArneBab_>outside the actual benchmarking function
<davexunit>ArneBab_: why not just wrap the 'benchmark' form in a 'let'?
<ArneBab_>davexunit: because I want to make it a single call: basic syntax (benchmark thunk), extended: (benchmark thunk #:let ((...)))
<davexunit>that syntax doesn't sound particularly friendly to me
<ArneBab_>keeping it together
<davexunit>this is what lexical scope is for.
<ArneBab_>I will need to wrap it deeper, still, so I wanted to make it look simpler
<ArneBab_>the macro wraps the actual benchmark function in a let
<davexunit>and it would be hard to cover all the possibilities: what if I want let* or letrec behavior?
<ArneBab_>I hope I won’t need that
<davexunit>the point is that your macro need not concern itself with these details. maybe it's just me, but I see it only as a complication.
<ArneBab_>I want to get to a point where I can say (estimate-time-complexity list append)
<ArneBab_>and get back something like "O(1)".
<ArneBab_>maybe I’m making this overly complex, I’m not sure