#rust-lang

What's the current technical restriction on a naive implementation of const trait functions (if any)? i.e. just treating them like inherent impl or ordinary functions.

eddyb, any idea? :)

Noldorin: well, it's all about checking

actually calling should "just" work

eddyb, yeah. I was thinking so to. I don't know if it's MIRI dependent (is MIRI being used for const evaluation yet, in nightly?)... but I was wondering if enabling that and feature-gating it would be a problem.

eddyb, and leaving type-checking (const-checking) if you prefer, for later, when the RFC is complete and accepted

Noldorin: it's really all about checking, there's nothing stopping *either* old CTFE (which is almost completely removed) or miri from interpreting those

I don't see how we can allow the calls without checking them

eddyb, checking in what sense... a full before-hand const-check? I thought we briefly discussed before the possibility of just evaluating the function until one runs into a non-const function.

Noldorin: that possibility is a technical one, not something I have been convinced as a good language design point

eddyb, oh sure. the whole backwards-compatibility thing, due to lack of const safety.

eddyb, I mean, centril's current RFC seems to be the accepted solution in that direction, and I'm cool with that. I just wonder about a stop-gap solution. :-)

(which can be implemented quite easily with minimal changes to the codebase)

at least, it could be feature gated on nightly

Noldorin: I will (in all likelihood) make some changes in the direction eddyb requested once I've a had a chance to talk some things over with nmatsakis

centril, okay. which changes are we talking about here?

Noldorin: const trait functions as in `: const Foo` bounds, or as in implementing a normal trait fn s a const fn?

the latter is presumably separable from centril's RFC, and could include things like allowing an unsafe trait fn as a safe fn

Noldorin: As currently written (and assuming const is more specific wrt. specialization), you'd have to write: const impl<T: const Default> Default for (T,) {..} and impl<T: Default> Default for for (T,) {..} where the former specializes the latter. With eddyb's suggested changes, const impl<T: Default> Default for (T,) {..} satisfies a X: const Default bound iff T: const Default,

otherwise it satisfies an X: Default bound only

so there is less repetition with eddyb's proposal, but the current one is more general

scottmcm3: see https://github.com/rust-lang/rfcs/pull/2237#iss... for a DAG

centril: right, I read that, but (1) can be extended to other qualifiers

scottmcm3: certainely, I considered unsafe{..} but that seems like a different RFC

or perhaps 'total fn' in the future

scottmcm3, from what eddyb is saying, it seems the latter is trivial

Noldorin: that'd be nice. It's probably uncontroversial

centril, right, makes sense

scottmcm3, I'm wondering if we can create a stop-gap solution for now, even if it's "const-unsafe" (and feature gate it)

centril, is this how eddyb's change would work for two trait bounds, or is my description slightly different? https://github.com/rust-lang/rfcs/pull/2237#iss...

Noldorin: oh, I didn't put the nicks together, didn't know it was you

no worries. :-)

I should probably change my IRC nick, but too many people know my on IRC as Noldorin now... I'm listed on Rustaceans, but most don't check there.

Noldorin: I usually do check there but since so few are listed i check it less and less

yeah...

Noldorin: idk how to answer that question atm, i defer to eddyb since it was his proposal

Noldorin: I've been thinking about changing nick too everywhere

but it is such a hassle

centril, indeed. I find it easier just to let people know (or let them find out). I probably should have told you earlier.

^,-

Noldorin: (changing nick from Centril (which I use everywhere except reddit) to my reddit nick)

Noldorin: (to ηreduce)

centril, okay. are you favourable towards eddyb's proposal anyway? I suppose you could allow specialisation *as well*, but I'm not sure there's the need for such generality.

just because you prefer the latter? changing the Reddit one would sure make your life easier :P

Noldorin: the generality gets rid of all of these hairy questions, I like that, but it comes with the consequence of some duplication when dealing with ty-var parametric types, so I am favourable towards eddyb's proposal

Noldorin: just cause I prefer the latter, it has a meaning I like whereas centril was just my WoW-characters name and is meaningless

hah okay

mu-reduce sounds somewhat type-theoretic, though my knowledge of type theory isn't good enough to know if it's a real thing.

