Various (and almost completely unrelated) questions and opinions

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

Chris Pressey
Thanks to everybody for your help; in the open-source spirit I'd like to
give something back to the Erlang community.

I've written some little Erlang modules in the course of learning
Erlang, and they can be found at http://www.catseye.mb.ca/erlang/ 
They're nothing special, since there are already plenty of good examples
of Erlang code out there, and none of these modules are suitable for any
particular worthwhile application (except maybe Turtle Erlang?)

If you happen to have a look at any of them, I'd be curious to know.
Have I made any flagrant violations of coding style, convention etc?
(Don't bother mentioning that I should have used yecc for VALGOL - I
intentionally did it the hard way to see what it would be like.)

Are there any namespace issues?  Am I safe distributing these modules as
modules, or should I wrap them into applications for more insurance?

On general topics, are there any testimonials to the suitability of
Erlang's Inets package as a web server outside of an embedded
environment - for a real web site (with low-to-moderate traffic)?

Are there any noteworthy Erlang projects outside of Erlang's assumed
application domain?  Specifically, I'm thinking of projects like
retail accounting and online games like MUDs.

On programming topics, is there any way (using the digraph module) to
find a vertex (or edge) in a graph given its label (short of a linear
search through the list that is returned by vertices())?  (Using such
a function would make Wumpus much cleaner.)

Semicolons and commas would be nicer if extraneous ones were allowed,
however I see now why it is more problematic to do so here, where
semicolons and commas have very different semantics from each other.
(Compare to Perl or C, where ; and , have almost the same semantics.)

Speaking of which, if comma roughly means "and" and semicolon roughly
means "or" then the following would make sense to me but is not
considered legal by the compiler:

  fib(1; 2) -> 1; fib(N) when N > 2 -> fib(N-1) + fib(N-2).

That may be too risque as well.  Partly what I'd like to see is a sort
of "Dangerous Erlang" which trades off some of the safety and
predictability for flexibility and expressivity.  Is there any other
programming language out there which claims to be a descendant of
Erlang, or lists Erlang as one of its influences?  (Barring anything
that claims it's a direct "subset" or "superset" or "extended subset" of
Erlang)

Whew!  Sorry if that's too many questions at once.  Thanks in advance
for any help.

_chris

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


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

tobbe

The code looks very nice.
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.
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).

Cheers /Tobbe



Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

tobbe

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

That would be very cool !

JFYI: Tony (Rogvall) made a spreadsheet program some
years back. However, I think it has rotten away now...

Cheers /Tobbe


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

David Gould-2
In reply to this post by Chris Pressey
On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote:
...

> Speaking of which, if comma roughly means "and" and semicolon roughly
> means "or" then the following would make sense to me but is not
> considered legal by the compiler:
>
>   fib(1; 2) -> 1; fib(N) when N > 2 -> fib(N-1) + fib(N-2).
>
> That may be too risque as well.  Partly what I'd like to see is a sort
> of "Dangerous Erlang" which trades off some of the safety and
> predictability for flexibility and expressivity.  Is there any other
> programming language out there which claims to be a descendant of
> Erlang, or lists Erlang as one of its influences?  (Barring anything
> that claims it's a direct "subset" or "superset" or "extended subset" of
> Erlang)

Hmmm, I am thinking, "typeless Haskell" ;-)

-dg
 

--
David Gould                davidg               510 536 1443
If simplicity worked, the world would be overrun with insects.


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

Chris Pressey
David Gould wrote:
> On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote:
> > [...]  Partly what I'd like to see is a sort
> > of "Dangerous Erlang" which trades off some of the safety and
> > predictability for flexibility and expressivity.  [...]
> Hmmm, I am thinking, "typeless Haskell" ;-)

Well, not entirely typeless - for that I think you have to go back to
the lambda calculus itself or "alternative" languages like Unlambda,
where there is only one "type", the function.  Erlang has a type system,
it is just not strongly typed (but there are seperate static analysis
tools to do that, too.)

Also I like Erlang's eager evaluation much better than Haskell's lazy
evaluation.  It is easy enough to build a lazy evaluator in Erlang if
you need one.

I've heard it said that "the number of Haskell programmers worldwide
could fit in my bathroom" - Erlang's takeup may not be explosively
large, but I think more people are actually *using* it for something,
than Haskell.

IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the
best blends of sophistication & expediency since... well, since C!

