Re: So confused with scheme options

On Dec 21, 1:54 pm, Aaron W. Hsu <arcf...@xxxxxxxxxxx> wrote:
5lvqbw...@xxxxxxxxxxxxxx writes:
Conclusion: I'm totally confused.  I'm not understanding what are
considered language extensions, what are built-in srfi's that are
somehow automatically loaded, and why the same procedure seems to
exist in one but not in the other.

In the Scheme community, there is what I will call a hierarchy or
tower of libraries and procedures.  It goes something like this:

        1. Revised Reports (R{4,5,6}RS)
        2. Scheme Requests for Implementation (SRFI)
        3. Well known Libraries (Oleg's Code, SLIB, &c.)
        4. Implementation Extensions

When you are evaluating a given implementation, you should first,
usually, examine it to discover to which Revised Report it most
closely adhers.  This can actualy be quite a task in some cases.

This will give you an idea of the base functionality that you should
be able to find anywhere in the system provided you follow the
standard.  Of course, this isn't strictly true, but it is a good
start.

Next, you can usually expect that the implementation will implement
some level of SRFIs, or at least be able to run the portable
SRFI Reference source that is provided in the SRFI documents.  How
you get to these procedures varies with each implementation.  

Usually implementation that have some sort of library system will
also have libraries already written for the major extra libraries,
or someone will have written code to run these libraries under your
implementation.

The real kicker is #4.  Here, you will want to read the documentation
that comes with the implementation.  The quality and clarity of
this documentation varies as widely as do the implementation designs,
but usually you can find out some key things:

        1. How to access a given procedure.
        2. How to run programs.
        3. How to load programs.
        4. What additional extensions are provided.

Many times the implementation will mix all of the library tower #2
through #4 into one document.  Splitting this document's content
into the three different sections requires your knowledge of the
existing libraries, of SRFIs, and of the Revised Reports.  In fact,
in general, you need to first grasp the Revised Report of the
implementation you are using.  Use that as your starting point.
Start playing with, and writing code written using that report, and
use the manual for your implementation to determine how to run the
code you have written.  Once you have done this, you can usually
start getting a feel for how that implemenation does things, and
you'll be able to expand into using other libraries.

One thing you should watch for is the module system and/or library
system of the given implementation.  Many implementation do not
just throw everything into the main default environment for you to
use, but instead divide them up into modules or libraries that must
be imported first.  The way that you import these libraries into
your system differes with each implementation, but usually this is
documented in the same place that you can find the extensions.

Nor have I found a consistent say of loading up libraries, .ss
files, "modules", (require ...) (load), (this-thing/that-thing.ss),
(rnrs), etc.  It's so inconsistent I'm not even sure what I'm talking
about.

Depending on the Revised Report that you choose, you will not find
a consistent way of loading programs.  This is one things that
Scheme tends to leave up to the implementation.  In R5RS, there is
only one way of getting new code into the system, and that's using
LOAD.  However, almost all implementation provide an extension to
allow you to load them some other way, suchas with using REQUIRE
or IMPORT.  You need to read the documentation for your implementation
if you want to discover the right way to access built-in libraries,
or load your own that you grab from somewhere else or write yourself.

In R6RS, all code written as a LIBRARY form lets you IMPORT your
libraries in, but the way that the libraries are accessed differs
by system, so you still need to read up on how that works.

What I need is a one-hour verbal primer from an actual human expert
to explain this.  I understand scheme implementations are different,
etc., so that's what I'm trying to grok so I know how/where to spend
my time, and understand what's considered a basic part of the
language, what's an expected library function for most implementations,
and what's a really special thing with some particular implementation.

The best advice I can give you is to stop trying to understand this
as a newbie.  You are still learning, and wandering around the
jungle without any understanding is a good way to fall into all
sorts of tar pits.  At your stage, it's easiest for you to pick a
single implementation (and it really doesn't matter which you choose
at this point), and start writing code in it.  You shouldn't worry
whether this code is portable or not.  In fact, most code written
is not written with a strong emphasis on portability.  Instead of
worrying about those details, just enjoy writing programs.  When
you start to get good with this stuff, you'll naturally come to
understand how the procedures you use are different than what is
in the Report, or that this procedure is a SRFI, and this one an
extension of blah or whatever.  Later on, switch Schemes and use
another, and you'll instantly see where the two are similar and
where the two differ.  In other words, get a little footing somewhere
first, and then you'll be able to move around the jungle without
feeling so lost.  After time, you may settle on the same spot you
started, or you may end up somewhere else, but regardless, you'll
get there much faster if you have a point of reference.

* PLT mzscheme seems to require a #lang directive, which I've
concluded directs the interpreter to take certain assumptions into
account, set parameters about case sensitivity and/or how strictly it
conforms to r5rs, and loads up some procedures that are desribed in
the plt guide.  It looks like DrScheme gui/ide by default uses
mzscheme, since it seems to require the #lang directive at the top.

This is the "module" language of PLT, and it's not R5RS.  In fact,
it's probably closer to R6RS, but even that's not true.  PLT SCheme
does a lot of different stuff, but the main difference, that I can
think of is the immutable pairs in the module language.  If you
want to use one of the Revised Report languages to start with, you
can do something like #lang r6rs and you should get strict R6RS
semantics, or close enough for you that it shouldn't matter.

* Chicken and gambit don't understand any #lang directive

The #lang directive is a PLT extension.

* The only way to get the plt guide stuff to work is to run mzscheme
with a "#lang scheme" directive
* Running plt-r5rs isn't the same as "#lang scheme"

PLT is an umbrella brand for a bunch of languages, including their
implementation of R5RS, R6RS, Lazy Scheme, Typed Scheme, and the main
"module" language that they have as default from #lang scheme.

* with "#lang scheme" in mzscheme I get simple procedures like format,
which I have found as srfi-28, and a bunch of other stuff in the plt
guide that sometimes works in chicken and usually not in gambit, where
gambit seems more bare-bones and chicken has some of this built in.
No pun intended.

Gambit probably does not provide you with the built-ins right off
the bat.  I think there are some libraries that are available with
it, but you would have to check the documentation to see how to
load them in, as it's almost certainly different than Chicken.  If
it doesn't provide what you want, then you can check out the reference
implementation of SRFI-28 for example, and just use that code
instead.  Usually this is pretty easy.

In other words, don't worry about what is built-in or not right
now.  People who use the "bare bones" implementations as you call
it, usually just grab the libraries from somewhere else, so this
isn't relaly going to hamper you in the long run.  Really, you
should get comfortable with grabbing code that's not built-in, it's
good practice, and gives you an idea of how different implementations
handle the grabbing of libraries.  Chicken has its eggs, PLT has
PlaneT, SCM relies heavily on SLIB, Chez generally expects you to
grab them yourself, &c.

* without "#lang scheme" in plt-r5rs, it doesn't like it when I call
(format "string" blabla).

You would need to import the FORMAT library somehow.

* with "#lang scheme" in plt-r5rs, it doesn't like my next line, which
is  (define...) (define: not allowed in an expression context...)

In the R6RS semantics you find with scheme -- at least I think it's
R6RS semantics -- in any given module, the definitions must come
before any expressions. So you can not have something like:

        (define x 1)
        (+ 1 x)
        (define y 2)
        ....

* print vs printf vs display vs write

PRINT and PRINTF are generally extensions, where as DISPLAY and WRITE
are R5RS and R6RS.

So I have a few overall/overview/big-picture questions:
* Are all the differences in which procedures are available by default
desribed in one SRFI or another?

SRFIs are for specifying new functionality or libraries, and they
will not tell you what is or is not available where.  If you want to
know what is available by default, and what isn't, and what you have
to load in, and what you don't have to, you should check the
implementation documentation.

* If r5rs is a spec, then why the PLT consider differences to this a
different "language", rather than a set of macros, etc., which are
loaded in as a library?  What is the dividing line between what's a
language extension vs. a library?

Language extensions can do things that libraries can't.  For example,
PLT implements many language extensions, such as immutable pairs,
which change the actual language semantics, and not just what
procedures are available for use.  Libraries usually add new macros
or procedures that can be used, by they do so in the context of the
language specification.

PLT Scheme is notorious for changing the language semantics, and
you will find a lot of different languages in the PLT System that
you can use.  You will find things that are different from the
report, because PLT's base language is *not* equivalent to the
language standards.  It is usually possible to use the libraries
in PLT in most of the languages, however, but not possible for one
language, such as R5RS, to use the features (such as immutable
pairs) of another language, such as the base language, or the
LIBRARIES of R6RS.

* In theory, can I find the SRFI code (either in an installed library
or cut-and-paste from the SRFI page), and dump it into an r5rs
implementation and have it work in any r5rs-compliant implementation?

If you want to use a SRFI, first check whether that functionality
is already available through the implementation's system.  If not,
then you can grab the "reference implementation" usually available
in the SRFI document.  You then need to read through that reference
implementation.  The comments will usually tell you on what the
code depends.  You will then need to make sure that you provide
those features to the code when you load it.  For example, some
code may expect a certain type of ERROR procedure be available,
such as one specified in another SRFI, or some specific form, which
differs from the normal implementation's ERROR form; you would need
to get or make your own ERROR procedure of the same type so that
you can load the SRFI code.

Once you have satisfied the dependencies for the SRFI code, load
it into your system in the way the documentation indicates you
should, and voila.  For example, on a strictly basic R5RS system,
you may have to LOAD the file before using it.  However, in a Chicken
system, you may wrap the SRFI code in a module declaration, and
then use the import form after loading the file through the command
line or making an egg.  in PLT, you may make a module and then do
whatever it is that they want you to do.  If you are using R5RS,
then usually LOAD is the safest and most straightforward way to
start.

* Assuming I learn how to "do" libraries/modules, where they are,
etc., can I use a module/lib from implementation X in implementation
Y?  I'm still in section 4 Expressions and Definitions part of plt-
guide and I haven't gotten to the part about libraries/modules.

Strictly speaking, any library written in a given language, will run
on another implementation of that language, provided that you make
sure all the dependencies are satisfied.  In practic, this can be a
task, especially if you are trying to port PLT code to other systems.
The reason for this is PLT's language is not the same as it is in other
implementations.  

I have ported code from one system to the other with little difficulty,
but it does require that you make sure things work.  As a working
example, let's take two libraries.  I took MIT Scheme's Red-black tree
implementation and made it to run in Chez.  I did this by adjusting
the ERROR procedures to work, and I had to change the record
definitions, because the systems did not agree in those aspects, but
other than that, it wasn't hard.  Another, was porting foof loop from
R5RS code to R6RS, which mostly required me to change the upper case
to lower case, because R5RS is case-insensitive and R6RS is not.

A smaller question:
* Is there a comand line option to mzscheme which allows me to avoid
using the #lang directive?  This way  I don't have to comment out the
first line when I run chicken or gambit.

If you are really trying to make portable code, it's usually best to
separate out the parts that are implementation dependent.  For example,
you might write your main code without modules or any directives,
just assuming that the procedures are available, and then have separate
files for each implementation which INCLUDEs this code.  That is
assuming, of course, that the implementations you are using have an
INCLUDE form which splices the code of one file into that of another.
So, if I were doing PLT and Chez, I might have my main file look like:

        (define blah ...)

And then have a PLT file:

        #lang scheme

        (module .... (include "main.ss"))

And then have a Chez file:

        (eval-when (compile) ;; Optimizations
          ...)

        (module ... (include "main.ss"))

And if I had a third implemenation that didn't have anything but R5RS:

        (load "dep1.ss")
        (load "dep2.ss")

        (load "main.ss")

Et voila!

--
Aaron W. Hsu <arcf...@xxxxxxxxxxx> | <http://www.sacrideo.us>
"Government is the great fiction, through which everybody endeavors to
live at the expense of everybody else." -- Frederic Bastiat
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) ++++++++++++++




