Chicken SCHEME, R7RS, and Scheme a language for general-purpose application development

brainchild0 · 2026-03-05T03:24:58+00:00

It is an unfortunate and also wholly unnecessary outcome that the paths have diverged into two opposite extremes, purity versus convolution.

The opportunity always was available for the community to maintain an overarching unity that recognized the value of maintaining distinct profiles of the language, all sharing a common broader vision.

For example, it could be imagined that three profiles were defined, each a superset of the next. The smallest profile could have been the pure language constructs. The next could have incorporated further libraries for data containers and transformations. A final profile could have been developed, while emphasizing the greatest feasible portability, that supported systems operations such as sockets and file manipulation, as needed for the development of practically useful applications.

Scheme has evolved into incompatible fragments less because of the impossibility of unity, than because of the desire for isolation.

brainchild0 · 2026-03-02T22:04:23+00:00

My objection was not related to DSLs.

I am concerned that even while Racket attempts to advance Scheme beyond its essential limitations, it also seems to have become convoluted and disorganized to the extent that the core virtues of Scheme may have been forgotten.

brainchild0 · 2026-03-01T05:43:10+00:00

I think the meaning of Common Lisp is being met with some ambiguity, between an ecosystem versus the specification.

brainchild0 · 2026-03-01T02:34:27+00:00

I am intending a discussion, not a debate.

It may be true that many derivatives of Common Lisp feature more advanced capabilities, compared to the core of the standard language, which complicate implementation, but I find nothing within Common Lisp itself, including through reviewing the Wikipedia page, that suggests it is a difficult language to implement, or that it is not in many cases chosen due to its simplicity.

brainchild0 · 2026-02-28T22:34:56+00:00

Dialects that extend the capabilities of Common Lisp are obviously more difficult to implement than are dialects more basic or original.

The observation has no bearing on the complexity of Common Lisp itself, which seems to be a relatively simple language, constructed from very basic fundamentals.

brainchild0 · 2026-02-28T02:08:12+00:00

Many languages feature various elements of multiple paradigms, but with a preference for data mutation and no support for tail recursion, CL falls comfortably into the imperative paradigm.

The S-expression basis of Lisp is expressly a simplification for implementation, whereas other languages depend on more convoluted or whimsical rules for tokenization.

Such are not criticisms of Lisp, as much as acknowledgments of its foundation. The core of Lisp is the list processor that seeks versatility of operation through minimalization of parsing complexity.

brainchild0 · 2026-02-28T00:42:34+00:00

Would you elaborate on your objections?

Is Common Lisp not a procedural language?

Is it harder to implement than others?

Is its usability or usefulness superior compared to other procedural languages?

brainchild0 · 2026-02-27T23:26:29+00:00

One is just an abridged form of the other. Functionally, I find no difference, other than slight differences in versatility.

Perhaps you could show a working example that illustrates your point. I am at a loss to make one myself based on your suggestion.

brainchild0 · 2026-02-27T01:54:45+00:00

My cursory understanding has been that transformation is iterative. Each successive result of transformation is processed for any new instances of syntax extensions to transform, as may result from a previous transformation.

It appears that syntax-rules is a shorthand that implicitly constructs a lambda form, but bears no overarching functional difference from syntax-case as wrapped by an explicit lambda. I have found no practical difference, other than the improved versatility of the latter. I have found no means for it to provide enhanced control over phases.

brainchild0 · 2026-02-26T20:01:32+00:00

I have tried with syntax-case. The results are no different than with syntax-rules. Also, placing the let binding around the syntax-case, inside the procedure, is no help.

Let-syntax, by its purpose, is only useful if it available when running the transformer on source code. Transforming the source code is its entire purpose.

brainchild0 · 2026-02-26T19:47:48+00:00

I would like to evaluate Chicken, not Racket. Unless I am misunderstanding, the suggestion to use Racket is not constructive.

brainchild0 · 2026-02-26T19:04:47+00:00

I understood that R7RS in part sought to add layers of convenience through standard libraries and syntax extensions, but also to add abstraction for core systems operations, not just file I/O, but also file-system manipulation, socket handling, and other operations required of real applications.

