Re: Scheme for programmers book

Anton van Straaten wrote:
> Michael Erdmann wrote:
> 
>
>
> I'm not sure what you mean here - isn't FramerD implemented in C, with a
> Scheme derivative as a scripting language?  Also, I would think many of yo
ur
> questions could be answered by looking at the FramerD source code.
>
> Certainly, neither Ada nor C# would not make sense as a "scripting languag
e"
> for something like FramerD.
A little bit polemic the question is, why should i use the scheme
derivat to FramerD to implement an application on top of the FramerD
database which works quite well. Since FramerD provide an C interface
i could bind this interface to more or less any language.

If i would decide to stick with scheme, will be the FramerD scheme
dialect sufficient for continous development. May be a port
to Chicken whould make sense?

These are the questions i am trying to answer.

> 
>
>
> There tends to be more variation in Scheme than e.g. in Java.  But
> indentation and bracketing is easy enough.  Aside from reading other
> people's code, your best bet is to experiment with an environment like ema
cs
> (perhaps with Quack) or DrScheme, which will do much of the formatting for
> you.  Ask questions here if you have any.
>
> Commenting varies even between implementations, since the standard only
> specifies single-line comments, whereas most implementations provide a
> multi-line comment mechanism like: #| ... |#.  Some documentation tools
> expect a certain comment format. 
>
>
> There are a multitude of these for Scheme.  A couple picked more or less a
t
> random include SchemeDoc and Schmooz.  (All these names are googleable.)
> Some Scheme implementations have a preferred approach or tool for this.
>
> 
>
>
> It would be a mistake to consider Scheme a "really unsafe" language based 
on
> your initial impressions of it, without getting into the details of one of
> the major implementations.  For example, some of the Scheme module systems
 -
> like PLT and, I believe, Scheme 48's - statically detected undefined
> identifiers.

Don't worry, only the error statistic and the maintainence efforts
of the my first bigger project will make up my impression.

> They also provide exception mechanisms.  There's also a srfi
> for exceptions (SRFI-34).

It seems this document is withdrawn. I am realy wondering how
you live in larger SW Systems with errors.

>
> Regarding static type checking, there are ways to achieve that in Scheme,
> too, arguably more powerful than the way in which tradition statically-typ
ed
> languages work.  The "soft typing" tools like SoftScheme, MrSpidey, and
> MrFlow will infer the types in your Scheme programs and warn you when the
> program has type errors.  However, they won't prevent you from running the
> program if you want to.  It should be noted that these tools aren't used i
n
> most Scheme programs (afaict), and they are essentially all research
> systems, with various limitations.  However, they do work and can be usefu
l,
> depending on what you're trying to do.
It seems SoftScheme has disapeared from the net. MrSpidey and MrFlow
seems to be tools which are integrated with DrScheme. I guess SoftScheme
whould have been  the right standalone tool.

>
> There are other sophisticated things that can be done in Scheme related to
> type checking, for example, if you include type assertions in your program
,
> i.e. statements that are intended to check types at runtime, you may be ab
le
> to run a partial evaluator on your program, in which case many of the type
> checks can be checked before runtime.  In the end, this is equivalent to
> static type checking, but again, with greater flexibility since you get to
> choose (to a greater degree) what will and won't prevent your program from
> running.  Once again, this kind of thing is more in the research domain th
an
> an everyday tool, but it is possible to do if you need it, and depending o
n
> the kind of system you're developing.
>
> All in all, Scheme is far richer in possibilities than is apparent from a
> brief look from the outside.

Thanks, i understood the message :-) I will have a deeper look into it,
since i am not under any time pressure in the moment.

Michael


>
> Anton
>
>