winterkoninkje: shadowcrane (clean) (Default)

This term has been quite hectic for me, though to be fair it is surely my own fault. But for now at least I have a brief respite. I finished my term paper for software engineering last night and think I did a decent job of it. Once the suitable grading period has passed, I will post it and join in a long tradition of online articles analyzing hacker culture.

I've still the project paper for artificial intelligence, but that shouldn't be too difficult. Twenty pages, but with a partner and we gave the presentation today. There's plenty of room for tweaking the project and running more trial simulations, but we have enough for the paper I think. And I still have finals, though I'm not too concerned about them; I've some back reading I need to do before taking them, but the concepts of the classes are simple. My contract job, though still ongoing, has passed the initial development stage and passed into the long slow calm of maintenance.

Though of course there is still much to do. I've given the day job and Free Geek less attention than I ought and so I must catch up on them. I've been concerned about Free Geek in particular. There was a break in recently which you may have already heard about. The press coverage has been good from that, a silver lining though still a heavy blow. But I've also been concerned about growing distant from that community. It's been a long while since I've made time to just hang out around there and take pulse of the place, and I worry about loosing touch with the daily happenings at the Geek, as well as the degree to which I am contributing to the well-being of the organization. While I doubt I'm doing any harm, I'm uncertain about whether another might do a better job than I.

I must also look to the future. It's time already to start looking into doctoral programs and to make more solid plans for where I will pursue my degree and with whom. I should probably take the GRE again, though I did well enough the first time. I need to hurry up in looking for other masters' programs too. I've grown weary of PSU. A while back I realized that even if I do get my degree from there, it won't offer me what I need from a CS masters. Without published research in computational linguistics or supplementary studies in sociolinguistic change, a CS degree is a tangent besmirching my dedication to linguistics.

I've begun thinking about Eng again, working out some of the details. One of the basic design considerations looks like it may be more technically challenging than I originally hoped, namely the notion of having no primitive types built into the language itself. The difficulty comes in from how primitive types are defined (in assembly naturally, but there are countless varieties of assembly) and how those definitions could be used by the compiler in an optimal manner. Perhaps the most challenging thing to design is how to deal with translations from literal values into the binary representation which the primitive type uses, i.e. what internal representations the compiler uses.

And then there's romance. Ah, sweet sweet romance. We've been spending much time chatting this term, and over thanksgiving she came out to visit. Hands down the best thanksgiving I've ever had. Hands down the best five days I've had in quite a long time. Though it's strange for her to cross over into my life out here, I could not have wished for a better set of memories. If I can drag her out here again before I leave this town there's still so much I'd like to show her. But deep down, it doesn't matter where I take her, for she is what makes the evening; delicious food and pretty sights are but a pale stage to highlight her wonder. And as she said, it doesn't matter where I move to, I shall always find those intimate authentic holes in the wall. It's what I do.

Still not sure where-all things will go or how to resolve those few thousand miles. I'm sure if nothing else that changing schools will throw all that into a tizzy anyway. But for once I'm not too worried. Time will explain it all. He is a talker, and needs no questioning before he speaks.

winterkoninkje: shadowcrane (clean) (Default)

So here's another crazy idea I have for Eng. When writing code, particularly at a low level, there's frequently call for doing basic sanity checks. That is, you often see code like this if ($foo == nil) { omg die! } elsif ($foo->bar()) { blah blah; } scattered liberally around everywhere. And especially with method calls when you got your object from some potentially unreliable source you see if ($foo and $foo->bar()) all over. Wouldn't it be nice if we could abstract that away?

I've had a few different ideas in the general area of different semantics of "return values" — for example you have different senses of "return value" when you're talking about the evaluation of a function/method/operator, the error code for failed evaluation, and returning "this" object so you can chain method calls together — but I recently had an idea that might be easier to implement in a similar field: we could do sanity checking with a special postfix operator ?. You would use it like $foo?->bar() and it would have short-circuit semantics so that if $foo passes the sanity check it behaves like a no-op, but if $foo fails sanity checking then it will skip evaluating bar() because trying to evaluate it will probably explode, what with $foo not being sane and all. In case there are different types of unsanity it would also be helpful to have some special variable ( $? perhaps) that stores the type of unsanity, or have perhaps some other way to deal with unsanity handling.

The challenge is where exactly to short-circuit to. If we have a statement that's a chain of method or field calls like $foo->bar()->baz->bif()->zorch()->quux; then it makes sense, wherever the ? is, to skip everything from there to the end of the chain/statement. But in other circumstances things get more complicated.

For instance, what do we do if it's in a conditional statement? If it's just a basic conditional statement like if ($foo?) or if ($foo?->bar) then it would make sense to have the whole statement return false. But if it's in a compound conditional statement like if ($foo?->bar() or $zorch->bazzle()) then it would make sense to skip the call to bar(), fail the first subexpression, and so evaluate the second. We could say that in boolean contexts the expression returns false, but that is contingent on what we mean by "expression" here.