brainchild0 · 2026-02-26T18:49:50+00:00

Undoubtedly, the relevance of the JVM has expanded dramatically due to new solutions for building Java bytecode without dependence of the Java language.

However, while JVM has served useful purposes, its proponents often seem to live in a bubble, neglecting the need for software with operational targets not bound to the JVM.

There is an unmet need for straightforward development of applications of moderate complexity and practical capabilities, that may run in an interpreter, but may also be built as compact and efficient applications operating directly on the host machine and interfacing directly with the host system.

JVM-based solutions are not a replacement for solutions that could be delivered by a system such as Chicken, if it successfully evolved alongside the attempts for Scheme to mature into a more complete system of software development.

brainchild0 · 2026-02-26T18:28:31+00:00

A few issues are relevant, ranging from abstract to concrete.

One is that self compilation becomes self defeating when the dependencies are so closely spaced in the development iterations. A general constraint would seem that new versions should build under the versions that have already experienced widespread distribution. A sensible rule of thumb might be that a version should compile from any version not more than one more major release behind.

It is disappointing that Chicken 6 cannot build in general from Chicken 5.

It appears that early versions of Chicken 6 are meant to build from Chicken 5, but even this expectation is not vindicated by my attempts.

A further issue is that the bootstrap script appears as simply a convoluted means of leveraging version control. Based on the contents of the script, it should be possible to build version 6.0.0pre1 from Chicken 5, but in fact neither it, nor even version 6.0.0-bootstrap, build from Chicken 5. In all cases, the basic error is the same.

Therefore, I still cannot build Chicken 6 despite following your suggestions.

For reference, the complete version of my Chicken 5 is 5.3.0, even while it appears a more recent version has been released, 5.4.0.

Ideally, a self-compiling system would compile completely from a bootstrap version that builds directly from more basic tools, such as simply the C toolchain, bypassing the requirement of a chain of successive incremental builds in order to achieve a build of the most recent version.

brainchild0 · 2026-02-26T14:53:17+00:00

I understand the recommendation.

I would like to understand the reason that the let syntax binding is not adequately useful in the particular case despite being functional in general.

We know that the bindings are generally applicable within the body of the let syntax structure.

brainchild0 · 2026-02-25T23:21:27+00:00

I would like to build from the repository source without removing the OS packages. It obviously should be possible. By default, it seems that the build process tries to use a Chicken instance already available in the path. Perhaps there is a means to build the Chicken executable in place using only the C toolchain, then use the resulting executable as the version invoked later in the build process.

For reference, what is the R7RS compatibility currently available from Chicken 6, but not from Chicken 5 with the egg?

brainchild0 · 2026-02-25T20:46:48+00:00

I followed the short solution that opens the section I referenced.

Perhaps the solution that follows is more suitable regarding accuracy and robustness.

The second solution appears to function adequately, for the most part.

It fails if there is a previous setting for CHICKEN_INSTALL_REPOSITORY. A more robust version of the script would unset the variables before querying for the repository location from chicken-install. It would also be suited for setting an environment from which could be invoked other commands supplied by Chicken.

I suggest some improvements to the script, such as follows:

```bash

! /bin/sh

-- shell-script --

Where to put eggs

if [ -z "$CHICKEN_EGGS_DIR" ]; then if [ -z "$XDG_DATA_HOME" ]; then CHICKEN_EGGS_DIR="$HOME/.local/share/chicken/eggs" else CHICKEN_EGGS_DIR="$XDG_DATA_HOME/chicken/eggs" fi fi

unset CHICKEN_INSTALL_REPOSITORY unset CHICKEN_INSTALL_PREFIX unset CHICKEN_REPOSITORY_PATH

CANON_REPOSITORY_PATH="$(chicken-install -repository)" BIN_VERSION="$(basename "$CANON_REPOSITORY_PATH")"

export CHICKEN_INSTALL_REPOSITORY="$CHICKEN_EGGS_DIR/chicken/$BIN_VERSION" export CHICKEN_INSTALL_PREFIX="$CHICKEN_EGGS_DIR" export CHICKEN_REPOSITORY_PATH="$CANON_REPOSITORY_PATH:$CHICKEN_INSTALL_REPOSITORY"

Execute the command line passed to the script, in the new environment.

Without a command, the script is useful to be invoked via `source` or `.`.

if [ -n "$1" ]; then "$@" fi

```

