## Neologism

There ought to be a word for the sinking realization that, semantically, the language you've been designing and implementing for months is only a small extension over the one you're implementing it in.

(I posted about this language once before. Writing an interpreter for it in Scheme was one thing; but, once I started to compile it down to Scheme, and saw how easy it was--the generated Scheme code was a pretty trivial transform from the ASTs--I realized that meant my semantics offered very little over Scheme's. I'll probably stick with it as an exercise, but that's about all the value it offers at this point.)

## Comment viewing options

### neologism

Let me know if you find the word — I might need it soon for the language I've been designing. To this point, I've been keeping embarrassment at the ready. The type system is enough of a stretch that I'll never figure out on my own how to reduce it to Haskell. Thus, it will inevitably become public.    :-)

### Hmm...

Let's see. A term for the language itself could be "Schadensprache" ("shameful language"), analogous to the better known "Schadenfreude", "shameful joy". However, by that analogy, "Schadensprache" might work better for a language that you'd be ashamed to use, such as Visual Basic.

Hmm...

### Das Ende aller Dinge

FWIW, "Schadenfreude" refers to joy one feels when others come to harm; you may consider that shameful, but that is not part of the core meaning, but rather a value judgement one can ascribe to that sort of joy.

So "Schadensprache" does not really make sense, and if it did it would likely denote something like "a language which causes others to come to harm." In that sense, though, perhaps Visual Basic could indeed be called a Schadensprache.

### Die entscheidende Schadensprache

If harm to others is the criterion, then the ultimate Schadensprache must be C and its descendants. Think of all the wailing, gnashing of teeth, and rending of garments caused by worms that take advantage of pointer and buffer bugs in C programs, to pick just one rather fertile area of example.

### reinventing the call-by-push-value

Thanks to Derek Elkins, I found Paul B. Levy's call-by-push-value. So it turns out that the language I've been developing is at its heart a reinvention. That's a letdown. On the other hand, it's good to see that people out there consider the idea worth a 300 page dissertation and a new, expensive book. Moreover, my language now has formal semantics with no effort on my part.

### A saying that fits, not a word.

"so sharp you'll cut yourself".

### Not Far From Scheme

francis: once I started to compile it down to Scheme, and saw how easy it was--the generated Scheme code was a pretty trivial transform from the ASTs--I realized that meant my semantics offered very little over Scheme's.

Let's be fair: Scheme deliberately "hews close to" (according to Guy Steele) the Lambda Calculus. Considerations of typing aside, it's not really that surprising that your language's semantics would be close to Scheme's.

Interestingly enough, I just read the pages on the new Tree SSA intermediate representation being used in GCC 4.0. It's making possible whole new classes of optimizations etc. As I read the description of the tree structure, the importance of the lack of side-effects in SSA, and so on, it occurred to me that, under the hood, all compilers end up being functional and relatively close to the Lambda Calculus. :-)

I'm also reminded of the C++ standards community's desire to make "typeof" part of the language, and some implementor's complaints that this would essentially necessitate the development of a typing-with-undo framework in their compilers, and it occurred to me that this sounds a lot like constraint-based type inference.

Bottom line, I wouldn't be surprised if mainstream languages like C++ got stronger and stronger functional subsets, especially as compiler implementors continue to draw lessons from the functional camp. Conversely, I'm anxious to see what comes of some of the efforts to produce a functional language that plays nicely in an imperative world, such as Tim Sweeney is working on.

### Ob. refs

As I read the description of the tree structure, the importance of the lack of side-effects in SSA, and so on, it occurred to me that, under the hood, all compilers end up being functional and relatively close to the Lambda Calculus. :-)

In the spirit of the Getting Started thread, a couple of the classic papers about this correspondence are Kelsey's A Correspondence between Continuation-Passing Style and Static Single Assignment, and Appel's SSA is Functional Programming.

### Considerations of typing asid

Considerations of typing aside, it's not really that surprising that your language's semantics would be close to Scheme's.

There is that. Thanks.

Conversely, I'm anxious to see what comes of some of the efforts to produce a functional language that plays nicely in an imperative world, such as Tim Sweeney is working on.

I should take a look at that; part of my goal was to create a language that was comfortable for people used to imperative syntax, without sacrificing the power of functional programming.

### Preemptive bootstrapping?

There ought to be a word for the sinking realization that, semantically, the language you've been designing and implementing for months is only a small extension over the one you're implementing it in.

Actually, that would be called "a sane decision" since it would allow for an easy bootstrap of your new language.