Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Loading user information from MSDN

Something went wrong getting user information from MSDN

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

## C9 Lectures: Greg Meredith - Monadic Design Patterns for the Web 4 of 4

Aug 02, 2011 at 5:50PMThank you Greg! Thank you Charles!

This one was really giving me a blast (and still is). Today I got my copy of D.E.Knuth's "Surreal Numbers", which is an excellent little intro to Conway numbers back from 1974, and I would like to recommend it here. I devoured it in one go and will read it again as soon as possible, then equipped with pencil and paper. The other book, Conway's "On Numbers and Games", appearing in the slides, I have ordered already... and Greg's book is on the list

Now, having settled the praise, here's something that sparked off quite towards the end of this installment. It's about abstracting over the container representation for 'left' and 'right'. Hmm, possibly there's a good thing even in Scala's oddity of non-variant (immutable!) Sets (see ShiNoNoir's link above).

Ok, I got two things, the second about transfinite ordinals. I know, that sounds quite scary/impressive - but it ain't really so (much). I have put together a postscript below (admittedly long for a post, but still...) which I hope establishes the relevant point while presuming virtually nothing. Please also leave your comment on that particular attempt alone, if you have some.

includingthe "first hole" that you poked? That is to say: once we're free to provide any container representation we like, can't we get rid of the A type parameter in GenConWayGame[M[_],A] and theEither[A, ...] in left and right and just "push" that into the M[_]?code. I mean code as data, i.e. we're not going to execute that code but rather want to manipulate it. So ω would just be some (finite!) representation of code that,ifexecuted,wouldgive the empty set for right and for left enumerate the naturals, ad infinitum. Adding 1 to that, for example, would give code that,ifexecuted,wouldgive the empty set for right and for left enumerate {ω,2,3,4,....}. And, even better, we could simply return the equivalent ({ω}, {}). Not so hard to imagine how to representthat, is it? You see, it's calculating (=reasoning about) it,notactually writing it out. We'd like todeferas long as we can - at best forever____

p.s., "

What's that Conway ω, by the way?" (simplifying quite a bit - as Greg mentioned, "there's a lot of devil (detail) in there"):maximalelement (check yourself using the definition of LTE). Hence the choice of the canonical representative is straight-forward: simply use the singleton set with exactly that maximal element for left and the empty set for right. This covers all of the non-negative integers nicely. Now for the fun partfinite? Well, nobody, of course. But that means there is this critter: ({0,1,2,3,4,...}, {}), i.e. empty right and in leftallthe non-negative integers from 4). This actually is a Conway number according to 2), yet any non-negative integer from 4) is LTE it. Check it yourself, you'll see it's trivial. This critter is commonly denoted byωand it was created on the day after infinitely many days (when the integers [and some more, like the rationals] were created), aka day aleph (1). Anyhow, here come the interesting bits: how to actually representωin a program? Obviously we cannot replay the "trick" from 3), as there is no maximal element (although we could agree on a canonical representation that contains just the singleton sets from 4) - but that doesn't help, it's still infinite). However, it's not at all hard to envisionω- or is it?! C'mon, all we're talking about is the pair of a) all the non-negative integers and b) the empty set, that ain't really hard. But wait, what is justthat? It's an English sentence, consisting of... uhm... a number of characters - but definitely finite! And it characterizes this infinite critterω. So...## Rx Workshop: Observables versus Events

Jul 01, 2011 at 12:11PMGreat workshop on exciting concepts - congratulations!

Had been watching Rx "from the distance" for quite a time, but now I decided to really get hands on.

So, re Challenge1: my first go on it yielded considerably

lessandmore concisecode for events than for Observables! I just could not see how this ought to illustrate the (better) composability of Observables; it seemed ratherto the contrary... oops.Then I realized that my simple-minded solution for events was way off spec (or what I think is the intended semantics) - while with Observables it all comes out just as it should be

automatically.However, the problem with the challenge at hand is IMHO that the "test case" in Program.cs does not surface any of the relevant bits. That is, I think, because it only tests the case where there is one subscriber for changes in length. Therefore I'd like to propose the following as expected output:

...produced by the this test code:

The prefixed comments denote my changes/additions relative to the original. Besides the additional length-change subscriber I have added the new text-change events "new" and "and" after "are", which both should NOT yield a length-change event.

The whole point of this is that the stream of events, particularly:as suchshould really be independent of the subscribersa) which / how many subscribers there are and

b) *when* a particular subscriber actually did subscribe.

***Note that the above test case still does not account for the one case where we have both,

a) a length-change subscriber that subscribed even before the very first *text-change* event (missing in test case, SHOULD see an event since (no text ~ length 0) != (some text ~ length > 0)

b) a length-change subscriber that subscribed right in between the text-change events of "are" and "new" (present in test case, should NOT see an event since "are" and "new" are both three characters long)

The problem I'm seeing there is that in the event solution you can get

eithera)orb) to see the right thing(s), but not both - whereas, again, with Observables you get it right for both just naturally. That is, at least given the restriction that the original [Events|Observables].OnTextChanged(string) firing method may not be changed, I'm not even sure if it's possibleat allto get it completely right with only events.Well, and there we're back at compositionality: adding a new kind of event (stream) should really only require an

additivechange.So that's what I wanted to share; this my train of thought felt somewhat educational to me. Sorry for that it all got soo lengthy

___

p.s.: please do try yourself a solution for *** based on events-only, it's one of those things which you deem "definitely doable" at first glance but find yourself utterly puzzled at when having to actually do it. At least that's what applies to me.