This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Another use for Guile/Scheme/Lisp


I would recommend looking at the language "Obliq". The main implementation
of the language comes with DEC SRC Modula-3, but you can find the docs
independently.

The language has an infix syntax, but the structure of the language is very
similar to Scheme, and it does support distributed scope. An examination of
Obliq will provide you with many insights as to how data distributes well.
You can find a lot of good information in DEC SRC Reports 122 and 115.

You're right about the ease with which Scheme code can be transported and
executed elsewhere (or elsewhen). The main problem I see when doing these
things is the security model. There needs to be a clean way to write an
'eval' loop that does not have risky procedures available (like
'open-file'). Additionally having a way to impose quotas on an eval to
prevent a bit of code from running too long would be good to have. There
needs to be more to the model than "You have a certificate, so I'll trust
you entirely." What comes after that is Scheme as a "web language".

A Guile related question: What is the direction of Guile with respect to
R5RS?

> -----Original Message-----
> From:	Wade Humeniuk [SMTP:humeniuw@cadvision.com]
> Sent:	Wednesday, September 16, 1998 7:03 PM
> To:	guile@cygnus.com
> Subject:	Another use for Guile/Scheme/Lisp
> 
> I am sitting here trying to translate Python into Guile.  It has
> reminded me why I love the Scheme/Guile/Lisp language, or at least the
> external representation.  It is clean, formally specified and
> consistent...
> 
> Which reminds me.  A lot of the focus for Guile is as a extension
> language but there is an overlooked strength in the language and that
> lies in its ability to be a communication protocol/RPC implementation.
> The Scheme external representation can be used as an inter-process,
> inter-system and inter-platform protocol.  Its strengths are:
> 
> Builtin message delimiting, with the list parenthesis.
> 
> Platform independent data representation.  The OSI Presentation Layer
> bombed because of the complexity of representing external types across
> platforms and language specifications (i.e. ASN.1) .  The CORBA spec
> also goes to great lengths specifying language bindings.
> 
> You can use the builtin read/eval/print procedures by providing ports
> that allow interprocess communications.
> 
> You automatically have RPC functionality, with hardly any code added
> to a Scheme implementation.  An application sends a message which is
> eval(ed) by the peer.
> 
> The protocol allows one to extend the functionality of a peer (by
> defining new procedures in the peer) without having to revise the
> communication specification.  Using this you could reduce the
> bandwidth between peers by creating high enough abstractions.  The
> caveat being that the core functions are sufficient.  However with ffi
> abilities even this can be got around.
> 
> The protocol is readable by human beings.  I have spent many hours in
> front of protocol analyzers puzzling out a communications link.
> 
> In addition, other possibilties are: that a program could move its whole
> self for execution on a different system as it needed different
> resources, etc.  Of course issues like these need security measures,
> but with certificates, encryption and such this type of communications
> could be made secure.
> 
> 
> Wade.