I've had some thoughts about overloading operators, btw.  I think it's
only of limited use unless you can have user-defined functions in
guards.  This is assuming that the semantics of any overloaded operator
are expressed by a user-defined function, and that relational operators
can be overloaded.

As an example, I would like to write code like this, in some sort of
idealized Erlang-like language, simply for readability and clarity:

  delivery_charge(Shipment) when Shipment.distance > 5km ->
    $5.00/km * (Shipment.distance - 5km);
  delivery_charge(Shipment) -> $2.00.

Obviously, I could write code which does exactly the same thing in
Erlang, but it would be relatively ugly and cumbersome.  Instead of the
">" operator, I'd have to use a measurement:greater_than() function,
which is a more awkward syntax, and can't be used in a guard either.
The literal units of measurement would as well have to be expressed as
fairly awkward-looking function invokations like measurement:new(5.00,
[{'$',1},{km,-1}]). Overloading only solves one of these problems, the
rest remain and must be worked around by other means.

The result is that I think I will continue on the path of writing a
little language around the measurement data type, since Erlang alone
can't handle it very nicely.  The good news is that this little language
will be heavily influenced by Erlang and the compiler will probably be
written in Erlang and translate to Erlang - sort of a sublanguage for
modules which rely heavily on manipulation of values with units of
measurement.

_chris

--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

David Gould-2
On Mon, Feb 19, 2001 at 06:29:19PM -0600, Chris Pressey wrote:

> David Gould wrote:
> > On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote:
> > > [...]  Partly what I'd like to see is a sort
> > > of "Dangerous Erlang" which trades off some of the safety and
> > > predictability for flexibility and expressivity.  [...]
> > Hmmm, I am thinking, "typeless Haskell" ;-)
>
> Well, not entirely typeless - for that I think you have to go back to
> the lambda calculus itself or "alternative" languages like Unlambda,
> where there is only one "type", the function.  Erlang has a type system,
> it is just not strongly typed (but there are seperate static analysis
> tools to do that, too.)

Well, it was sort of a joke. It is just that since there is a constant
flamewar on comp.lang.functional about the necessity (or is it morality)
of strict typing, I decided to learn a little about haskell too.

Without insight, it is pretty on the page. Which I find to be a very
good first discriminator for languages. Ugly source text, ugly all the way
down. Canonical example: C++.

> Also I like Erlang's eager evaluation much better than Haskell's lazy
> evaluation.  It is easy enough to build a lazy evaluator in Erlang if
> you need one.
>
> I've heard it said that "the number of Haskell programmers worldwide
> could fit in my bathroom" - Erlang's takeup may not be explosively
> large, but I think more people are actually *using* it for something,
> than Haskell.

Well yes. I do know of a few people doing things with ocaml though, so
it might be as widely used. But from the little I have looked at it, it
seems to not quite pass the ugly test. All the let in and in and in ...

> IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the
> best blends of sophistication & expediency since... well, since C!

Very good, I like the observation about the blend as applied to C. I used
(back in the early 80s) to love C, but it gets worse as time goes by and
really is not a good choice for most of the things people use it for.

I agree, the blend of beauty and ruthless pragmatism in Erlang is rarely
found.

And you can even use the curly braces for something (the essential criteria
for language success as far as I can tell from the recent historical
evidence ;-)).

More later, I have a wife yelling something about dinner now....

-dg

--
David Gould                davidg               510 536 1443
If simplicity worked, the world would be overrun with insects.


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

Lon Willett
In reply to this post by Chris Pressey
Chris Pressey <cpressey> writes:
 [snip]
> Also I like Erlang's eager evaluation much better than Haskell's lazy
> evaluation.  It is easy enough to build a lazy evaluator in Erlang if
> you need one.
 [snip]

I prefer the eager ("strict") evaluation too, as a default.  But there
are some nice things that can be done with lazy evaluation: streams as
lists, some clever data structures, etc.  And it is not so trivial to
write a lazy evaluator; any reasonable implementation would require
changes to the VM.

I briefly (as in for a few moments; then reality set in and I moved on
to more pressing matters) considered modifying the beam type system to
support "promises", or whatever one wants to call the delayed-
evaluation objects.  It probably wouldn't be too hard, but there are
some tricky issues as to what one should do with them when they are
passed in a message, or passed to term_to_binary.  If someone else has
implemented this, then I'd be interested in the results.

And while on the topic of useful language extensions: has anyone
implemented weak-reference ets tables?  (Actually, with weak-reference
ets tables, one could write a lazy-evaluator that has almost
reasonable performance, although I suspect that the memory usage
characteristics would lead to a bit of thrashing).