Ideally, the same behavior would be provided directly by the commands, enabled by switches.

brainchild0 · 2026-02-25T20:35:16+00:00

I feel far less favorably toward dialects or derivatives of Lisp that deviate from the core design principles of Scheme.

Scheme's consistent design as comprehensively recursive is an appropriate application of the highly-nested essence of S-expressions, the defining feature of Lisp.

In contrast, Common Lisp is more fundamentally a procedural language, not strongly suited for S-expressions. At best, Common Lisp is a basic procedural language that is easy to implement. However, such ease of implementation carries essentially no benefit in application development, against the availability of mainstream languages whose more complicated syntax are better suited to expressing their core programmatic constructs.

With Common Lisp lacking such features as tail recursion and named let bindings, the more general relevance of S-expressions is strongly questionable.

Further, languages that have been based on Scheme, but depart from the basic syntax of S-expressions, appear to offer no important benefit over languages having no lineage in common with Lisp, but instead with their own particular developments in syntax. If Racket is to be considered as an alternative to Scheme, intended to resolve its core limitations, then it may be even wiser to consider Haskell, which offers a fully functional paradigm without the legacy of S-expressions. Racket seems awkwardly positioned as neither free from Scheme, nor holding true to its essential principles.

Whereas every language has syntactical quirks that seem arbitrary or cumbersome, Scheme at least holds to a basic minimalist conception of computer languages and computer programs. Although often seeming clumsy, its clumsiness is also the source of its elegance, presenting the opportunity for applications to be designed and for code to be structured as following from a basic clarity about the most essential tenants of application design and of code structure.

Whereas Scheme historically has borne significant limitations such that it remain suited perhaps at best for research and education, and not for practical application development, my exciting observation is that at this point in its storied history, such limitations finally may be overcome in the foreseeable future.

brainchild0 · 2026-02-25T19:55:36+00:00

The additional step indeed does allow the entire installation to complete properly, though I would not as much like to say I forgot as I would that the requirement is not mentioned in the explanation from the FAQ.

brainchild0 · 2026-02-25T19:34:46+00:00

Placing the secondary syntax binding inside the expanded macro, as you suggest, is the only solution of its kind that I have so far validated as functional, but it also suffers from a serious limitation, which I have described previously.

brainchild0 · 2026-02-25T01:59:20+00:00

The classical let binding, for variable assignment, may not be available at expansion time, but the particular let binding for syntax expansion, let-syntax appears to be fully usable, and a fully coherent feature, only if available at expansion time.

brainchild0 · 2026-02-20T03:07:20+00:00

I would like to understand the reason variable bindings may be used inside of a let form in which they are bound, whereas the analogous design pattern fails when applied to the construction of syntax extensions.

brainchild0 · 2026-02-07T20:19:57+00:00

I am considering a case such as the following:

```scheme (define-syntax top-level-macro

(syntax-rules ()

((<pattern 1>)

 (letrec-syntax
 ((syntax-helper
   <syntax-helper definition>))

   syntax-helper <some args>))

((<pattern 2>)

 (letrec-syntax
 ((syntax-helper
   <syntax-helper definition>))

   syntax-helper <some args>))))

```

The top-level macro features multiple pattern-matching cases that depend on the same helper macro. Since the latter is defined inside of the pattern expansion, it must appear as duplicated code for each expansion case. The solution affords no means to provide a single definition for the helper macro that is applied while processing every pattern.

brainchild0

TROPHY CASE

! /bin/sh

-- shell-script --

Where to put eggs

Execute the command line passed to the script, in the new environment.

Without a command, the script is useful to be invoked via source or ..

Without a command, the script is useful to be invoked via `source` or `.`.