First-class continuations remains the hardest nut to crack to implement any full specification of Scheme, especially if performance and/or compactness and/or simplicity of implementation and/or integration with other languages (C, C++, Java, etc.) is a priority. Scheme--, a subset with only downward continuations, i.e. continuations that could be implemented using only C setjmp and longjmp or equivalent, would still be an extremely useful language, but it is much harder to gather a community for such a project.
I was lucky enough to meet Alonzo Church and Haskell Curry at the ACM Symposium on LISP and Functional Programming at CMU in August 1982. Curry was clearly not well and only lived about two weeks after the conference, but Church was in good form and lived about 13 more years. Gerry Sussman was very excited while he went around the room at the reception introducing them, and of course it was a great thrill for us to meet them.
It's a shame to describe the tritone sub for G7 as C# F G# B, when the proper way to spell it is either Db F Ab Cb or C# E# G# B. Of course, then you'd have to explain about enharmonic equivalence and how chords are usually spelled with every other note.
The C# grates on my eyes, since the V7 tritone substitute is IIb7. However, preserving the F and the B notation emphasizes the tritone interval that is inverted and shared with the substitute.
The explanation is that a seventh chord is defined as a set of third intervals. So it cannot jump from C# to F, it needs to go from C# to E#. Even though these tones are the same, the C# to F doesn't make sense. The same can be said about F G#, it doesn't make sense because it is not a third.
I transcribed the music on the ghost ship in Monkey Island 1, which features a lot of chords in the background involving fourths, fifths, and whatever we want to call the half-step in between fa and so.
Working with a MIDI file and without much grounding in music theory, I had and have no real way of determining whether to represent notes flat or sharp. I consulted several people and generally got a response of "Oh, interesting stuff! It's not clear how you should transcribe that."
The note between fa and sol is fi or se, depending on if it's the sharp 4 or flat 5 functionally. Sharp 4 would be most common, since it comes up as the leading tone of the dominant's key, e.g. in an secondary dominant, like V7/V.
But I guess you could get the flat 5 if you did the tritone substitution of the secondary dominant of the IV, which would be bV7.
I know that fa sharp is fi and so flat is se. The point of my comment was (1) that I was having difficulty labeling the note in question, meaning I couldn't use either name; and (2) that the heuristic "use the enharmonic that doesn't interfere with other nearby notes" doesn't work, because the notes a half-step away in either direction are both in use.
Oh sorry, I misread your comment and that you were referring to a specific piece. Are you talking about the vibraphone part in the beginning? If so, I think you did it right. I wouldn't consider those little dips of the top note to be a chord change, but just a neighbor tone (https://en.wikipedia.org/wiki/Nonchord_tone#Neighbor_tone). So I'd treat it melodically and just put it on the adjacent line, with whatever accidental works. Like you did!
And then I think you may be talking specifically about measure 11. I'm pretty rusty on my analysis, but it seems like it's the iv7 chord, but starting and ending with a chromatically raised root, which is slick because it acts as a passing tone from the i chord in measure 10 and the V in measure 13. I would probably do Gb -> F -> Gb, because the F is the chord tone, and the Gb is the nonchord ornament. But yeah, probably doesn't really matter!
- Match the type of accidentals used by the key signature.
- Use sharps when the melody is moving up, and flats when it's moving down.
- Use whatever accidentals give you a visually pleasing spacing of notes in "thirds" as represented on the staff. (As advocated here.)
- Use the accidentals that are physically compatible with other notes in the chord. (Only a concern for certain instruments, but e.g. I understand that the pedals on a harp affect many strings at once, so playing a particular combination of notes may require a clever approach to the pedals, indicated by what might otherwise look like an unnatural set of accidentals. This wouldn't apply to a piano, where G# is just a separate key from G, not a modification of the G key.) I think this is what you're going for?
Another example would be the bass side of an accordion where Db and C# imply different buttons (though not different sounds - there are duplicates) and they’re quite far away from each other.
The accident you use really depends on the context. If you're talking about chords, then you should follow the "stack of thirds" explanation that I gave above, it is how chord theory works. However, the other rules you mention also can be used depending on your situation. In a melody, you normally want to add accidents only when needed.
Yeah, I've seen things spelled this way before in barbershop arrangements. Usually because it's less accidentals. I think it makes sense from a "what notes should I play" perspective, but seeing these chords spelled in a weird way gives you insight into how some composers actually think, and all that REALLY matters is what the music sounds like.
I came here to pick this nit but you beat me to it. I think calling it Db7 is the best way to think of it, especially since in jazz it's often part of a descending sequence of II-V-I, where the tritone substitution turns it into II-bII-I. So in C major (where G is the dominant), it has to be Db.
I don't think this is correct. I think colanderman's answer is the right one, which is that when we're descending, we generally spell out the pitches with flats. If this were ascending, then we could have I-#I-II. But as I noted, in jazz this particular descending pattern is fairly common.
I, bII, etc. are chords not pitches. II-bII-I is a chord change. Pitches may go up or down and voices may go away or arrive. They may be part of those chords or not. And there may not even be a root pitch.
Or if you want formal theory, chords are scales [1] and there ain't no such thing as a scale with a sharp I. If you sharp the one it’s a different scale starting in a different place.
The b in bII is not an accidental and bII is how to communicate the chord in passing. I/bII is also possible to communicate a modulation (as would be vii/II, etc. if the modulation is elsewhere).
There are “enharmonics” for chords that aren”t the root of course, e.g. #IV and bV depending on intent, convention, or playability. But #I will be marked wrong on the entrance exam and only raise you standing among an avant guard that isnt accepting new members.
> If you sharp the one it’s a different scale starting in a different place.
It depends on what's the function. If you want to use the tritone-substituted G7 to modulate to the sharp fourth, you'd write it C#7 and resolve it to F# (or F#-).
C#7 is the name of a chord not a pitch and not Roman Numeral Analysis. [0]
The Roman Numeral analysis would be V7/#IV if you are modulating in C. And something else if you aren't in C. Roman Numeral Analysis is independent of key or tonal center. The Roman Numeral Analysis would be bII if you are not modulating because that's how Roman Numeral Analysis communicates.
Thinking about Phrygian mode. The two is always a bII.
{0} As an aside, in The Common Practice the bII is often notated N6 (for Neapolitan 6th) to set up a perfect cadence, i.e. I-N6-V-I.
multics emacs and lisp-machine emacs also predated gosmacs, which drew a lot of features from them, most notably being scripted in lisp (though gosmacs's lisp was a pathetic sort of thing called 'mocklisp')
Multics Emacs and the Lisp Machine EINE/ZWEI/ZMACS were also implemented in Lisp, they did not use an embedded scripting Lisp implementation. There is no boundary between an implementation and scriptling language, just one Lisp (Maclisp for Multics Emacs and Lisp Machine Lisp (aka ZetaLisp) for EINE/ZWEI/ZMACS), which in the case of the Lisp Machine also was used to implement the rest of the operating system and all its applications.
yes, and i should have said that, but gosmacs didn't copy that aspect of their design, just the ability to extend the editor in (mock) lisp
arguably gnu emacs is almost like multics emacs in this sense; the editing functionality of gnu emacs without any lisp code loaded is not actually zero but is pretty minimal. and i was surprised to find the other day that gnu emacs on my laptop is now compiling all my elisp to machine code, which is another similarity to maclisp, albeit a very recent one
For a similar situation today, there is the editor lem which is an Emacs-clone written in Common Lisp (and whose extension language is also Common Lisp).
more generally, though, even if you aren't using a gui library with a built-in text editor widget, gigahertz and gigaflops make it not especially challenging to write a usable text editor in a high-level language. http://canonical.org/~kragen/sw/dev3/edumb.py is 183 lines of fairly straightforward python and includes full-text search and infinite undo; it's not quite usable but pretty close. its really stupid buffer data structure might start to get unresponsive once you're editing a file in the neighborhood of 100k
Sadly, USB-HID does not define a hyper key, so no USB keyboard has a true hyper key. What one can do is configure the keyboard to emit a different, little-used key, and then configure X to recognize that key as hyper. I think what I do is emit left super for both super keys, and right super for both hyper keys, and then X turns right super into Hyper_L. Or something like that. This doesn’t bother me, because I don’t want to assign different meanings to the physical left and right super or left and right hyper keys — folks who do (e.g. for games) might not like it.
I also had to do a little bit of magic to get hyper recognised as a modifier.
It would be awesome if someone could get Hyper added to the official list of USB keyboard keys.
excellent! have you written up your configuration somewhere? are you using a public keyboard firmware?
at the other end of the spectrum, i just hacked together this stupid shell script to blindly reimpose my desired xkb configuration with lower-case parens yesterday: http://canonical.org/~kragen/sw/dev3/kbdd maybe you know the actually correct way to do this?
I actually own an original one (and some other goodies from my lispm time), I "just" need an adapter, but my electronics manufacturing / soldering talent is not adequate, sigh ;-0
If you're in the SF bay area, we might be able to get one put together... I've built several adapters for mice and keyboards, assuming the voltage levels are compatible it's mostly a matter of twiddling the right pins on a microcontroller. In return I would want to pick your brain about your lispm time :)
Obviously this is a joke, but the real message should be: if you can't manage your own memory, you should be using a language implementation with automatic memory management. If your code really needs to run "close to the metal", you really need to figure out how to manage your memory. In 2024, language implementations without automatic memory management should be reserved for applications that absolutely need them.
Funny, I think the lesson is the opposite: just because you have mechanisms that technically prevent memory leaks doesn't mean that you don't need to think about memory and its allocation/freeing. Or rather, memory leaks generally are not problem, unbounded memory consumption is, regardless if the consumption is technically due leak or some reference stashed somewhere.
> if you can't manage your own memory, you should be using a language implementation with automatic memory management.
I agree, and would expand the idea to all kinds of resources (files for example). Sadly not many languages have "automatic resource management". For example Go has automatic memory management, but if you read an HTTP request's body you have to remember to call req.Body.Close(). If you open a file you have to call file.Close(). If you launch a goroutine, you have to think about when it's going to end.
I'd like to know if some languages manage to automatically managed resources, and how they do it.
C# has Using. When the block ends the destructor is called.
VB Classic has reference counting and the terminate event is fired when the count goes to zero. So as long as you don't store the reference in a global the terminate event is guaranteed to run when it goes out of scope (so long as you don't have circular references of course).
C++ has Resource acquisition is initialization (RAII)
It obviously is a joke, but at the same time it's actually a viable approach for the right problem. Sometimes leaking is very tolerable and in terms of programmer time, very cheap!
Yes. Hence the word 'joke' I used. For short running programs, it's fine. The longer running programs you can often find a few places where 95% of the leaks happen and easily 'free' those leaving the last 5% to leak slowly. It depends. Just remember it's a valid solution sometimes.
The joke and the sometimes valid solution are different strategies.
The joke only reminds people of the valid solution. It feels like multiple people are giving the article the briefest skim and assuming the two are the same. Perhaps focusing on the words "optional to call free" and extrapolating off that without looking at the code or properly reading the rest of the text.
Dynamic scoping is usually implemented with shallow binding, where a single value cell for a variable is located at a fixed address, with each new binding saving and restoring the enclosing value on the stack. This allows constant time variable access, even in an interpreter working directly from S-expressions without a compilation phase. Lexical scoping in a pure interpreter requires a linear search through an environment. In compiled code, lexically-scoped variable access is more efficient than dynamically-scoped variable access, since it can be implemented with either a stack location at a fixed offset in the frame, or inside a closure object at a fixed offset.