centril, what's the main hairy question it eliminates?

some people also pronounce my nick as "centrail" and "centreel", but the 'i' is pronounced as in 'idiot'

I'm not sure how one gets the first pronunciation, but the other two both seem fair.

Noldorin: my reddit nick is etareduce, i.e: f == \x -> f x

Noldorin: the second pronounciation gets on my nerves ^,-

centril, oh, my sleepy eyes are playing tricks on me. yes, it's eta not mu, I know. :)

^,-

centril, it's more rational than the first though, at least!

Noldorin: I like the nick cause I really like to etareduce in Haskell, it gives me a tingly feeling

ah, I haven't used Haskell in a while... it's a lovely language in some ways, but so impractical in others.

Noldorin: impractical, uh?

I could launch into a monologue about why I think the way it deals with side effects is all wrong, but let me save that for another time...

centril, it's pureness being the main case of that, but not only

Noldorin: heh ;) I think that if you want rapid prototyping Haskell is your language, it is certainly faster to prototype in Haskell than in python

hmm... depends what you're doing. maybe. if you know Haskell wel

Noldorin: assuming you know both languages really well

just, becoming that sort of proficient in Haskell takes a lot more effort than with Python, I feel

Noldorin: If you started with functional programming before imperative I think Haskell will be easier for you - imperative programming really goes against the mathematics you are taught before you ever tough programmming

"what, you can mutate and have side effects? that is not how functions work..."

[PR 2260] <open> RFC: if- and while-let-chains <https://github.com/rust-lang/rfcs/pull/2260>;

Havvy: hmm well, I'm currently inclined towards if let PAT = EXPR && EXPR {..} , so not so much

I also think I want to avoid let PAT = EXPR as a general expression right now and perhaps revisit later

as long as we are future-proof

centril, sure, but whether mathematics/functional programming is more suited towards computational tasks, I'm not so sure... monads are effective, and in some way elegant, but at the end of the day they still seem like a hack to get functional programs to do imperative things

centril, anyway, what is the primary "hairy question" that your specialisation proposal avoids (in contrast to eddyb's)? :)

Noldorin: Doesn't feel like a hack to me, especially when considering how ridiculously good abstractions things like monad stacks and indexed monads are

I forget how these things work, to be honest... it's been too long, and I never got very deep into Haskell. So can't comment, sorry!

Noldorin: the specialization-idea is simple, in a const impl, you have to use const bounds, T: const Default + Clone is illegal (i think)

Noldorin: has been a while since I thought about the original proposal tbh, so I might be inconsistent with what I proposed

okay. and what sort of additional things does that allow one to do?

over eddyb's proposal

Noldorin: you can have a const impl and a normal impl that do different things

like different alogs

algos

centril, right, of course, but is this in practice something useful/desirable? I'm not sure this is

Noldorin: strawman: use rayon / distribution for one impl, a normal sequential algo for the const impl

Noldorin: but the non-usefulness in practice is what brought me over to eddyb's proposal

centril, yeah. just avoiding the duplication seems to be the more immediate benefit. I see both sides clearly now, but lean towards eddyb's too.

centril, well, I look forward to seeing the final version of this RFC before long. I suspect you're not *too* far off. good job so far. :-)

Noldorin: an indexed monad: class IxMonad m where pure :: a -> m i i a ; bind :: m i j a -> (a -> m j k b) -> m i k b

ah right

what sort of things is it typically used for?

Noldorin: and a monad stack: type Comp = ReaderT Config (StateT Env (ExceptT Err (WriterT Log Identity)))

I used things like Comp as the type for a compilers entire computation

Noldorin: consider the transition: State s1 a -> State s2 a , those are two different monads, so you can't bind

but it is fully allowed with an indexed monad

ah yes

interesting

Noldorin: I think there's a bit more to work out, in particular wrt. the questions you're asking now and deriving, and then we're done

and thank you =)

centril, yes indeed. the bulk of the work is there; points 1 to 3 seem unanimously accepted, and the solution to these outstanding questions is surely among existing suggestions, it just remains to ratify one and flesh it out, like you say.

right, I'm off now. good night.

Noldorin: sleep tight

ta ;-)