IRC channel logs

2016-06-02.log

back to list of logs

<taylan>galex-713: for what purpose are you interested in the "lowest level scheme forms"?
<taylan>maybe you just want to look into Guile's Tree-IL
<galex-713>taylan: no just I cannot decide what paradigm to use to do abstract things the cleanest way
<galex-713>So I’m looking for what would be the more efficient to compile/run, since most of implementations would be expressively equivalent
<taylan>I think it's best to just use the macro that's semantically most suitable for the situation... do you have a concrete example of where you have two or more macros to choose from that can do the same thing?
<galex-713>implementation of different sorting algorithms
<galex-713>merge sort, insertion sort, quicksort, etc.
<galex-713>And I don’t know if I’ll better use do, named let/let*/letrec/letrec*, while, with or without let, with or without side effects, etc.
<galex-713>since different people advise me to do different things
<galex-713>Except for people who says it’s unimportant and I’ve only to quickly choose and do that
<taylan>hmm, ok. firstly, 'do' is pretty obscure and generally discouraged. secondly, there's only named let, no named let*/letrec/letrec*. 'while' is more for imperative programming style, whereas named let is more for functional; in Scheme/Guile we usually root for functional programming style, though some algorithms may be more cleanly expressed in imperative.
<galex-713>So I’m searching for what’s the lowest level
<taylan>('while' is also not standard Scheme, in case that matters for you)
<galex-713>ok
<galex-713>why does do exist if everybody discourage it?
<galex-713>and yeah I said it wrong: couldn’t choose between named let/while/do and let/let*/letrec/letrec* on the top of these
<taylan>it was added waaay back because MacLisp had it and Scheme was first based/implemented on MacLisp (and I have a feeling they thought it was a cool way to show off what you can do with tail recursion) and then they always kept it for backwards compatibility
<galex-713>oh ok
<galex-713>taylan: also why having a while if it’s not standard scheme?
<taylan>let/let*/letrec/letrec* all do slightly different things. you normally use let. when you need some variable bindings to see the value of some previous ones, you use let*, e.g. (let* ((a blah) (b (+ a 5))) ...).
<galex-713>yeah I know for let/let*/letrec/letrec*, I read the appropriate manual section
<taylan>while is provided by Guile for reasons I don't know. maybe because it makes some imperative algos easier to write.
<galex-713>(or subsection or idk)
<taylan>yeah well, "always use the simplest one that suffices" should be a good rule of thumb
<galex-713>ok
<taylan>for looping I find myself using named let most often
<galex-713>I see
<galex-713>Anyway do/while/etc. translate to named let right?
<taylan>I'm not sure, it could be that some are implemented at a lower level. one can check by using ,expand or ,optimize at the REPL
<taylan>seems like do expands to named let
<taylan>and while expands to some huge thing because it defines "prompt" tags for continue and break
<taylan>but also seems to use named let otherwise
<galex-713>ah ok
<galex-713>(I thought while was a horrible guile way of defining things at low level)
<taylan>nope, all cleanly implemented with delimited continuations. :-) at least as of 2.0.11, maybe it was different in the past.
<galex-713>taylan: ok cool ^^
<Baldtoenails>Is there a way to disable this wawrning: "WARNING: (guile-user): imported module (lib proc) overrides core binding `sleep'"
<Baldtoenails>I'm running r6rs mode and sleep seems to be one of the exceptions of core guile bindings getting in
<wingo>meep
<civodul>hi wingo!
<wingo>morning :)
<wingo>release update: it took me a while but i think i finished the needed facilities in ports to allow for concurrency while nonblocking i/o is happening
<wingo>i just want to port some old code to master to see if it runs and then i will work on the 32-bit build issue
<wingo>civodul: to remind me, how do i set up a 32-bit x86 environment with guix?
<civodul>awesome
<civodul>wingo: guix build -s i686-linux foo bar
<wingo>tx
<civodul>same with 'guix environment'
<wingo>great, guix environment is probably the thing i need then
<wingo>because then i can work on guile from git
<civodul>yeah
***chaos_ is now known as Chaos`Eternal
<amz3`>héllo
<dsmith-work>Morning Greetings, Guilers
<kwrooijen>Morning
<wingo>mew
<wingo>ACTION ports old memcache server & client implementation from old eports stuff to an ethreads on top of guile master
<civodul>neat!
<civodul>high-performance web!
<wingo>well ;) we will see how the perf is ;)
<wingo>no idea yet
<wingo>could be all the port position / encodings / BOM / * stuff slows things down significantly; can't tell yet
<wingo>i just want something where i can make & handle requests without being vulnerable to DOS
<wingo>ok peoples
<wingo>i have a modest propsal
<wingo>proposal
<wingo>cannibalism
<wingo>er, wait, no ;)
<wingo>IF you set a socket to be nonblocking
<wingo>IF you set a socket to be nonblocking
<wingo>er
<wingo>AND you try to accept(2) on that socket
<wingo>AND there's nobody ready there
<wingo>THEN we should return #f instead of raising an exception
<wingo>either that, or cannibalism
<wingo>either one.
<ijp>cannibalism seems hard to implement efficiently
<wingo>letrec binding, for humanity
<civodul>wingo: avoiding exceptions on common cases sounds good
<civodul>but having two different possible control flows depending on socket settings sounds not-so-good
<wingo>yeah
<wingo>hmm.
<daviid>wingo: could you find some time to look at and fix bug#20093 ? again, I depend on it, and should I be the only one, I think it would be very nice of you to fix it before the next release
<wingo>daviid: tx for reminder, will look at it when i get back into a cleanup/bugfix phase
<wingo>soon!
<wingo>i want to release soon so i should deal with that soon
<wingo>but now am in a featurish phase, so i don't want to break my flow
<daviid>wingo: ok, thanks!
<wingo>i guess i want something like the current story for nonblocking i/o and ports
<wingo>where when called from C, a read on a nonblocking port will transparently wrap the request in a poll if needed
<wingo>but for ethreads it would do something similar
<wingo>hmm
<wingo>pretty sure the ethreads connect function was borken, oh well
<wingo>connect(2) is clownshoes
<dsmith>wingo: how so?
<dsmith>wingo: Are you referring to setting it non-blocking and then polling for write?
<wingo>yep
<wingo>and then checking SO_ERROR or whatever
<dsmith>YEah, that's a little weird
<wingo>turns out the ethreads connect function was fine, it's just connect(2) that's a bit strange
<daviid> https://news.ycombinator.com/vote?for=11823902&dir=up&goto=news
<dsmith>Only way to do a non-standard connect timeout. Other than setting an alarm (Ugh).
<daviid>ACTION thinks the more we speak about lisp and lisp dialect the better
<daviid>dialects*
<dsmith>daviid: Mentioning "dialect" remimded me of all those "lithp" jokes you year from time to time
<daviid>:)