How to customize the reader and printer in a language implementation

How to customize the reader and printer in a language implementation

[mikel evins]

Per,

What's the right way to arrange for Kawa to use an output format that's not in the formats array in Shell.java? I want to use my own printer with the Bard implementation.

While I'm asking, I may as well also ask about the right way to customize the reader to handle alternative syntax for certain value expressions. For example, I want to read expressions like "{...}" as finite maps, and "[...]" as persistent sequences. I'd also like to arrange for a different surface syntax for character objects.

Thanks,

--me

Re: How to customize the reader and printer in a language implementation

[Per Bothner]

On 02/18/2015 07:51 PM, mikel evins wrote:
> What's the right way to arrange for Kawa to use an output format
> that's not in the formats array in Shell.java? I want to use my own
> printer with the Bard implementation.

I assume you've written an implementation of either AbstractFormat
or Consumer  So you want to give it a name, so it can be selected by the
--output-format switch. How would you do that?

Right now there isn't anyway, except to modify the formats array in Shell.java.
One way to fix that is to add a registerFormat method, which would act similar
to registerLanguage in gnu/expr/Language.java.  The problem is you'd have to
write your own main program to call registerFormat before clling repl.main.
For example see gnu.jemacs.lang.ELisp#main.  This means you can't do something like:

    $ java kawa.repl -output-format my-new-format

A better way to be able to extend new formats while still using kawa.repl
is to use Java's "service provide" mechanism.  See java.util.ServiceLoader.
We could define an interface kawa.OutputFormatProvider:
   public interface OutputFormatProvider {
       public Object[][] getProvidedFormats();
   }
or maybe better:
   public interface OutputFormatProvider {
     /** Return null if this OutputFormatProvider does not provide a format
       * with the given name. */
     Consumer getOutputConsumer(String name, OutPort out);
   }

Then you add a new format you'd add a file META-INF/services/kawa.OutputFormatProvider
to your .jar, which contains the name of one or more OutputFormatProvider sub-classes.

Patches welcome ...

> While I'm asking, I may as well also ask about the right way to
> customize the reader to handle alternative syntax for certain value
> expressions. For example, I want to read expressions like "{...}" as
> finite maps, and "[...]" as persistent sequences.

In that case I suggest creating a new Language class.  If it's very similar
to Scheme except for a few modest changes make it extend kawa.standard.Scheme.
Then you can override the createReadTable method.

> I'd also like to
> arrange for a different surface syntax for character objects.

Character values are evil.  You shouldn't make it easier to work with characters
directly - they're too low-level and little or no useful semantic meaning.
Instead people should work with strings.  IMNSHO.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: How to customize the reader and printer in a language implementation

[mikel evins]

> On Feb 19, 2015, at 1:41 AM, Per Bothner <per@bothner.com> wrote:
> 
> 
> 
> On 02/18/2015 07:51 PM, mikel evins wrote:
>> What's the right way to arrange for Kawa to use an output format
>> that's not in the formats array in Shell.java? I want to use my own
>> printer with the Bard implementation.
> 
> I assume you've written an implementation of either AbstractFormat
> or Consumer  So you want to give it a name, so it can be selected by the
> --output-format switch. How would you do that?
> 
> Right now there isn't anyway, except to modify the formats array in Shell.java.
> One way to fix that is to add a registerFormat method, which would act similar
> to registerLanguage in gnu/expr/Language.java.  The problem is you'd have to
> write your own main program to call registerFormat before clling repl.main.
> For example see gnu.jemacs.lang.ELisp#main.  This means you can't do something like:
> 
>   $ java kawa.repl -output-format my-new-format
> 
> A better way to be able to extend new formats while still using kawa.repl
> is to use Java's "service provide" mechanism.  See java.util.ServiceLoader.
> We could define an interface kawa.OutputFormatProvider:
>  public interface OutputFormatProvider {
>      public Object[][] getProvidedFormats();
>  }
> or maybe better:
>  public interface OutputFormatProvider {
>    /** Return null if this OutputFormatProvider does not provide a format
>      * with the given name. */
>    Consumer getOutputConsumer(String name, OutPort out);
>  }
> 
> Then you add a new format you'd add a file META-INF/services/kawa.OutputFormatProvider
> to your .jar, which contains the name of one or more OutputFormatProvider sub-classes.
> 
> Patches welcome ...

I'll look at it; thanks for the pointers.

In the worst case, I know I can simply modify the Kawa sources to get the effect I want (I've done it that way before), but that is the worst case, and I'd rather strive for the best.

>> While I'm asking, I may as well also ask about the right way to
>> customize the reader to handle alternative syntax for certain value
>> expressions. For example, I want to read expressions like "{...}" as
>> finite maps, and "[...]" as persistent sequences.
> 
> In that case I suggest creating a new Language class.  If it's very similar
> to Scheme except for a few modest changes make it extend kawa.standard.Scheme.

I've done this already.

> Then you can override the createReadTable method.

Thanks; that's the missing piece.

>> I'd also like to
>> arrange for a different surface syntax for character objects.
> 
> Character values are evil.  You shouldn't make it easier to work with characters
> directly - they're too low-level and little or no useful semantic meaning.
> Instead people should work with strings.  IMNSHO.

Fair enough. Thanks for the help.