[philly-lambda] Re: Programming Erlang

["Kyle R. Burton" <kyle.burton@gmail.com>]

I'm in the process of reading it, I've just gotten to the chapter
where he discusses Erlang's binary desturucturing bind and packing
feature, which was a pleasant surprise to see a feature like that
included in the language.

Getting into the functional mindset, as opposed to how I'm used to
thinking, is something that is developing for me more slowly than I
would want it to, but I am enjoying the book and Armstrong's writing
style.

I personally like how Java and Perl organize their libraries - module
name spaces which are laid out in a directory tree where the files
correspond to the class/package names.  From what I've read so far,
Erlang seems a bit flatter.  Am I missing something (am I just not far
enough in the book)?  Or is this different in Erlang since there is no
OO.  Its module system feels similarly flat to what I understand about
common lisp and the various module extensions I've used in the scheme
implementations I've worked with.

Ah, which leads to a question.  We are using scheme in an application
at HMS.  We have a matching application (matches profile information
between databases with varying structure/relational data models).  In
that application, we allow users to specify precisely how they want a
match to happen via an s-expression based expression language
(Matching Criteria Expression Language) which is processed via
JScheme.  Looks something like this:

  (match-plan
    (alias (shares-an-address-with-x-miles (x Integer)) ...)
    (match-rounds
      (match-round
        (accept-one-result)
        (or
          (shares-an-address-wtihin-x-miles 1.5)
          (and
            (shares-address-in-same-city-state)
            (indiv-name-edit-distance-similarity 0.85)))))
      (match-round
        ...)))

And 'compiles' it into JScheme code which when evaluated constructs
various Java objects.  In addition to the basic compiler, we also
perform (or are going to perform) various kinds of analysis and
re-writing of the AST for optimization purposes and to create an
execution plan for carrying out the processing on a cluster of boxes
(using various intermediate cached results [indexes], or pruning
specific branches if they are unreachable due to data types not being
present in the subject records, etc)..

So, now for the question: there is a growing amount of scheme code for
doing the MCEL handling, AST analysis, etc.  Right now we just have it
broken down into a handful of files and are making use of JScheme's
use-module (we have to use 'load' for macros/syntax-rules).  Do any of
you have good conventions for organizing large amounts of lisp/scheme
source code to keep things maintainable and so that it is not
confusing looking at a particular piece of code to know where specific
functions or macros are defined?  JScheme's use-module allows things
to be prefixed by the importer, and I haven't seen if there is some
way for the importee to decide what can and can not be imported or
accessed by another module.

Any advice?


Thanks,


Kyle


On 7/25/07, Toby DiPasquale <codeslinger@gmail.com> wrote:
>
> Hi all,
>
> As Philly Lambda started out as an idea to start an Erlang group and
> Erlang is tres chic right now, I was wondering how many of you had
> looked at the new Programming Erlang book by Joe Armstrong:
>
> http://www.pragmaticprogrammer.com/titles/jaerlang/index.html
>
> I just got it in print form earlier this week and I have had the
> various beta PDFs for some time now. Personally, I think the book is
> great and the mailing list is very friendly and helpful (for now).
>
> Anyone else read it? I can bring my copy to the first meeting if
> people want to browse through it a bit.
>
> --
> Toby DiPasquale
>
> >
>


-- 
------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
kyle.burton@gmail.com
http://www.neverlight.com/~mortis
------------------------------------------------------------------------------

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Philly Lambda" group.
To unsubscribe from this group, send email to philly-lambda-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/philly-lambda?hl=en
-~----------~----~----~----~------~----~------~--~---