/Lon

--
Lon Willett <Lon.Willett>
Security Architect, SSE Ltd.
Fitzwilliam Court, Leeson Close
Dublin 2, Ireland
+353-1-216-2946
+353-87-8053539 (mobile)


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

Robert Virding-4
Lon Willett <Lon.Willett> writes:
>And while on the topic of useful language extensions: has anyone
>implemented weak-reference ets tables?  (Actually, with weak-reference
>ets tables, one could write a lazy-evaluator that has almost
>reasonable performance, although I suspect that the memory usage
>characteristics would lead to a bit of thrashing).

That would be very difficult as ets tables do NOT share their data with
anything.  Each table creates a local copy of all data inserted in it
and on lookup data is copied back.

        Robert




Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

Lon Willett
Robert Virding <rv> writes:

> Lon Willett <Lon.Willett> writes:
> >And while on the topic of useful language extensions: has anyone
> >implemented weak-reference ets tables? [snip]
>
> That would be very difficult as ets tables do NOT share their data with
> anything.  Each table creates a local copy of all data inserted in it
> and on lookup data is copied back.

Oops.  I knew that.  Some kind of weak reference would be handy
though.  (ets tables just jumped to mind because of familiarity with a
few lisp/scheme implementations of weak-reference hash-tables).

Hmmm.  Maybe a per-process table: put_weak and get_weak?

Oh well.  It's not so important.  Weak-references have always struck
me as rather a kludge anyway (but a useful kludge, for a certain
subset of problems).

/Lon


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

Chris Pressey
In reply to this post by Lon Willett
David Gould wrote:

> On Mon, Feb 19, 2001 at 06:29:19PM -0600, Chris Pressey wrote:
> > David Gould wrote:
> > > On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote:
> > > > [...]  Partly what I'd like to see is a sort
> > > > of "Dangerous Erlang" which trades off some of the safety and
> > > > predictability for flexibility and expressivity.  [...]
> > > Hmmm, I am thinking, "typeless Haskell" ;-)
> > Well, not entirely typeless - for that I think you have to go back to
> > the lambda calculus itself or "alternative" languages like Unlambda,
> > where there is only one "type", the function.  [...]
> Well, it was sort of a joke. It is just that since there is a constant
> flamewar on comp.lang.functional about the necessity (or is it morality)
> of strict typing, I decided to learn a little about haskell too.

Ah, understood.  Advocacy is a strange and terrible thing.  Sure, static
analysis is a good thing that saves time and energy.  On the other hand,
it's not impossible to write a program without it, and there are always
other factors to consider.  Erlang's philosophy of being fault
*tolerant* doesn't strictly need static analysis.  But it's always nice
to have it on the side.

All in all, I like ML better as a generic example of a functional
programming language.  It hasn't got all the fancy stuff Haskell has in
it, so (for me) it was easier to understand.  (Then again I'd say the
same thing with respect to Pascal and C in imperative programming.)

> Without insight, it is pretty on the page. Which I find to be a very
> good first discriminator for languages. Ugly source text, ugly all the way
> down. Canonical example: C++.

It's a good rough judgement, but sometimes it lies too.  Perl is ugly to
look at and mostly (but not entirely) ugly underneath.  Python is nice
to look at but (as I understand, not being a big Python programmer) not
entirely nice underneath.

> > I've heard it said that "the number of Haskell programmers worldwide
> > could fit in my bathroom" - Erlang's takeup may not be explosively
> > large, but I think more people are actually *using* it for something,
> > than Haskell.
> Well yes. I do know of a few people doing things with ocaml though, so
> it might be as widely used. But from the little I have looked at it, it
> seems to not quite pass the ugly test. All the let in and in and in ...

O.Caml was one of the original attempts to combine object-oriented and
functional programming, and a pretty naive one in my opinion.  A direct
combination leads to a lot of redundant functionality, which can make
building new code easier ("there's more than one way to do it") but also
makes maintaining existing code harder.  Just my opinion of course, I
know some people who swear by O.Caml.

> > IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the
> > best blends of sophistication & expediency since... well, since C!
> Very good, I like the observation about the blend as applied to C. I used
> (back in the early 80s) to love C, but it gets worse as time goes by and
> really is not a good choice for most of the things people use it for.

Me too.  C is a "systems-construction" language, and as I was doing more
stuff further and further away from "constructing a system", I started
using Perl; mainly for the garbage collection and regexps.