Another example of complexity is how it interacts with non-method calls, such as arithmetic expressions. If we have $foo?->numeric() + 5 and $foo isn't sane, then what should the expression return? Well maybe the whole greater expression should fail (i.e. be skipped), that sounds sensible. Now what happens in non-algebraic expressions, like assignment? Should $foo = $bar?->baz() skip the assignment too, or should it set $foo to a known-bad value like nil? In case that question seems too straight forward, compare it against foo($bar?->baz(), $bif); should we call foo() with a known-bad value, or should we short-circuit out of ever calling foo()? Also, since ? is intended to simplify code, we must expect that callers won't necessarily test $? unless they really care about why ? failed.

A brief digression into implementation details. When calling ? we obviously need to pass it the thing we're testing. But at an assembly level, in order to know where to short-circuit to we also need to pass a label to jump back to. If during the course of evaluating sanity we determine the object's not sane, we can't just do a normal return because that wouldn't give us the short-circuit semantics we desire. The easiest way to get our short-circuiting would be to overwrite the memory location that stores the return address with the label we wish to jump to, and then when we return we'll return to somewhere else. In the event that some architectures disallow overwriting the return address, we'll have to manually pop a stack frame and do an unconditional jump, or use an inline function instead of a real function call, or devise some other method. If we allow operator overloading, overloading ? will have to be treated specially since we're not using a normal return.

Back to semantics. So far, I can identify six contexts that to be specified: method chains, boolean expressions, arithmetic expressions, string expressions, function calls, and assignment. And two general approaches: returning nil/false/zero/lambda or skipping evaluation. Since the whole point of this sanity checking operator is to avoid Doing Bad Things(tm) I'm thinking that we should err on the side of skipping evaluation, but there are certain places where just jumping to the next statement is jumping further than we may like. Inside conditional expressions — particularly disjunctions — is the big one, but also boolean expressions used as shorthand for control flow (like Perl's famous open($fh, ">", $file) or die "omg!";). Perhaps when the ? is buried in a boolean context it will skip the rest of evaluation for that whole subexpression and return false to the boolean operator, but in all other situations it just skips to the next statement. That sounds like a sensible enough place to start for Doing The Right Thing.

winterkoninkje: shadowcrane (clean) (Default)

There's a conceptual problem that's been plaguing me with Eng. For a first writing on the language, this isn't the area I would normally choose. But the most logical starting points — e.g. lexical aliasing, code metastructure — I've a pretty good handle on. Those are topics I will delve into in the future, but for now, this is my problem.

One of the design considerations for Eng is to be able to provide crossplatform natively parallel code. [1] When I say this, one should bear in mind that this goal alone is as large or larger than all the other goals for the language combined. There's a specific facet to a specific part of my attempt to do this which is causing me troubles, but before that, some history.

Back in the 1980s parallelism was very much in vogue. Then, come the late-1980s/early-1990s when microprocessor speeds started bounding through the roof, everyone decided parallelism was stupid and abandoned most research on it. (Though of course, there are always a few diehards for any technology.) These days, as we're starting to reach the limits of current fabrication technologies, and with the shape of the curve between speed and cost and how it's evolved over time, the field of parallelism is starting to simmer again with a passion fit to boil over the coming decade.

To see this, just take a look at the current market: basic home computers are shipping with 2~4 processors, many of those are dual- or (will soon be) quad-core processors, or have hyperthreading. And if that home market doesn't convince you, then take a look at console game platforms like the xbox360 or the ps3 (or their previous counterparts). And this doesn't even get into the server market which is growing ever faster as computers become persistantly more ubiquitous tools for every endeavor and every business. Nor does it get into distributed systems like the microchip in your keyboard and mouse. Let alone the scientific markets for weather modelling, VLSI, and AI — i.e. those diehards who never left.


Now that you're convinced that a natively-parallel language is essential, the first part of my problem.  )


17 Mar 2006 06:30 am
winterkoninkje: shadowcrane (clean) (Default)

As some of you may know, I've been considering the design of a new programming language lately. (And for those who haven't yet heard me talking about it, I will... at great lengths... whether you want me to or not.) This has been one of the things which has kept me busy and away from blogging of late. I'm not sure how much I should ramble on about it here though.

In working through my thoughts on the language, I'm writing an essay in three parts which mainly aims to justify why I'm doing this. (Before the abundance of circumlocutions becomes overwhelming, let us call this new language "Eng".) The first part is basically a laundry list of little features or attributes that Eng — or any language — would need to thrive against the current competitors. The second covers what I deem the fundamental Laws of Language Design, and these perhaps are the crux of the piece; certainly they are the part of the essay which is most liable to be useful outside of organizing my thoughts on Eng. And the third section of the essay is intended to introduce some ideas I have which would make this new language special. But there's a problem.

... )
RSS Atom

June 2017

18192021 222324


Page generated 21 Oct 2017 05:25 pm
Powered by Dreamwidth Studios