Various (and almost completely unrelated) questions and opinions

[Chris Pressey]

Torbjorn Tornkvist wrote:
> The code looks very nice.

Thanks.  I only hope I can now apply my newly acquired Erlang
programming skill to some truly useful purpose... like writing a
multiplayer online game :-)

More seriously, an Erlang spreadsheet (using GS, eval, and Mnesia) might
also be an interesting project; more ambitious, actually potentially
useful[1].

> The only thing I have to say is that in, for example, turtle.erl
> you have to do the following:
>  Shelly = turtle:new(),
>  Shelly! {fd, 20}.
> I would have wrapped the message sending in an exported function:
>  Shelly = turtle:new(),
>  turtle:fd(Shelly, 20).
> That way you have one interface less to worry about.

Now that I've read through chapter 5 of the book fully - I understand
completely and have updated the code accordingly.

> I like to encapsulate the message sending/receiving
> (i.e the protocol) within a single module (asynchronous
> messages can be taken care of by function call-backs).

I see.  I decided to make the turtle communication wait for a reply
message, so that it could return an error code.  The function
abstraction is exactly what allows these sorts of design decisions to
take place.

_chris

[1]  One thing that bugs me about most commercial spreadsheets is that
they make the user learn two very different "sublanguages" - one
(pseudo)functional for the spreadsheet calculations, one imperative or
object-oriented for the macro or scripting language.  An Erlang
spreadsheet application would use just one language, Erlang, as the
language used in cell calculations, macros, and the implementation of
the spreadsheet program itself.  I believe this would result in a
gentler learning curve, because what you learn about one area of the
application you can more easily apply to other areas.

-- 
Change rules.
Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List
http://www.catseye.mb.ca/list.html