1 Implementing Dr Scheme Tools
2 Adding Languages to Dr Scheme
3 Creating New Kinds of Dr Scheme Frames
4 Extending the Existing Dr Scheme Classes
5 Expanding the User’s Program Text and Breaking
6 Editor Modes
7 Language-specific capabilities
8 drscheme: get/ extend
9 drscheme: unit
10 drscheme: language
11 drscheme: language-configuration
12 drscheme: debug
13 drscheme: rep
14 drscheme: frame
15 drscheme: help-desk
16 drscheme: eval
17 drscheme: modes
Index
On this page:
2.1 Adding Module-based Languages to Dr Scheme
2.2 Adding Arbitrary Languages to Dr Scheme
2.3 Language Extensions
Version: 4.0.2

 

2 Adding Languages to DrScheme

2.1 Adding Module-based Languages to DrScheme

If a language can be implemented as a module (see module for details) and the standard language settings are sufficient, simply create an info.ss file in the collection where the module is saved. Include these definitions:

The lists must have the same length.

As an example, the Essentials of Programming Languages language specification’s info.ss looks like this:

  #lang setup/infotab

  (require string-constants)

  (define name "EoPL Support")

  (define drscheme-language-modules

    (list "eopl-lang.ss"))

  (define drscheme-language-positions

    (list (list (string-constant teaching-languages)

                "Essentials of Programming Languages")))

This info.ss file indicates that there is a single language in this collection. The module that implements the language is the eopl-lang.ss file in the same directory as the info.ss file. Additionally, the language dialog will contain Essentials of Programming Languages as a potential language. The use of the string constant teaching-languages ensures that EoPL’s language is placed properly in foreign language versions of DrScheme.

For collections that define multiple (related) languages, if the language-positions contain multiple strings, the languages whose leading strings match are grouped together. That is, if two languages have strings:

  '("My Text" "First Language")

and

  '("My Text" "Second Language")

the two languages will be grouped together in the language dialog.

2.2 Adding Arbitrary Languages to DrScheme

With some additional work, any language that can be compiled to PLT Scheme is supported by the tools interface, not just those that use standard configurations and module.

Each language is a class that implement the drscheme:language:language<%> interface. DrScheme also provides two simpler interfaces: drscheme:language:module-based-language<%> and drscheme:language:simple-module-based-language<%>, and mixins drscheme:language:simple-module-based-language->module-based-language-mixin and drscheme:language:module-based-language->language-mixin that build implementations of language^s from these simpler interfaces.

Once you have an implementation of the drscheme:language:language^ interface, call drscheme:language-configuration:add-language to add the language to DrScheme.

Each language comes with its own type, called settings. This can be any type the language designer chooses, but to aid documentation, we call it settings here. The settings type is expected to contain parameters of the language, such as case sensitivity, etc. The implementor of the language provides a GUI so the user can configure the settings and all of the language’s operations accept a setting. DrScheme maintains the current settings for each language.

2.3 Language Extensions

Some tools may require additional functionality from the drscheme:language:language interface. The drscheme:language:extend-language-interface function and the drscheme:language:get-default-mixin mixin make this possible.

For example, the MrFlow tool expands a program, analyzes it and then displays sets of values for each program point. These sets of values should be rendered in the syntax of the language that MrFlow analyzes. Since MrFlow doesn’t know which languages are available, it can call drscheme:language:extend-language-interface to extend the drscheme:language:language<%> interface with a method for rendering sets of values and provide a default implementation of that method. Tools that know about MrFlow can then override the value rendering method to provide a language-specific implementation of value rendering. Additionally, since the drscheme:language:get-default-mixin adds the default implementation for the value-set rendering method, all languages at least have some form of value-set rendering.

In some cases, it is important for one tool to avoid depending on another in the manner above. For example, if a tool that provides a new language provides an implementation for the MrFlow-specific method, that tool may fail to load if MrFlow is not present (Indeed, with the tool manager, this can happen to any tool that depends on another in this manner.)

To avoid this problem, consider writing your tool to first check to see if the base method is available before extending it. For example, if the MrFlow tool provides the render-value<%> interface, then a tool that overrides that method can first test to see if the superclass implements that method before overriding it:

  (define (my-language-mixin %)

    (if (implementation? % mrflow:render-value<%>)

        (class %

          (define/override ...)

          (super-new))

        %))

To help test your tool, use the PLTONLYTOOL environment variable to load it in isolation.