Code Comments
Programming Forum and web based access to our favorite programming groups.Anton van Straaten wrote: > Michael Erdmann wrote: > > > > I think that'll depend a lot on who the developers are. On some of the > Scheme projects I've seen or been involved in, those kind of choices get > made by the team members. May be the problem is that i am still following a wrong paradigm, which means you look at your requirements, you break them down in managable parts, define interfaces between them, Manageable part mean that the same developer can work on theses components incrementally or several developers can colaborte where each developer has been assigned to each part. In the past i found that some what stable interfaces between these parts are an essential issue. Stable means not frozen since you can never avoid that interfaces are changing. Stable means, if something i changed everybody in the team has a chance the realize the change because the compiler is complaining. I am realy afraid that a not trivial project is simply falling aprt during the time, and every thing has to be tested. I am realy wondering what choices i have. In the Moment i got the following issues. 1. selection of the correct scheme environment. bigloo, chicken, SIOD, DrScheme ... 2. Tools for impact analysis, when i am for example changing the input argument of a function from a single value to a vector (structure). Since the compiler/interpreter is not warning me about any in- compatablitiy, i guess i have to rely on fgrep, an editor and awk? Maybe SoftScheme or what else? 3. Documentation. This is in all languages a problem. But what it the most commonly used tool in the scheme community. I don't like to reinvent this tooling. Well i am trying to get schmozz with chicken running and i am failing misserably. 4. Build environment Are you using the GNU config tools. For example the makefile of SLIB does not use config. What is the common habit here? 5. Deployment What is the typical way of deploying. Are there some expriences and methods available (rpm, tar achrive what so ever). Specially the issue that you need to deploy the interpreter or runtime system as well! 6. Coding guideline, which means in any language i can do everthing (e.g. c-code like (++p* = *( get_address(*q++) )..) but there resonable limitation specific for certain languages. 7. Typical design blueprints like client/server, data base application etc. Any thing i should never do, since one million developers already have failed in trying it. 8. What is about embedding into operating systems and grafical environments (GtK etc..)? 9. Portability. But i think this only a minor issue, if Issue 8 is solved on different platforms. > If you're talking about a single maintainer > initially and hoping that you can get someone else to take over in future, I > don't think the exact details of your Scheme choices will be the real issue.[/colo r] I am not so sure. If some body takes over and i have reinvented everthing from the scratch it will be ver difficult for him to get even the build environment running on his box. I had this experience in the past very often. > Whether the project itself achieves something worthwhile is more important . > After all, people work with the Scheme implementation SIOD as part of the > GIMP, for example, and SIOD is far from being one of the best or richest > Scheme implementations. More on this below. May be this an answer for Question 1. I will check out. > > > > > Google shows a copy of SoftScheme here: > http://www.bloodandcoffee.net/campb...soft_scm.tar.gz Thanks, i have done the same, but obiously missed it, sorry! > > As for projects implemented in Scheme, the Roadsend PHP compiler was > mentioned, implemented with Bigloo Scheme, but I don't think that's an ope n > source project: http://www.roadsend.com/ > > Randomly searching Google, here's an example of Scheme being used as an > interpreter for Open Inventor: http://xenia.media.mit.edu/~kbrussel/Ivy/ . > This project seems to have a similar overall technical structure to what > you're trying to do. Thanks, the Header2Scheme tool might be interesting. I will have a look in this. > > There are some Scheme libraries for PLT Scheme maintained by the Schematic s > project at http://schematics.sourceforge.net/ . > > As I think someone else mentioned, you might also look at some of the Sche me > implementations themselves, since they tend to be large projects involving a > lot of Scheme code. Yes, this was the reason why i wanted to get schmozz working with scheme. To me scheme look far to complex for me, but let see how i am doing. > > > Different Scheme implementations have different tools that are commonly us ed > with that implementation. This applies to documentation tools, module > systems, even static type checking. If you pick a Scheme implementation > with an active community, you might check which documentation tools are us ed > most commonly in that community. For example, I imagine you're more likel y > to find Schmooz being used with SCM, and PLT has its own system for > generating documentation for its Help Desk (and the web). I see that > Chicken has a package for the documentation tool "mole". May be this is what is drving me crazy. There are so many scheme implementation. In my simple GNU world everbody is using gcc, gnat and some GNU tools. In the scheme communitiy there seems to me an artifical amount to implementations and tools. Only a view of them are regulary maintained. Thank you very mutch. I guess what i will do by end of this w. I will try to build a small protoype of refactoring tools i am intending to build using chicken assuming that i can incorperate the dtcall interface into a chicken extsion. During this i will try to test most of the techniques i find important for coding and deployment. During the w
end i will initiate a new thread putting my results on the 9 topics aboe for discussion. Next w
i will then decide wheterh i am going to proceed with scheme or if i am connecting framerd to C# (mean mono). Michael > > Anton > >
Post Follow-up to this messagePowered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.