IRC channel logs


back to list of logs

<daviid>beautiful! :) - i now have a complete and completely general (next-vfunc) mechanism in g-golf
<wingo>cow_2001: guile does not have a fixed evaluation order. perhaps it should, though :)
<cow_2001>wingo: maybe a form that fixes evaluation order
<wingo>i think it doesn't matter for perf. if we can be explicit, probably we should
<wingo>so we could just change to have ltr evaluation order
<cow_2001>can you do something like (+ (return-a-bunch-of-numbers)) by returning several values? or do you have to (apply + (return-………))?
<Zelphir>cow_2001: Do you mean something like this: ?
<ecraven>cow_2001: I don't think any Scheme supports this directly. if you return a list, you can use `apply', if you actually return multiple values, you need to use `receive' or `let-values' in some form.
<old>with the out of order evaluation order, it would be possible to evaluate the arguments in parallel in the future
<old>I have a `pcall' in guile-scheme for that. But by keeping the out of order default, it would be possible to make it transparent
<lloda>scheme standard says there's an order, it's just unspecified. If you can evaluate the arguments in parallel transparently, bc the evaluations don't have side effects or w/e, then you could also do that if the order was specified
<old>ordering and parallel are kind of oposite here no?
<lloda>i don't follow
<old>if you have (F x1 x2 x3 .. xn) and you specify and order of evaluation such as xn-1 will eveluate before xn
<mwette>wrt ordering, in one case a chain, in the other an anti-chain
<old>then you're imposing total ordering of arguments, so you can not parallelize evaluation of x1 .. xn
<old>so not specifying any order is actually given total freedom for parallelization of evaluation of arguments
<old>anyway, one should probably not rely on the evaluation order of arguments. Nested let are for that
<lloda>r5rs says 'The operator and operand expressions are evaluated (in an unspecified order) ...'
<lloda>one must not rely on any particular order, but one may rely on there being one
<lloda>all i'm saying is re: parallelization the current status isn't clearly better than fixing the argument eval order would be
<old>I see
<mwette>what does
<mwette>What is the context of "there being one"? For a particular call, a procedure, or an implementation?
<lloda>i read it as per call
<lloda>that's r5rs 4.1.3
<mwette>So the differnce between the order here and parallel is very subtle, but there is a difference.
<cow_2001>i've made a patch to (the unofficial) sicp!
<sneek>dsmith: Greetings!
<dsmith>sneek, botsnack
<cow_2001>owner of the repo seems to have vanished
<old>mwette: In my case there's none since I use map for parallelization with `pcall'
<old>anyway, I for one would like to not be impose a order of evaluation
<sneek>I've been running for 12 days
<sneek>This system has been up 1 week, 5 days, 22 hours, 17 minutes
<sneek>Welcome back mwette
<bjc>how can i query guile about where a particular symbol was imported from?
<RhodiumToad>I'm not sure it's possible to know
<RhodiumToad>peeking into module-import-obarray doesn't seem to give any clues
<RhodiumToad>might be possible to compare the variables to find out which module really contains them...