tag:blogger.com,1999:blog-6181310435977891397.post5997947688881633476..comments2010-07-31T21:02:16.914-04:00Nick Johnsonhttp://www.blogger.com/profile/09742551843387605596noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-6181310435977891397.post-64764730837447557102010-07-31T21:02:16.914-04:002010-07-31T21:02:16.914-04:00Haskell.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6181310435977891397.post-37446460272929012312009-03-09T22:37:00.000-04:002009-03-09T22:37:00.000-04:00Dennis,<BR/><BR/>I definately want to talk about it sometime.<BR/><BR/>The language you describe sounds interesting. It reminds me of a language described in an academic paper several years back named Z (I'll try to find a link). Having said that, it of course has some similarities to lisp.<BR/><BR/>Bjarne had an interesting prediction about lambdas in C++0x: he thinks that in the first year-or-so after their adoption they will be overused. After that, people will calm down and use them more conservatively. Having said that, I caution: your MMO codebase doesn't *require* them, since lambdas can be efficiently emulated with function classes (especially those which capture some environment during construction). Bjarne's lambdas don't deal well with escaped variables---stack variables still disappear upon scope exit, even if you return a lambda that captures them.<BR/><BR/>Though it is quite different than what I am planning. I'm looking more towards static type systems, but providing some very high level features that are generally only available with dynamic typing (e.g. safe variadic functions) or in scripting languages (fancy syntax for literals of many classes, including ranges, xml, regexen, etc). Also, a lot of my work will go into a decent standard library (I'm so unhappy with the standard libraries of C++ and Java)... I have one focus which is clear: make software development easier without sacrificing performance. I pull in high level features only after I'm sure they can be efficiently implemented. Too much to discuss here, we'll talk over email.<BR/><BR/>Shoot me an email; without telling the spammers (they're always listening), you can google for "nick johnson princeton" and find my email address at my princeton site.<BR/><BR/>NickNick Johnsonhttp://www.blogger.com/profile/09742551843387605596noreply@blogger.comtag:blogger.com,1999:blog-6181310435977891397.post-40557912739567211812009-03-06T18:50:00.000-05:002009-03-06T18:50:00.000-05:00(A bug in the input form sliced my comment, I had more to say:)<BR/><BR/>I'd like to have a discussion with you about the language you're designing. I have some (incomplete) ideas about a language design and I'd like to see if you either want to incorporate them or have some suggestions for my language. One idea is every block of code in curly braces would implicitly be a block/lambda function, so for instance while (x) { do_something; } is the same as var block = { do_something; }; while (x) block;<BR/><BR/>Anyhow great post, bravo.Dennis Ferronhttp://www.blogger.com/profile/03601234553344631838noreply@blogger.comtag:blogger.com,1999:blog-6181310435977891397.post-61357464242396705952009-03-06T18:46:00.000-05:002009-03-06T18:46:00.000-05:00You got to meet Bjarne Stroustroup?! Ah, I so jealous. I've watched every video I can find online of him speaking about C++0x. He's not just a brilliant man, but also a good speaker; one of those people who makes you feel like you just gained 2 IQ points just from grokking what he's got to say.<BR/><BR/>Oh yeah, C++0x is going to totally rock our socks off. I have in fact read some of the technical documents, and as far as I can remember you have it right about concepts; I hadn't read about or perhaps failed to grasp axioms until now, so thanks for explaining those. <BR/><BR/>My business partner and I are impatiently awaiting the release of C++0x so that we can update our MMO game codebase to use it. The design of our game engine actually <B>requires</B> lambda functions to be at all convenient to use. We&#39;re doing this neat thing whereby most of the functionality of the game is implemented using functors, so for instance game-&gt;draw() doesn&#39;t know about the graphics api, it takes a functor and the functor talks to the graphics api. When you use this technique all over the place, it&#39;s a pain to create a class for every functor, and much better to be able to declare the code of the functor near the usage of the functor. Right now I&#39;m using a hack that simulated lambdas in ordinary C++, but it&#39;s limited, although I did come up with a really sick way of shoehorning closures onto current C++! Incidently, it&#39;s the topic of a blog post I&#39;ve had in draft for a while; you might have just spurred me to publish it.<BR/><BR/>Also funny you should mention duck typing in relation to concepts, because I have an upcoming blog entry about that as well. My premise is that current C++ templates actually <I>already</I> implement "static duck typing", which is frankly a downright weird and absolutely fun combination, and I want to talk about some of the implications of that. I say C++ templates are already duck typed because they don't care about either the types or the signatures of objects and methods that are templated; they only care about whether the <I>names</I> of the methods are implemented. The problem is that if you make a mistake, you don't see the error where you made it, but 15 nested classes down inside some library header you've never heard of where the mismatch finally bottoms out. Concepts will fix that by letting the author of the template catch those at the top level, not the bottom. You are right, however, in that the way concepts themselves are implemented is duck typed. I like that; I think in a way the existing de facto duck typed way templates have been used forced them into making concepts work this way for compatibility, so the result is they were forced to implement them the way <B>I</B> would have wanted them to do it regardless.Dennis Ferronhttp://www.blogger.com/profile/03601234553344631838noreply@blogger.com