Cool, thanks a lot for the very informative response. The reality is
as I suspected -- too complex to breeze through it like python! I
totally understand the bit about learning one particular
implementation before getting to try to make portable code. I guess
with my experience that python can "feel" a bit sluggish, I was very
eager to get some programs translated to scheme, then compiled down to
the metal/si. Your response melded nicely with the impressions I've
been gathering about the distribution of language functionalities and
libraries. I have one question in particular, though.

You said the extensions are to change the language semantics, such as
with immutable pairs. I thought the *whole point* of lisp-and-lisp-
derived-languages was that you can use macros to change the language
semantics to suit your needs. This was a major source of my confusion
about why anyone would want to do a language extension vs. procedure/
macro libraries. I can only assume that "extension" in this case
means hard-coding or optimizing in C (or whatever the interpreter is
"really" written in) the stuff that might otherwise have to be
interpreted each time through macros... however that leaves me with a
weird feeling about what happens when you compile it down... wouldn't
all that extension macro overhead disappear, so after compiling, if
you want immutable pairs, you are "really" getting immutable pairs. ?

Fun stuff!

thanks
Michael


.

Relevant Pages

  • [LONG] Re: Why code completion and early error checking are needed
    ... > the programmer who wants such features. ... the guiding principles in the evolution of the c++ language should be ... the problem with this is that ide must first be able to assume ... libraries to find the type declaration. ...
    (comp.lang.cpp)
  • Re: So confused with scheme options
    ... Well known Libraries ... Implementation Extensions ... language, what's an expected library function for most implementations, ... This is the "module" language of PLT, ...
    (comp.lang.scheme)
  • Re: Verbose functional languages?
    ... believe it will be difficult to surpass the practical success of OCaml ... are writing good libraries for it). ... because the language was pushed with marketing money. ... Existing FPL implementations like OCaml and Haskell bask in the glory ...
    (comp.lang.functional)
  • Re: Why why why? (Was: Re: Vertical alignment of text within a DIV)
    ... but a full rendering implementation for every possible display ... Remember that back when these standards were written ... there was very little in terms of cross-platform display libraries. ... It's the 'any language' bit, ...
    (comp.infosystems.www.authoring.stylesheets)
  • Re: PLT Scheme Language Levels
    ... I have conceptional problems understanding 'language leves' in PLT Scheme. ... "PLT" languages automatically load libraries enabling OO and GUI ...
    (comp.lang.scheme)
Loading