Re: Practicalities of Ada for app development

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 13.06.12 02:04, Adam Beneschan wrote:

> Maybe this should be a challenge to the Ada community to come up with some common package specification (or set of packages) that would be sufficient to meet those needs, so that users wouldn't feel a need to switch to Perl to get the same kind of expressive power.  Offhand, I don't think it would need to become part of the official language standard (the letters I, S, and O are not a magical incantation that automatically makes software more trustworthy).  We've had working groups in the past that have developed standard packages that weren't part of the language (although some of them became part of later versions of the language, like Ada.Numerics).  What does anyone else think?  Does this seem worthwhile?  I have to admit, I've sometimes been frustrated when I need to work with text, although not enough to get me to use Perl for more than smallish programs, so off the top of my head this seems like it might be useful.

I like the "sufficient for most needs" part very much. It allows
going back to just regular languages.


This is my wishlist for a framework supporting regular languages
built around language features familiar to Ada programmers:

1. The building blocks in Ada.Strings.Maps, Ada.Strings.Maps.Constants
etc seem to correspond to character classes in POSIX REs:

   Hexadecimal_Digit_Set ~[0-9A-Fa-f]

Yet, the set operations of Maps exceed what I get in RE packages
of languages that start from version 7 regexp. Good!

So, alternation is presently possible for single characters.
Need groups and sequencing, expressed in the type system.

2. The container mechanics (Ada STL) offer one possible approach
to handling the set of matches:
The matching process results in an object of type that supports
iteration.  Perhaps not just Cursors, but also Extended_Index
like in Vectors, because programmers will expect that
groups in patterns are indexed by number.

3. The pattern matching facilities need not go beyond
regular languages. Provide some frequently used constant
patterns, such as end-of-line, start-of-string, word-boundary.

4. Add a single, read-only feature for RE inspection. It allows
observing the scanning process:

For example, given (ABC|BCD)E, and a function "&" returning
a pattern type,

   Alternation'(To_Set ("ABC") & To_Set ("BCD"))
      & To_Pattern ("E");

Here, it might be helpful to see the backtracking (if any) triggered
when the scanner is about to hit "E". Therefore, allow programmers
to implement an abstract pattern type that matches the empty
string. The scanner will call its primitive subprogram,
thus

   Alternation'(To_Set ("ABC") & To_Set ("BCD"))
     & user_defined_empty_1
     & To_Pattern ("E");

5. Define a small set of well chosen operators that reduce
verbosity.  (GNAT's Spitbol.Patterns has quite a lot of them.)

6. Producing new text from input text should not physically rely
on Ada.Strings.Unbounded. Instead, allocate new strings that can
clean up after themselves.


In conclusion, programmers would rely on Ada's type system when expressing
a pattern. They would not be forced to write in yet another macro
language in strings, as is required by most scripting languages.
Access to matched portions of input uses a familiar framework.