| Michael Erdmann 2004-09-26, 8:57 pm |
| 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 your
> questions could be answered by looking at the FramerD source code.
>
> Certainly, neither Ada nor C# would not make sense as a "scripting language"
> 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 emacs
> (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 at
> 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-typed
> 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 in
> most Scheme programs (afaict), and they are essentially all research
> systems, with various limitations. However, they do work and can be useful,
> 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 able
> 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 than
> an everyday tool, but it is possible to do if you need it, and depending on
> 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
>
>
|