Simon Thompson

Simon Thompson

Academic at the University of Kent, where I am Professor in Logic and Computation in the School of Computing. You can find out more at my

Location Canterbury, Kent, UK


  • Well, it's nice to see how far you can get with just pattern matching :-)

  • And just to confuse things, strings don't really exist in Erlang: they are "just" lists of ASCII codes …

  • What Brujo says is one of the strong customs of the Erlang community. So much so that I didn't realise that there was an import statement in Erlang for quite some time.

    It's interesting that the pragmatics of a language are as important as its syntax and semantics.

  • That's one reason it's really nice to teach!

  • Thanks for all the sharing in this step!

  • The story I know is that they tried a lot of languages, and found that none provided everything that they wanted. Hence a new language. The original interpreter was written in Prolog, so some of the syntax got carried over.

  • @AndrewMatthew fair enough. And I am guilty of using the maths here, but there's an interesting discussion to be had about how teachers' expectations feed into pupils' perceptions. If the former project that something is difficult, then that is picked up very clearly by the latter.

  • Hi Chaitanya. The whole function definition of `area` ends with a full stop, but the definition consists of two expressions: these are evaluated one after another, and the result of the function is the result of evaluating the last expression.

    In this case, in the first the name S is given to the formula on the right hand side, and then this S is used in...

  • @AndrewMatthew good points. I'm not completely sure about the math concepts, though. The idea of a function as a transformation of inputs (values) to outputs (values), rather than side-effects on storage, seems simpler conceptually, but maybe that's just showing my bias.

    And OK, I *do* use numbers for recursion, but as soon as lists are introduced then they...

  • It's interesting that type systems for Erlang are a hot topic again: facebook/whatsapp are looking at one, and Josef Svenningson has been developing a "gradual" type system for Erlang: gradualizer

  • Aha! Intriguing.

  • Yes, I think that was one of the few mistakes made in the design of Elixir.

  • Thanks for your additional comments here!

  • Simon Thompson made a comment

    Hi everyone - great to see you here, and I look forward to working with you on this MOOC.

    Do please use all the resources you find: each page has a _comments_ section, and I'd like to encourage you not only to ask questions, but also answer others questions too.

    We're joined by a number of experienced Erlangers from the Erlang Ecosystem Foundation who...

  • Doh! Sorry that I have been so slow in understanding this. I see that you have the set_trap_exit functionality exactly as it is because of the way that you allow your clients to have possession of multiple frequencies at any one time. I had really not envisaged this as a use case, and assumed that each client held at most one frequency at any time.

    So, to...

  • I wasn't sure that I understood the logic you have for dealing with trap_exit. In particular, what is behind the call set_trap_exit(NewFreqs) in the case that NewFreqs is not empty, but a successful de-allocation has taken place?

  • Did you think about getting the client to set trap_exit to true (for some parts of its execution)?

  • That's a fascinating question. I think that the answer is mainly that OTP got things broadly right, and that the sophistication of the implementation and design means that there's a big cost to re-developing something similar.

    The Erlang community is small and cohesive, but that's not been a bar to the development of different build tools, web frameworks...

  • Thanks for the comment about deallocate as call or cast. I partly chose the cast to make the contrast with call, but you're right that an acknowledgement would be a good thing, in general. On the other hand, it's certainly not necessary for the client to continue, so it's a matter of taste, I guess.

  • It's possible to include specs for the gen_server callbacks, and we should think about doing that.

  • Thanks, Victor!

  • We need to take on board that it's taking people more time … four weeks could work, and we'll definitely think about that. Thanks for the feedback!

  • Sure there are Erlang meet ups in Stockholm, and maybe Göteborg too?

  • Messages to non-existent processes are simply dropped … is that what you meant?

  • Once we start looking at distributed systems, then how systems recover becomes a lot more application-dependent. Francesco Cesarini's new book discusses this in the later chapters

  • Inheritance is less straightforward. It's not hard to see Erlang as an object-based language, where objects are represented by processes and communication is via message passing; however there's no straightforward representation of inheritance without building an explicit model of it: rather ugly.

  • Manfred - that could indeed be a problem, but the asynchronous nature of Erlang message passing avoids a whole lot of potential scenarios for deadlock.

  • State can be persisted in a number of ways: by the arguments to a tail recursive function, by putting the state in a message to the process itself (a bit like "delay line" storage from the 1940s), or using an ETS table; some details about this are in the companion MOOC on functional programming in Erlang.

  • Hi Douglas - if you check out the documentation for the erlang module you'll see that link takes one argument, but monitor takes two, but also in that case, the relationship is made between the process in which monitor/2 is called and the second argument which is a Pid; the first is the atom process (distinguishing this...

  • I've also added some comments about this to the feedback video scheduled from the last step of week 2.

  • That's right.

  • Victor, that's exactly right. Concurrency is about *independence* of processes, rather than explicit parallelism. I should also have been clearer about steps …

  • Hi Florian - sorry to hear that. There are some pre-compiled Erlang versions at the Erlang Solutions website but perhaps not for your particular flavour of Linux.

  • Hi Jose - thanks for the question. The point is here that you have killed the existing process with reason kill, but the linked process will not receive a message with reason "kill" but with reason "killed", which is trappable.

  • We're still looking into the "extended video" problem …

  • Douglas - no, no monads in Miranda: the special flavour of Miranda was laziness + strong types, including user-defined types.

  • Thanks for the "heads up" on this … we'll look into it.

  • We talk about this in the next step. You're right that this is a potential problem: if you don't match on every kind of message then it's possible to miss some, and for these to accumulate in the mailbox.

    One way to avoid this is always to include a "catch all" clause in receive statements, but that may not be appropriate in all cases. Alternatively it's...

  • I'm using Visual Studio Code, which seems to work a treat (also for other languages).

  • What is meant here by "asynchronous" is that it's not necessary for message send and message receive to be synchronised. A message can be sent without the receiver actively participating at the time of sending. For this to work, messages have to held somewhere pending their being processed by the recipient: hence the mailbox. Given the example in Ed's posting...

  • The key Erlang construct here is the timeout of zero on a receive clause: this means that we can process all (and only) the messages already in the mailbox. We can just throw them away, or process them more actively.

  • Just to be clear about upgradingl: after upgrading you have indefinite access (bounded by the life of the course itself, I guess). The other thing to be aware of, is that "If you choose not to upgrade, you can still access the majority of the course for free, for the duration of the course plus two weeks – regardless of when you join”. This quote is from the...