IRC channel 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: https://www.gnu.org/software/guile/manual/html_node/Expression-Syntax.html#index-unquote_002dsplicing ?

<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.

<cow_2001>oooooh!

<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! https://github.com/sarabander/sicp/pull/45/commits/6235bec8a34b7d11ed3ab0f033ba45ee12ddb2f7

<sneek>dsmith: Greetings!

<dsmith>sneek, botsnack

<sneek>:)

<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

<dsmith>!uptime

<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...

IRC channel logs

2023-04-14.log