Spoofax.discoverLanguages(FileObject location) discovers language components at a given location. The method name might be renamed to discoverLanguageComponents(FileObject location) to reflect this more accurately.

I suggest to also have Spoofax.discoverLanguageImplementations(FileObject location) which hides the additional step of composing implementations from components, and Spoofax.discoverLanguageImplementation(FileObject location) which discovers a single implementation or throws an exception, when there are more.

I am not sure if the current trick using LanguageUtil.active() is problematic, when there are implementations for different languages in the set. Does the method actually check for the language or only for the version?

One could even hide the resource service and archive path construction spoofax.resourceService.resolve("zip:" + nablUrl + "!/") in variants which take a string argument.

Submitted by Guido Wachsmuth on 14 February 2017 at 13:58

On 14 February 2017 at 13:59 Gabriël Konat tagged api

On 16 February 2017 at 12:45 Guido Wachsmuth commented:

This might actually not be needed, if you rely more on services to pick the language implementation. I am now using the following setup code, which does not pick or store any implementation:

try (final Spoofax spoofax = new Spoofax()) {
  FileObject archive = spoofax.resourceService.resolve("zip:" + args[1] + "!/");
  spoofax.discoverLanguages(archive);
  ...
} catch (IOException | RuntimeException | MetaborgException e) {
  e.printStackTrace();
}

When invoking the builder, the implementation is picked by Spoofax:

BuildInput input = new BuildInputBuilder(project)
  .addSource(file)
  .addTransformGoal(new EndNamedGoal("Show parsed AST"))
  .withMessagePrinter(printer)
  .build(spoofax.dependencyService, spoofax.languagePathService);

IBuildOutput<?, ?, ?, ISpoofaxTransformUnit<?>> output = spoofax.builder.build(input, new NullProgressReporter(), new CancellationToken());

This easier use pattern still needs to be added to the API usage example repository.


On 16 February 2017 at 13:26 Gabriël Konat commented:

Indeed, but I agree that loading languages should have a simpler API. Especially the "zip:" "!/" stuff is confusing. I will add methods that deal with loading from an archive, separate from the methods that deal with loading all languages in a directory.


On 17 February 2017 at 13:31 Gabriël Konat commented:

I refactored the language discovery service to provide methods for loading a language from a directory with a compiled language (root directory of a language with src-gen and target directory), and from an archive (.spoofax-language files). I also added a method that scans a directory and its descendants for all languages that it can find and loads them. Methods have a variant for loading a single language implementation, and variants for returning either ILanguageComponent and ILanguageImpl.

Old methods are supported but deprecated.


On 17 February 2017 at 13:31 Gabriël Konat closed this issue.

Log in to post comments