But my day job involves extremely expedient languages like Perl and
Business BASIC and various scripting languages for various specialty
software packages where control is utmost and abstraction is, well,
nearly absent; so it's little wonder I'll cherish any beauty (like
single-assignment) that shows up in an otherwise expedient language.

> I agree, the blend of beauty and ruthless pragmatism in Erlang is rarely
> found.

Erlang, one of the few (only?) functional languages genuinely suited to
a production environment?

> And you can even use the curly braces for something (the essential criteria
> for language success as far as I can tell from the recent historical
> evidence ;-)).

Absolutely :-)

Lon Willett wrote:
> Chris Pressey <cpressey> writes:
>  [snip]
> > Also I like Erlang's eager evaluation much better than Haskell's lazy
> > evaluation.  It is easy enough to build a lazy evaluator in Erlang if
> > you need one.
>  [snip]
> I prefer the eager ("strict") evaluation too, as a default.  But there
> are some nice things that can be done with lazy evaluation: streams as
> lists, some clever data structures, etc.

Well, clever is clever.  I dunno - I'd rather leave being clever, up to
the programmer, I guess.

> And it is not so trivial to
> write a lazy evaluator; any reasonable implementation would require
> changes to the VM.

It all depends on what you want to evaluate.  If you wanted to lazily
evaluate arbitrary Erlang code (complete with send and receive?) then
yes, you'd have to make some major changes.  But I was thinking merely
numerical expressions, like a "symbolic calculator", which would be far
easier; in fact I think there's some example code for one in the
extensions doc.

In fact, if you consider erl_eval et al as part of the language, then
there is your means of delayed (if not formally "lazy") evaluation right
there.

It all depends what you need out of lazy evaluation, and yes, while it
makes possible some clever tricks, are there very many problems that
really call for full lazy evaluation?  It seems to me more real-world,
production-environment problems actually call for eager evaluation -
make sure everything is resolved as soon as possible.  So I see Erlang's
design decision as a fairly wise one.

One of the main drives towards lazy evaluation (it seems to me) is the
desire for if(e,t,f) to be just like any other function, yet for it to
be short-circuiting, so that f isn't evaluated unless e is false.  It
strikes me that lambda functions for t and f could serve this purpose -
but Erlang isn't even in a position where 'if' is supposed to be a
function, so I can't see there being a lot of call for it here.

> I briefly (as in for a few moments; then reality set in and I moved on
> to more pressing matters) considered modifying the beam type system to
> support "promises", or whatever one wants to call the delayed-
> evaluation objects.

I think in Erlang they should be called "funs" :-)

_chris

--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html


Reply | Threaded
Open this post in threaded view
|

Various (and almost completely unrelated) questions and opinions

David Gould-2
In reply to this post by Chris Pressey
On Mon, Feb 19, 2001 at 06:29:19PM -0600, Chris Pressey wrote:
...
> I've had some thoughts about overloading operators, btw.  I think it's

Have you looked at Oberon? I am somewhat persuaded by the Oberon rationale
against overloaded operators. Oberon is roughly my idea of what a C level
language with objects should have been. They claim extreme simplicity is
a good thing. To back it up, the Oberon language specification is coherent
and complete in something like 28 pages. See other simple languages, eg
R5RS for contrast.

Anyway, the Oberon argument is that code should be understandable by
reading it. That is, what is being done and the cost of doing it should
be apparent by looking at it. The problem with overloading is that "A + B"
could mean anything, eg "blend these two 80MB images", and it is not obvious
from the immediate source what the heck is going on or what it might cost.
Not without finding the declarations of A and B and '+' and understanding
how overloading selects implementations, all of which in the worst case
(c++ again!) are stored in separate files in separate directory hierarchies.

At least for the Oberon system designers, this appears to work, they have
produced some pretty fantastic stuff that runs on ridiculously low
resources.

One of the things I like about Erlang is that it too has an emphasis
on "textual transparancy" and simplicity. Except possibly in how I/O is
really done...

> only of limited use unless you can have user-defined functions in
> guards.  This is assuming that the semantics of any overloaded operator
> are expressed by a user-defined function, and that relational operators
> can be overloaded.

I like the rationale for the restrictions on guards, that they are
restricted to known time or constant time operations without side
effects. It means a less flexibility, but if guards could be arbitrarily
expensive, then people would start contorting code in other ways to avoid
using guards or something. A net loss I think.

-dg

--
David Gould                davidg               510 536 1443
If simplicity worked, the world would be overrun with insects.