Practicalities of Ada for app development

Practicalities of Ada for app development

[wrp]

What would you say about using Ada for developing desktop
applications? I like what I have read in descriptions of the language,
but I have concerns about the practicality of using it.

I develop small to medium sized tools. Tasks are mostly limited to
text processing, database management, and simple visualization. I have
no need for high precision calculation or support for distributed,
concurrent, or real-time control. You can picture for example the size
and scope of the traditional Unix utilities. Sometimes I build
something larger with a GUI.

For considerations of size and performance, I'm planning to shift from
scripting to a compiled language. I develop on Linux but also target
Windows and OS X. After trying to consider everything available, I
feel that the only serious cadidates for me are C and Ada.

1. To begin with, I've heard it said that Ada, designed for embedded
system building, is simply not suited to apps for a general computing
platform. That's rather vague and I haven't seen any detailed
justification of that claim. What would you say?

2. I don't need tools to be free, but they have to be affordable to a
small shop. If I'm targeting x86-64 (and possibly ARM) is GNAT the
only compiler option I have?

3. How about the quality and availablity of supporting tools like
debuggers and profilers?

4. How about production quality, open source libraries for things like
Unicode support, sockets, network communication, GUIs, etc? The stuff
at www.dmitry-kazakov.de looks good, but most of what I have seen
online is from the 1980s and pretty rough to begin with.

5. How well is incremental development supported? I'm thinking of
things like modular compiling and speed of the edit-compile-test
cycle.

6. Size and latency are sometimes an issue. I've heard that since GNAT
is oriented to building larger systems, the executables it produces
are comparatively bulky. What is the situation relative to C in that
regard?

7. What advanced tutorial material is there for using Ada in this way?
Say that I have Norman Cohen's _Ada as a Second Language_. What more
advanced material is available on subjects other than concurrency,
distributed processing, or real-time systems? On a related note, what
projects would you recommend looking at as examples of great code?

Thanks

Re: Practicalities of Ada for app development

[Jeffrey Carter]

On 06/08/2012 01:48 PM, wrp wrote:
>
> 1. To begin with, I've heard it said that Ada, designed for embedded
> system building, is simply not suited to apps for a general computing
> platform. That's rather vague and I haven't seen any detailed
> justification of that claim. What would you say?

I would say everything you've heard is wrong. Ada is a general-purpose language 
that has been used successfully in every application domain. Ada is the language 
of choice for S/W that must be correct. Since I want all my S/W to be correct, I 
always use Ada. Examples of small Ada applications I've written include one to 
choose the signature (like the one at the end of this message), one to choose 
the sound to be played next time I log in (next time it will say, "What is your 
favorite color?"), and one to display a quote in a dialog window (today's is, 
"If you think you got a nasty taunting this time, you ain't heard nothing 
yet!"). There seems to be a theme there.

A larger application is the Mine Detector game 
(http://pragmada.x10hosting.com/mindet.html).

At work we have a large, concurrent, distributed, soft-real-time, web-accessible 
call-center application, but large parts of it do DB access and things that 
would be common in the kind of applications you want to make.

> 2. I don't need tools to be free, but they have to be affordable to a
> small shop. If I'm targeting x86-64 (and possibly ARM) is GNAT the
> only compiler option I have?

RR Software's Janus/Ada (for Windows) is reasonably priced. You might also look 
at Atego.

Note that most compiler are for Ada 95. Only 3 of 7 compilers I'm aware of 
support the entire language in the current standard (published in 2007). GNAT is 
the only compiler I'm aware of that supports features from the next standard 
(hopefully published this year).

Ada 95 is a very good language, so that might not be a concern. (Even Ada 83 is 
a better language than most of the competition.)

> 3. How about the quality and availablity of supporting tools like
> debuggers and profilers?

One nice thing about Ada is not needing to use a debugger.

> 4. How about production quality, open source libraries for things like
> Unicode support, sockets, network communication, GUIs, etc? The stuff
> at www.dmitry-kazakov.de looks good, but most of what I have seen
> online is from the 1980s and pretty rough to begin with.

There are plenty of libraries available. You can find many through adaic.org.

> 5. How well is incremental development supported? I'm thinking of
> things like modular compiling and speed of the edit-compile-test
> cycle.

Unlike C, Ada has modules ("packages"). With them, stubs, and separate 
compilation, incremental development is supported well.

> 6. Size and latency are sometimes an issue. I've heard that since GNAT
> is oriented to building larger systems, the executables it produces
> are comparatively bulky. What is the situation relative to C in that
> regard?

As I've said, everything you've heard is wrong. Equivalent programs in Ada and C 
create executables of about the same size using gcc (the key word is 
"equivalent"). Robert Dewar of AdaCore claims to have a collection of equivalent 
Ada and C programs that produce identical object code using gcc.

> 7. What advanced tutorial material is there for using Ada in this way?
> Say that I have Norman Cohen's _Ada as a Second Language_. What more
> advanced material is available on subjects other than concurrency,
> distributed processing, or real-time systems? On a related note, what
> projects would you recommend looking at as examples of great code?

Cohen is a pretty good book; I'm not sure that you need anything else. Note that 
even small applications can sometimes benefit from concurrency. Since Ada 
tasking is high-level and safe, it would a mistake not to learn about it so you 
can use it when warranted. Barne's book is a good choice. You might want to look 
at "Ada Distilled" by Richard Riehle. Again, adaic.org has a list of texts and 
tutorials.

-- 
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Practicalities of Ada for app development

[Adam Beneschan]

On Friday, June 8, 2012 2:35:55 PM UTC-7, Jeffrey Carter wrote:

> > 3. How about the quality and availablity of supporting tools like
> > debuggers and profilers?
> 
> One nice thing about Ada is not needing to use a debugger.

I don't get this comment.  Ada is a lot nicer than some languages at preventing you from making certain kinds of mistakes, but no language is able to prevent logic errors and certain dumb typos.  And if you make this kind of error and the program doesn't work, just the fact of its being written in Ada doesn't help you much.  There may less need for a debugger because Ada will prevent certain types of errors and things like constraint checks will catch some others that would cause havoc in C.  But it can't catch everything, and even if it does find an index that's out of range it won't tell you why the index was out of range.  I mean, Ada is a much better language than certain others for writing correct code, but this seems like a gross overstatement.

Or maybe I'm just being parochial here because I designed and wrote the Ada debugger that comes with Irvine Compiler's product.  And yes, I do use it to help track down problems.  (Including errors in the debugger itself.)

                         -- Adam

Re: Practicalities of Ada for app development

[BrianG]

On 06/08/2012 05:35 PM, Jeffrey Carter wrote:
> On 06/08/2012 01:48 PM, wrp wrote:
>>
>> 1. To begin with, I've heard it said that Ada, designed for embedded
>> system building, is simply not suited to apps for a general computing
>> platform. That's rather vague and I haven't seen any detailed
>> justification of that claim. What would you say?
>
> I would say everything you've heard is wrong. Ada is a general-purpose
> language that has been used successfully in every application domain.
> Ada is the language of choice for S/W that must be correct. Since I want
> all my S/W to be correct, I always use Ada. Examples of small Ada
> applications I've written include one to choose the signature (like the
> one at the end of this message), one to choose the sound to be played
> next time I log in (next time it will say, "What is your favorite
> color?"), and one to display a quote in a dialog window (today's is, "If
> you think you got a nasty taunting this time, you ain't heard nothing
> yet!"). There seems to be a theme there.
>
I've used GNAT to build small "Unix-like" utilities (simple to moderate 
processing, standard-in to standard-out filters, ...) for around 18 
years.  Mostly for DOS/Windows, but I used some, and created some, on 
Linux.  Mostly just whatever I need.

>> 2. I don't need tools to be free, but they have to be affordable to a
>> small shop. If I'm targeting x86-64 (and possibly ARM) is GNAT the
>> only compiler option I have?
>
> RR Software's Janus/Ada (for Windows) is reasonably priced. You might
> also look at Atego.
>
Isn't there still ObjectAda?  There's a limited free version that comes 
with the Barnes Ada 95 book (but not the Ada 2005 book).

There is also an Ada-syntax shell (it was called Bush, but I think it 
was renamed).  You can use the same program as a script or as compiled.

> Note that most compiler are for Ada 95. Only 3 of 7 compilers I'm aware
> of support the entire language in the current standard (published in
> 2007). GNAT is the only compiler I'm aware of that supports features
> from the next standard (hopefully published this year).
>
> Ada 95 is a very good language, so that might not be a concern. (Even
> Ada 83 is a better language than most of the competition.)
>
I doubt I've ever (yet) used any 2005 features for this type of stuff. 
I have (long ago) had to back-port some to Ada 83 (old VAX Ada).

>> 3. How about the quality and availablity of supporting tools like
>> debuggers and profilers?
>
> One nice thing about Ada is not needing to use a debugger.
But it's available - command line gdb or the GPS IDE for GNAT.  (I've 
used it more for confirming code works as I expect than for tracking 
down bugs).

>> 6. Size and latency are sometimes an issue. I've heard that since GNAT
>> is oriented to building larger systems, the executables it produces
>> are comparatively bulky. What is the situation relative to C in that
>> regard?
>
> As I've said, everything you've heard is wrong. Equivalent programs in
> Ada and C create executables of about the same size using gcc (the key
> word is "equivalent"). Robert Dewar of AdaCore claims to have a
> collection of equivalent Ada and C programs that produce identical
> object code using gcc.
These stories usually come from creating simple programs without any 
thought applied to actual "equivalence", or how they're built (if gcc by 
default uses dynamic libraries and GNAT uses static).


-- 
---
BrianG
000
@[Google's email domain]
.com

Re: Practicalities of Ada for app development

[Jeffrey Carter]

On 06/08/2012 05:40 PM, Adam Beneschan wrote:
> On Friday, June 8, 2012 2:35:55 PM UTC-7, Jeffrey Carter wrote:
>
>> One nice thing about Ada is not needing to use a debugger.
>
> I don't get this comment.  Ada is a lot nicer than some languages at
> preventing you from making certain kinds of mistakes, but no language is able
> to prevent logic errors and certain dumb typos.  And if you make this kind of
> error and the program doesn't work, just the fact of its being written in Ada
> doesn't help you much.  There may less need for a debugger because Ada will
> prevent certain types of errors and things like constraint checks will catch
> some others that would cause havoc in C.  But it can't catch everything, and
> even if it does find an index that's out of range it won't tell you why the
> index was out of range.  I mean, Ada is a much better language than certain
> others for writing correct code, but this seems like a gross overstatement.

I haven't used a debugger for a long time. Usually Ada gives an idea of the kind 
of error and its location, and I can easily figure out what the problem is. In 
the rare case that that isn't true, it's quicker to stick in a few Put_Lines 
than to learn to use the debugger again. This is a self-reinforcing situation, 
of course.

-- 
Jeff Carter
"[I]f we should ever separate, my little plum,
I want to give you one little bit of fatherly advice. ... Never
give a sucker an even break."
Poppy
97

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Practicalities of Ada for app development

[gautier_niouzes]

Hello,
Since I develop desktop applications for both my job and for hobby, and GUI apps and command-line apps, my answer is: "yes, you can!".
For 3, have a look there:
  http://sf.net/directory/language:ada/
or other open-source platforms.
For 5, I've never seen an Ada development system that was *not* incremental.
It's probably because Ada is modular from day one (really modular, not the hacks with "include"'s).
For 6, you might see a significant difference only "hello-world"-size programs. You might be concerned only if you intend to develop for a 8-bit platform. For desktop apps, not a problem.
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 08.06.12 22:48, wrp wrote:

> 6. Size and latency are sometimes an issue. I've heard that since GNAT
> is oriented to building larger systems, the executables it produces
> are comparatively bulky. What is the situation relative to C in that
> regard?

Diagnoses of relative sizes of executables have frequently neglected
the effect of static vs dynamic linking, for example.

For the following functions, written in C and Ada, GCC produces
sequences of processor instructions that are almost identical:

-- 8< --

#include <stdint.h>

typedef double Real;
typedef int32_t Nat;

static Nat Last = 42;

Real Gen_Random (const Real Max) {
#define IM 139968
#define IA   3877
#define IC  29573
   
   Last = (Last * IA + IC) % IM;
   return (Max * (Real) Last) / (Real) IM;
}

-- 8< --

package Nothing is
    subtype Real is Long_Float;

    function Gen_Random (Max : in Real) return Real;
end Nothing;

package body Nothing is
    Last : Natural := 42;

    function Gen_Random (Max : in Real) return Real is
       IM : constant := 139_968;
       IA : constant :=   3_877;
       IC : constant :=  29_573;
    begin
       Last := (Last * IA + IC) mod IM;
       return (Max * Real (Last)) / Real (IM);
    end Gen_Random;
end Nothing;

-- 8< --

Translations:
$ gcc -W -c -O nothing.c
$ otool -tv nothing.o  # C output

_Gen_Random:
0000000000000000	pushq	%rbp
0000000000000001	movq	%rsp,%rbp
0000000000000004	imull	$0x00000f25,0xfffffffc(%rip),%ecx
000000000000000e	addl	$0x00007385,%ecx
0000000000000014	movl	$0x1df75681,%edx
0000000000000019	movl	%ecx,%eax
000000000000001b	imull	%edx
000000000000001d	sarl	$0x0e,%edx
0000000000000020	movl	%ecx,%eax
0000000000000022	sarl	$0x1f,%eax
0000000000000025	subl	%eax,%edx
0000000000000027	imull	$0x000222c0,%edx,%edx
000000000000002d	subl	%edx,%ecx
000000000000002f	movl	%ecx,0x00000000(%rip)
0000000000000035	cvtsi2sd	%ecx,%xmm1
0000000000000039	mulsd	%xmm1,%xmm0
000000000000003d	divsd	0x00000023(%rip),%xmm0
0000000000000045	leave
0000000000000046	ret
0000000000000047	nop

$ gnatchop -r -w nothing.ada && gnatmake -gnatwa -gnatp -O nothing.adb
$ otool -tv nothing.o   # Ada output

_nothing__gen_random:
0000000000000000	pushq	%rbp
0000000000000001	movq	%rsp,%rbp
0000000000000004	imull	$0x00000f25,0xfffffffc(%rip),%ecx
000000000000000e	addl	$0x00007385,%ecx
0000000000000014	movl	%ecx,%esi
0000000000000016	sarl	$0x1f,%esi
0000000000000019	movl	%ecx,%eax
000000000000001b	xorl	%esi,%eax
000000000000001d	movl	$0x1df75681,%edx
0000000000000022	mull	%edx
0000000000000024	shrl	$0x0e,%edx
0000000000000027	xorl	%edx,%esi
0000000000000029	imull	$0x000222c0,%esi,%esi
000000000000002f	subl	%esi,%ecx
0000000000000031	movl	%ecx,0x00000000(%rip)
0000000000000037	cvtsi2sd	%ecx,%xmm1
000000000000003b	mulsd	%xmm1,%xmm0
000000000000003f	divsd	0x00000011(%rip),%xmm0
0000000000000047	leave
0000000000000048	ret

While not identical, and while the Ada option -gnatp suppresses all
checks in order to compete with C on a size scale, this ad hoc test
demonstrates the extent to which there is support for saying
an Ada executable will be "bulky", I think.

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 08.06.12 23:35, Jeffrey Carter wrote:

>> 3. How about the quality and availablity of supporting tools like
>> debuggers and profilers?
>
> One nice thing about Ada is not needing to use a debugger.

ObjectAda's is a programmable debugger.  I imagine that to check
the values of a variable for different inputs to the program
might be nicely automatic, better than studying trace outputs.

Re: Practicalities of Ada for app development

[Nomen Nescio]

wrp <i3text@gmail.com> wrote:
> 
> I develop small to medium sized tools. Tasks are mostly limited to
> text processing, database management, and simple visualization.

Ada is lousy for text/string manipulation.  Although I'm an Ada
enthusiast, I cannot think of a worse language in this regard.  The
string library is feature-poor, so you'll find yourself writing basic
libraries for constructs that are included in many languages.

Ada is (by design) a safe language.  But the side effect is that
strings are arrays of characters and the developer is forced to be
mindful of boundaries.. bogged down with detail.

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sat,  9 Jun 2012 11:25:05 +0200 (CEST), Nomen Nescio wrote:

> wrp <i3text@gmail.com> wrote:
>> 
>> I develop small to medium sized tools. Tasks are mostly limited to
>> text processing, database management, and simple visualization.
> 
> Ada is lousy for text/string manipulation.

Which is good, because there practically is no task, which required text
string manipulation. You should parse strings in place without moving
anything except the cursor. The same applies to the formatted output.

> The string library is feature-poor, so you'll find yourself writing basic
> libraries for constructs that are included in many languages.

The constructs which should probably be forbidden in first place. It is
amazing to see what programmers usually write in C++ or C# when faced
trivial problems of parsing some simple input.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[tmoran]

>Ada is lousy for text/string manipulation.  Although I'm an Ada
>enthusiast, I cannot think of a worse language in this regard.
  Speak for yourself.  I find it easy to do text processing in Ada,
given a few home-grown library routines.  But having written compilers
in both Fortran and COBOL, perhaps my standards aren't up to your level.

Re: Practicalities of Ada for app development

[darkestkhan]

On Saturday, June 9, 2012 9:25:05 AM UTC, Nomen Nescio wrote:
> wrp <i3text@gmail.com> wrote:
> > 
> > I develop small to medium sized tools. Tasks are mostly limited to
> > text processing, database management, and simple visualization.
> 
> Ada is lousy for text/string manipulation.  Although I'm an Ada
> enthusiast, I cannot think of a worse language in this regard.  The
> string library is feature-poor, so you'll find yourself writing basic
> libraries for constructs that are included in many languages.
> 
> Ada is (by design) a safe language.  But the side effect is that
> strings are arrays of characters and the developer is forced to be
> mindful of boundaries.. bogged down with detail.

Why not use Unbounded_Strings then? Then it wouldn't be "array of character".
And I don't think that Ada's string manipulation routines are that bad - we have all the important subprograms and only when you have some specialized use case you are in need of writing your own subprogram.
The only thing I can whine about in this regard is UTF8 support. But that is the case for C too. And for many other languages too.

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Sat, 09 Jun 2012 11:36:13 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Sat,  9 Jun 2012 11:25:05 +0200 (CEST), Nomen Nescio wrote:
>
>> wrp <i3text@gmail.com> wrote:
>>>
>>> I develop small to medium sized tools. Tasks are mostly limited to
>>> text processing, database management, and simple visualization.
>>
>> Ada is lousy for text/string manipulation.
>
> Which is good, because there practically is no task, which required text
> string manipulation. You should parse strings in place without moving
> anything except the cursor. The same applies to the formatted output.

I have to agree a lot. That's what I did with a Pascal variant too (did  
not knew Ada at that time, and still not ported to Ada), for a set of  
applications running a lot of text processing (CGI). I avoided passing  
strings everywhere, using references to strings and string ranges, moving  
start and end cursors, etc.

Passing strings is nice for modeling, but is better avoided when the model  
is OK.

For another application which was more generating new text than parsing  
existing text, I also had a strategy using call‑back procedures to print  
“this and that” instead of passing strings to a procedure dedicated to  
printing (you pass references to subprograms instead of passing strings).  
However, depending of the context, passing tagged types or else  
association of a subprogram and a record, may be a better choice.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Sun, 10 Jun 2012 01:18:20 +0200, darkestkhan <darkestkhan@gmail.com> a  
écrit:
> The only thing I can whine about in this regard is UTF8 support. But  
> that is the case for C too. And for many other languages too.

Me too. And even if one don't enjoy UTF‑8 as in Ada 2012, UTF‑8 is easy  
enough to implement in one's own best way (Unicode in the large is complex  
and requires some amount of data, but UTF‑8/16 alone is very simple and  
requires near to no data).

> But that is the case for C too. And for many other languages too.

Except C's lack of strong typing and opaque types does not help.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sat, 9 Jun 2012 16:18:20 -0700 (PDT), darkestkhan wrote:

> The only thing I can whine about in this regard is UTF8 support.

Can you tell us what is missing? I maintain a library providing UTF-8
handling. Proposals are welcome.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Shark8]

On Saturday, June 9, 2012 4:25:05 AM UTC-5, Nomen Nescio wrote:
>
> Ada is (by design) a safe language.  But the side effect is that
> strings are arrays of characters and the developer is forced to be
> mindful of boundaries.. bogged down with detail.

And yet, if we were not mindful of [array] bounds, we would be screaming at all the times using strings caused a buffer-overflow.

There are ways to "work around" the problem, like the reading long/variable-length strings piece-at-a-time and constructing the result inside a function. (Using recursion: http://www.adapower.com/index.php?Command=Class&ClassID=Basics&CID=202 )

That said, there are languages that are made for text processing, SNOBOL [IIRC] is one such language. (Also, I think there's an Ada port of the SPITBOL macros as part of the GNAT-specific packages.) Ironically, most of them aren't used in the mainstream of software development which tends to fall back on C's string manipulation [style of] functions or Regex (which is horrible if you look at Regex from a maintenance perspective.).

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Sun, 10 Jun 2012 16:04:46 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> I maintain a library providing UTF-8 handling.

Strings_Edit?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sun, 10 Jun 2012 18:51:53 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sun, 10 Jun 2012 16:04:46 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> I maintain a library providing UTF-8 handling.
> 
> Strings_Edit?

Yes

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Sun, 10 Jun 2012 17:49:40 +0200, Shark8 <onewingedshark@gmail.com> a  
écrit:
> Ironically, most of them aren't used in the mainstream of software  
> development which tends to fall back on C's string manipulation [style  
> of] functions or Regex (which is horrible if you look at Regex from a  
> maintenance perspective.).

If Regular Expressions appears as is, as literals in the program, yes,  
that's a maintenance nightmare. But you may decompose the expressions,  
build them incrementally (I use to do it with Python), or even fork to  
something similar which could use objects and structures instead of  
unreadable literal expressions (I don't one, just an idea).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Sun, 10 Jun 2012 19:00:22 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Sun, 10 Jun 2012 18:51:53 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> Le Sun, 10 Jun 2012 16:04:46 +0200, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>> I maintain a library providing UTF-8 handling.
>>
>> Strings_Edit?
>
> Yes

Please, why have you defined Code_Point as a modular type?

http://www.dmitry-kazakov.de/ada/strings_edit.htm#7

Why

    type Code_Point  is mod 2 ** 32;

instead of

    type Code_Point  is range 0 .. ((2 ** 32) - 1);

?

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[darkestkhan]

On Sunday, June 10, 2012 2:04:46 PM UTC, Dmitry A. Kazakov wrote:
> On Sat, 9 Jun 2012 16:18:20 -0700 (PDT), darkestkhan wrote:
> 
> > The only thing I can whine about in this regard is UTF8 support.
> 
> Can you tell us what is missing? I maintain a library providing UTF-8
> handling. Proposals are welcome.
> 

I know about matreshka - I'm only saying that language itself doesn't support UTF8, which is different from `there is no library for handling UTF8 encoded strings`.

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sun, 10 Jun 2012 11:15:47 -0700 (PDT), darkestkhan wrote:

> On Sunday, June 10, 2012 2:04:46 PM UTC, Dmitry A. Kazakov wrote:
>> On Sat, 9 Jun 2012 16:18:20 -0700 (PDT), darkestkhan wrote:
>> 
>>> The only thing I can whine about in this regard is UTF8 support.
>> 
>> Can you tell us what is missing? I maintain a library providing UTF-8
>> handling. Proposals are welcome.
> 
> I know about matreshka

That is not mine.

> - I'm only saying that language itself doesn't
> support UTF8, which is different from `there is no library for handling
> UTF8 encoded strings`.

Why should language support it? It is always an advantage when the language
is capable to support something at the library level rather than
hard-wired.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sun, 10 Jun 2012 19:18:09 +0200, Yannick Duch�ne (Hibou57) wrote:

> Please, why have you defined Code_Point as a modular type?
> 
> http://www.dmitry-kazakov.de/ada/strings_edit.htm#7
> 
> Why
> 
>     type Code_Point  is mod 2 ** 32;
> 
> instead of
> 
>     type Code_Point  is range 0 .. ((2 ** 32) - 1);

Because code point is unsigned. When you declare something signed you do
that because you want negative inverses. Signed integers have the base type
with 0 in the middle of its range.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sun, 10 Jun 2012 19:04:02 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Sun, 10 Jun 2012 17:49:40 +0200, Shark8 <onewingedshark@gmail.com> a  
> �crit:
>> Ironically, most of them aren't used in the mainstream of software  
>> development which tends to fall back on C's string manipulation [style  
>> of] functions or Regex (which is horrible if you look at Regex from a  
>> maintenance perspective.).
> 
> If Regular Expressions appears as is, as literals in the program, yes,  
> that's a maintenance nightmare. But you may decompose the expressions,  
> build them incrementally (I use to do it with Python), or even fork to  
> something similar which could use objects and structures instead of  
> unreadable literal expressions (I don't one, just an idea).

That does not change the fact that SNOBOL patterns are far more powerful
(the language generated is of a much wider class), much more readable. The
problems are that any patterns are unmaintainable unless trivial. Trivial
patterns require no special means. Another problem is not in having pattern
as an object. This is well possible in Ada. The actual problem is to have a
pattern matching construct in the language. You need something like

   match Variable in Stream by Pattern do
       ...
   end match;

which would initialize Variable or set of variables by matched parts of the
Pattern while advancing Stream while the pattern is matched. It is very
difficult to describe in a structured manner. The way SNOBOL handles that
is total mess. Variables are specified in the pattern. Success and failure
are just labels etc. It is not worth the efforts to bother about that,
because, as I said, patterns is a bad idea in general.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Nomen Nescio]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
> > Please, why have you defined Code_Point as a modular type?
> 
> Because code point is unsigned. When you declare something signed
> you do that because you want negative inverses. Signed integers have
> the base type with 0 in the middle of its range.

That's no reason to use mod.  You can put boundaries where you want
them, integer, or mod.

It's about the operators.  Mod affects the arithmetic.  If you want
my_type'last + 1 to equal my_type'first, then mod is appropriate.  If
you want the Ada runtime to bitch when you do that, then a unsigned
non-modular discrete type is appropriate.

Choosing a modular type in a case where it doesn't make sense to have
modular arithmetic operators is an abuse of the language.

Re: Practicalities of Ada for app development

[Nasser M. Abbasi]

On 6/10/2012 10:49 AM, Shark8 wrote:
>

> That said, there are languages that are made for text processing,
>SNOBOL [IIRC] is one such language.

Yes, SNOBOL is very good for strings becuase it
has patterns build-in

http://www.snobol4.org/docs/burks/tutorial/ch4.htm#4.5

But perl is here now and it is what is used for string
processing more than anything I would think.

--Nasser

Re: Practicalities of Ada for app development

[Nasser M. Abbasi]

On 6/10/2012 2:47 PM, Dmitry A. Kazakov wrote:

>It is not worth the efforts to bother about that,
> because, as I said, patterns is a bad idea in general.
>

Hello Dmitry;

Have not followed the whole discussion here. But I just
wanted to mention on the above, is that Mathematica is based
on just this concept. Patterns.  It is really a pattern
replacement language at its core.

For example, in Mathematica, when I define a function

f[x_] := x^2

x_ above means the pattern x.  On the right side, the
pattern named x is replaced by x raised to 2. That is
all what Mathematica does.

When no more pattern matching replacement can be done, the final
resulting expression is evaluated and the result returned.

Hence f[2] returns 2^2 which evaluates to 4 while
f["micky mouse"] returns micky mouse^2

My point is pattern based languages can be very powerful,
Mathematica is an example, may be the issue is implementation
and such. So what works fine in Mathematica, might not work for Ada
due to basic design of the language and I think your point
about  "bad in general" refer to some context which I missed
because I did not follow the whole thread, I just jumped in here :)

--Nasser

Re: Practicalities of Ada for app development

[Jeffrey Carter]

On 06/10/2012 05:00 PM, Nasser M. Abbasi wrote:
>
> But perl is here now and it is what is used for string
> processing more than anything I would think.

C is here now and it is what is used for networking S/W more than anything.

COBOL is here now and it is what is used for financial S/W more than anything.

Popularity is hardly a reason to choose a language.

-- 
Jeff Carter
"C++: The power, elegance and simplicity of a hand grenade."
Ole-Hjalmar Kristensen
90

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Practicalities of Ada for app development

[Jacob Sparre Andersen]

darkestkhan <darkestkhan@gmail.com> writes:

> I know about matreshka - I'm only saying that language itself doesn't
> support UTF8, which is different from `there is no library for
> handling UTF8 encoded strings`.

What do you mean by "doesn't support UTF8"?  Is your problem that the
internal representation of strings isn't UTF-8 encoded?  Source files
can be UTF-8 encoded, if you like it that way?  And you are free to
store your Wide_Wide_Strings on disk in UTF-8 encoding, if you prefer
that.

Greetings,

Jacob
-- 
�But you have to be a bit wary of a ship that collects
 snowflakes.�                                  -- Diziet Sma

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sun, 10 Jun 2012 23:36:46 +0200 (CEST), Nomen Nescio wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> 
>>> Please, why have you defined Code_Point as a modular type?
>> 
>> Because code point is unsigned. When you declare something signed
>> you do that because you want negative inverses. Signed integers have
>> the base type with 0 in the middle of its range.
> 
> That's no reason to use mod.  You can put boundaries where you want
> them, integer, or mod.
> 
> It's about the operators.

Exactly, there is *no* arithmetic of code points. Code point is an
enumeration. The modulo ring operations with code points are less
meaningless than bounded integer arithmetic is. You better don't add code
points at all. Implementation per modular type has performance advantages,
so I chose it. I considered Wide_Wide_Character instead, but dropped that
idea because it would lack numeric literals common for Unicode.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Sun, 10 Jun 2012 19:37:41 -0500, Nasser M. Abbasi wrote:

> On 6/10/2012 2:47 PM, Dmitry A. Kazakov wrote:
> 
>>It is not worth the efforts to bother about that,
>> because, as I said, patterns is a bad idea in general.
> 
> Have not followed the whole discussion here. But I just
> wanted to mention on the above, is that Mathematica is based
> on just this concept. Patterns.  It is really a pattern
> replacement language at its core.
> 
> For example, in Mathematica, when I define a function
> 
> f[x_] := x^2
> 
> x_ above means the pattern x.  On the right side, the
> pattern named x is replaced by x raised to 2. That is
> all what Mathematica does.
> 
> When no more pattern matching replacement can be done, the final
> resulting expression is evaluated and the result returned.

It was called macro expansion in earlier days. An idea by margin more
horrific than patterns in their original meaning (1. A language used to
define a formal language; 2. Texture).

Yes, I am aware that the new generation of awful languages uses "pattern"
instead of "macro."  I cannot, sorry, too old for that.

Anyway a preprocessor integrated into the language syntax is the worst
nightmare one can imagine. If you proposed curly brackets and equality as
assignment operator for Ada, that would be a lesser shock to me. (:-))

BTW, Ada has macros, they are called "generics."

> My point is pattern based languages can be very powerful,
> Mathematica is an example, may be the issue is implementation
> and such.

One aspect of languages evolution is dropping powerful constructs invented
at the dawn of computing, while remaining at the same level of
expressiveness. The most notorious example is goto. Powerful constructs are
dangerous. You don't use nukes to drill a whole in the wall...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 11.06.12 10:22, Dmitry A. Kazakov wrote:
> On Sun, 10 Jun 2012 23:36:46 +0200 (CEST), Nomen Nescio wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>>
>>>> Please, why have you defined Code_Point as a modular type?
>>>
>>> Because code point is unsigned. When you declare something signed
>>> you do that because you want negative inverses. Signed integers have
>>> the base type with 0 in the middle of its range.
>>
>> That's no reason to use mod.  You can put boundaries where you want
>> them, integer, or mod.
>>
>> It's about the operators.
> 
> Exactly, there is *no* arithmetic of code points.

In case there is no arithmetic of code points, it is really
surprising to see

   type Code_Point is mod 2**32;

and not

   type Code_Point is private;

;-)

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Mon, 11 Jun 2012 16:27:30 +0200, Georg Bauhaus wrote:

> On 11.06.12 10:22, Dmitry A. Kazakov wrote:
>> On Sun, 10 Jun 2012 23:36:46 +0200 (CEST), Nomen Nescio wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>>>
>>>>> Please, why have you defined Code_Point as a modular type?
>>>>
>>>> Because code point is unsigned. When you declare something signed
>>>> you do that because you want negative inverses. Signed integers have
>>>> the base type with 0 in the middle of its range.
>>>
>>> That's no reason to use mod.  You can put boundaries where you want
>>> them, integer, or mod.
>>>
>>> It's about the operators.
>> 
>> Exactly, there is *no* arithmetic of code points.
> 
> In case there is no arithmetic of code points, it is really
> surprising to see
> 
>    type Code_Point is mod 2**32;
> 
> and not
> 
>    type Code_Point is private;

Code points are numeric:

http://en.wikipedia.org/wiki/Unicode

As I wrote, I considered Wide_Wide_Character, which also partially
implements the interface of code point. I used modular interface instead
because numeric literals seem more important for code points than character
literals.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> Code points are numeric:
>
> http://en.wikipedia.org/wiki/Unicode
>
> As I wrote, I considered Wide_Wide_Character, which also partially
> implements the interface of code point. I used modular interface
> instead because numeric literals seem more important for code points
> than character literals.

Did you remember to override the operators on your code point type with
abstract functions?

   type Code_Point is mod 2 ** 32;
   overriding
   function "+" (Left, Right : Code_Point) return Code_Point is abstract;
   ...

Greetings,

Jacob
-- 
"The same equations have the same solutions."

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 11.06.12 16:43, Dmitry A. Kazakov wrote:
> On Mon, 11 Jun 2012 16:27:30 +0200, Georg Bauhaus wrote:
> 
>> On 11.06.12 10:22, Dmitry A. Kazakov wrote:
>>> On Sun, 10 Jun 2012 23:36:46 +0200 (CEST), Nomen Nescio wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>>>>
>>>>>> Please, why have you defined Code_Point as a modular type?
>>>>>
>>>>> Because code point is unsigned. When you declare something signed
>>>>> you do that because you want negative inverses. Signed integers have
>>>>> the base type with 0 in the middle of its range.
>>>>
>>>> That's no reason to use mod.  You can put boundaries where you want
>>>> them, integer, or mod.
>>>>
>>>> It's about the operators.
>>>
>>> Exactly, there is *no* arithmetic of code points.
>>
>> In case there is no arithmetic of code points, it is really
>> surprising to see
>>
>>    type Code_Point is mod 2**32;
>>
>> and not
>>
>>    type Code_Point is private;
> 
> Code points are numeric:

Numeric to what extent? I'd have thought that code points need little more
than equality and ordering, with conversion functions to/from a "more"
numeric type such as mod 2**32 or a range type.  Either for construction
of code point values, or in case an algorithm wants to use offsets,
or use a table indexed by a numeric subtype made from a "subsection" of
the repertoire.

The construction function could be nicely Unicode-ish when named U:

   PI : constant Code_Point := U+16#03C0#;

> http://en.wikipedia.org/wiki/Unicode


package Unicode_Stuff is

   Data_Error : exception;

   type Unsigned is mod 2**32;

   type Code_Point is private;

   Max_Code_Point : constant := 16#10FFFF#;

   type Non_Code_Point(<>) is limited private;

   U : constant Non_Code_Point;

   function "+"
     (U      : in Non_Code_Point;
      Number : in Unsigned)
   return Code_Point;
   --  raises Data_Error if Number > Max_Code_Point;

private
   type Code_Point is new Unsigned range 0 .. Max_Code_Point;
   type Non_Code_Point is limited null record;
   U : constant Non_Code_Point := (null record);
end Unicode_Stuff;

Re: Practicalities of Ada for app development

[Adam Beneschan]

On Sunday, June 10, 2012 2:36:46 PM UTC-7, Nomen Nescio wrote:
> "Dmitry A. Kazakov" wrote:
> > 
> > > Please, why have you defined Code_Point as a modular type?
> > 
> > Because code point is unsigned. When you declare something signed
> > you do that because you want negative inverses. Signed integers have
> > the base type with 0 in the middle of its range.
> 
> That's no reason to use mod.  You can put boundaries where you want
> them, integer, or mod.

This isn't quite true because of subtleties of the language.  When you define an  integer "type" with range 0..(2**32-1), the *type* you declare is actually a larger type than that.  It has to be at least -(2**32-1) .. (2**32-1), which is a type that requires 33 bits (in practice, it will probably be 
-2**64 .. 2**64-1).  You then get a subtype with range 0..(2**32-1).  But some calculations have to be done using the base type, which means that using a signed integer type can require some extra conversions, and can require additional processing time on a machine that doesn't have 64-bit arithmetic instructions.  It probably wouldn't matter much if the type is being used to represent a Unicode code point.  But in a more general case, you have to be careful.  It's not really accurate to simply say "you can put boundaries where you want".

IIRC, some people have proposed adding unsigned integer types to the language; they've argued that modular types aren't good enough for some purposes.  But the idea was turned down.

                        -- Adam

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Mon, 11 Jun 2012 18:19:34 +0200, Jacob Sparre Andersen wrote:

> Dmitry A. Kazakov wrote:
> 
>> Code points are numeric:
>>
>> http://en.wikipedia.org/wiki/Unicode
>>
>> As I wrote, I considered Wide_Wide_Character, which also partially
>> implements the interface of code point. I used modular interface
>> instead because numeric literals seem more important for code points
>> than character literals.
> 
> Did you remember to override the operators on your code point type with
> abstract functions?
> 
>    type Code_Point is mod 2 ** 32;
>    overriding
>    function "+" (Left, Right : Code_Point) return Code_Point is abstract;
>    ...

I know the trick. I didn't do that because +1 is useful for sets and maps.
Code_Point'Succ is annoying.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Mon, 11 Jun 2012 19:14:45 +0200, Georg Bauhaus wrote:

> On 11.06.12 16:43, Dmitry A. Kazakov wrote:
>> On Mon, 11 Jun 2012 16:27:30 +0200, Georg Bauhaus wrote:
>> 
>>> On 11.06.12 10:22, Dmitry A. Kazakov wrote:
>>>> On Sun, 10 Jun 2012 23:36:46 +0200 (CEST), Nomen Nescio wrote:
>>>>
>>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>>>>>
>>>>>>> Please, why have you defined Code_Point as a modular type?
>>>>>>
>>>>>> Because code point is unsigned. When you declare something signed
>>>>>> you do that because you want negative inverses. Signed integers have
>>>>>> the base type with 0 in the middle of its range.
>>>>>
>>>>> That's no reason to use mod.  You can put boundaries where you want
>>>>> them, integer, or mod.
>>>>>
>>>>> It's about the operators.
>>>>
>>>> Exactly, there is *no* arithmetic of code points.
>>>
>>> In case there is no arithmetic of code points, it is really
>>> surprising to see
>>>
>>>    type Code_Point is mod 2**32;
>>>
>>> and not
>>>
>>>    type Code_Point is private;
>> 
>> Code points are numeric:
> 
> Numeric to what extent?

In the sense that there exists a bijection code point <-> number.

> I'd have thought that code points need little more
> than equality and ordering, with conversion functions to/from a "more"
> numeric type such as mod 2**32 or a range type.  Either for construction
> of code point values, or in case an algorithm wants to use offsets,
> or use a table indexed by a numeric subtype made from a "subsection" of
> the repertoire.
> 
> The construction function could be nicely Unicode-ish when named U:
> 
>    PI : constant Code_Point := U+16#03C0#;

Funny, but U+number is a notation for a language lacking proper numeric
types. Why not to use just number if the language allows that?

BTW, as practice shows, code points are used rarely and almost always as an
argument for conversion to a UTF-8 string.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Jeffrey Carter]

On 06/11/2012 11:29 AM, Adam Beneschan wrote:
>
> IIRC, some people have proposed adding unsigned integer types to the
> language; they've argued that modular types aren't good enough for some
> purposes.  But the idea was turned down.

Really, there are 2 orthogonal qualities: signed or unsigned representation, and 
overflow checking or not. These lead to 4 kinds of integer types. Ada has direct 
support for 2:

* signed, checked (type T is range Low .. High;)
* unsigned, unchecked (type T is mod High;)

There is also a kind of support for unsigned, checked:

type T is range 0 .. 2 ** N - 1;
for T'Size use N;

One can turn off overflow checking to get signed, unchecked.

-- 
Jeff Carter
"You me on the head hitted."
Never Give a Sucker an Even Break
108

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 11.06.12 20:38, Dmitry A. Kazakov wrote:

>> The construction function could be nicely Unicode-ish when named U:
>>
>>     PI : constant Code_Point := U+16#03C0#;
>
> Funny, but U+number is a notation for a language lacking proper numeric
> types. Why not to use just number if the language allows that?

My style rules will suggests qualification, Code_Point'(16#03C0#),
so as to state what I mean without any necessity to inferen from
context.
Reason: numeric literals typically mean a number of some "arithmetic"
type.

U+number is similar to the explicit checking of units (and possibly
values) in

   Some_Time_Object :=  45 * Seconds;

presented in Barnes's book.

When using U+number, the checks are performed by one subprogram ("+").
A different design might (but need not) require checking in many places.
U+number feels a bit like using a "constructor" for literals.


> BTW, as practice shows, code points are used rarely and almost always as an
> argument for conversion to a UTF-8 string.

OK. I imagine, though, that most US programming styles will suggest not to
write non-7-bit source text. When I need a UTF-8 encoded literal PI, wouldn't
I then need to write something like the following?

  PI : constant UTF_8_String :=
    Character'Val (16#CF#)
  & Character'Val (16#80#)
  & Character'Val (16#0A#);

Re: Practicalities of Ada for app development

[Nomen Nescio]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> wrote:

> On 06/10/2012 05:00 PM, Nasser M. Abbasi wrote:
> >
> > But perl is here now and it is what is used for string
> > processing more than anything I would think.
> 
> C is here now and it is what is used for networking S/W more than anything.
> 
> COBOL is here now and it is what is used for financial S/W more than anything.
> 
> Popularity is hardly a reason to choose a language.
> 

I worked on an Ada project where Ada SWEs with ~5-15 years experience
were tasked with a text manipulation problem.  Took these senior
engineers *days* to complete the project.  One of them deviated from
the crowd and used PERL.  Took him less than 2 hours to complete the
coursework.  After that, the company banned PERL for that particular
project (fyi, it was a six sigma project).

There is a good reason Ada is "unpopular" for text parsing and
manipulation.

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Mon, 11 Jun 2012 22:50:33 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> U+number is similar to the explicit checking of units (and possibly
> values) in
>
>    Some_Time_Object :=  45 * Seconds;
>

Good. Will think of it in the future.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Mon, 11 Jun 2012 20:29:47 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> IIRC, some people have proposed adding unsigned integer types to the  
> language; they've argued that modular types aren't good enough for some  
> purposes.  But the idea was turned down.

Why?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Adam Beneschan]

On Monday, June 11, 2012 2:10:07 PM UTC-7, Nomen Nescio wrote:
> Jeffrey Carter wrote:
> 
> > On 06/10/2012 05:00 PM, Nasser M. Abbasi wrote:
> > >
> > > But perl is here now and it is what is used for string
> > > processing more than anything I would think.
> > 
> > C is here now and it is what is used for networking S/W more than anything.
> > 
> > COBOL is here now and it is what is used for financial S/W more than anything.
> > 
> > Popularity is hardly a reason to choose a language.
> > 
> 
> I worked on an Ada project where Ada SWEs with ~5-15 years experience
> were tasked with a text manipulation problem.  Took these senior
> engineers *days* to complete the project.  One of them deviated from
> the crowd and used PERL.  Took him less than 2 hours to complete the
> coursework.  After that, the company banned PERL for that particular
> project (fyi, it was a six sigma project).
> 
> There is a good reason Ada is "unpopular" for text parsing and
> manipulation.

The length of time it takes to write a program isn't a valid metric.  Real software not only has to be written, it has to be read and maintained later, often by someone who is not the person who originally wrote it.  If someone thinks a language is better just because it lets you write programs faster, I'm not sure that person should be called a software engineer.

Given that, there are some things are built into Perl but not Ada that are useful for handling text, such as RE matching.  But there are existing libraries to do such things in Ada.  I think Vadim Godunko has a regular expression matcher (although I really haven't looked at it), and for those who dislike regular expressions there are alternatives.  I haven't actually tried any of them, so I can't speak to how simple they are to use, but maybe others have and can comment.  I'm sure that even with those libraries, it would still take a little longer to write programs in Ada, because Ada is a little more verbose.  But that's what helps programs be more readable, not to mention less error-prone.

                         -- Adam

Re: Practicalities of Ada for app development

[Jeffrey Carter]

On 06/11/2012 02:10 PM, Nomen Nescio wrote:
>
> I worked on an Ada project where Ada SWEs with ~5-15 years experience
> were tasked with a text manipulation problem.  Took these senior
> engineers *days* to complete the project.  One of them deviated from
> the crowd and used PERL.  Took him less than 2 hours to complete the
> coursework.  After that, the company banned PERL for that particular
> project (fyi, it was a six sigma project).

How long it took to write something for a "coursework" problem is not indicative 
of anything. On real projects, ease of reading is more important than ease of 
writing, and time to write is not a major concern.

> There is a good reason Ada is "unpopular" for text parsing and
> manipulation.

There is a good reason languages like PERL are banned from projects that are 
concerned about quality.

-- 
Jeff Carter
"You me on the head hitted."
Never Give a Sucker an Even Break
108

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Mon, 11 Jun 2012 10:37:09 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Sun, 10 Jun 2012 19:37:41 -0500, Nasser M. Abbasi wrote:
>
>> On 6/10/2012 2:47 PM, Dmitry A. Kazakov wrote:
>>
>>> It is not worth the efforts to bother about that,
>>> because, as I said, patterns is a bad idea in general.
>>
>> Have not followed the whole discussion here. But I just
>> wanted to mention on the above, is that Mathematica is based
>> on just this concept. Patterns.  It is really a pattern
>> replacement language at its core.
>>
>> For example, in Mathematica, when I define a function
>>
>> f[x_] := x^2
>>
>> x_ above means the pattern x.  On the right side, the
>> pattern named x is replaced by x raised to 2. That is
>> all what Mathematica does.
>>
>> When no more pattern matching replacement can be done, the final
>> resulting expression is evaluated and the result returned.
>
> It was called macro expansion in earlier days. An idea by margin more
> horrific than patterns in their original meaning (1. A language used to
> define a formal language; 2. Texture).

That's not horrific, that's pure mathematic. This equivalence by  
substitution is an important area of the core of all math formalisms, the  
establishment of formal proofs included.

What's horrific, is wild substitution, with no wellformedness and validity  
check of substituted expressions. Lack of substitution tracking may also  
help to provide a feeling of “horrific”.

What Nasser described, is expression substitution, not semantically  
neutral text substitution.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Mon, 11 Jun 2012 22:50:33 +0200, Georg Bauhaus wrote:

> Reason: numeric literals typically mean a number of some "arithmetic"
> type.

No, a numeric literal means what it tells "a number."

> U+number is similar to the explicit checking of units (and possibly
> values) in
> 
>    Some_Time_Object :=  45 * Seconds;
>
> presented in Barnes's book.

Technically Barnes is not quite right. A correct expression should be:

   Some_Duration_Object := 45.0 * s;

1. 45.0 is floating-point;
2. You cannot multiply time, you do durations (time intervals);
3. "s" or "second" is the proper name of the unit.

http://www.dmitry-kazakov.de/ada/units.htm

> When using U+number, the checks are performed by one subprogram ("+").

Code points are numbers, not dimensioned numbers. Dimensioned numbers form
a structure different from one of the code points. You are confusing type
and dimension. Dimension is one characteristic of some types, e.g. a
constraint, but not every type is dimensioned.

> A different design might (but need not) require checking in many places.
> U+number feels a bit like using a "constructor" for literals.

Literal per definition cannot be a constructor. Its name reveals that:
literal is denotes a value, e.g. a number, "literally." Furthermore,
literal is a syntactic notion (expression term), while constructors are
related to the program semantics (create objects from raw memory).

Anyway, the point stands: in a properly typed languages you need no special
forms of literals. I guess that U+n stems from C-ish nL, nU etc. These are
syntactic inventions necessary in C because the language is incapable to
resolve ambiguity using the result type. C is bottom up. Ada is not bottom
up. You can overload numeric literals in almost any context in Ada. So you
don't need silly tricks like U+n.

>> BTW, as practice shows, code points are used rarely and almost always as an
>> argument for conversion to a UTF-8 string.
> 
> OK. I imagine, though, that most US programming styles will suggest not to
> write non-7-bit source text. When I need a UTF-8 encoded literal PI, wouldn't
> I then need to write something like the following?
> 
>   PI : constant UTF_8_String :=
>     Character'Val (16#CF#)
>   & Character'Val (16#80#)
>   & Character'Val (16#0A#);

No. The proper way to do this is:

   UTF8_Pi : constant String := Image (16#0C30#);

http://www.dmitry-kazakov.de/ada/strings_edit.htm#Strings_Edit.UTF8

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Tue, 12 Jun 2012 08:24:44 +0200, Yannick Duch�ne (Hibou57) wrote:

> That's not horrific, that's pure mathematic.

Mathematica /= mathematics

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Nomen Nescio]

> The length of time it takes to write a program isn't a valid metric.

Of course it is.  It's an accurate measure of the expressive power of
a language for the task at hand.

> Real software not only has to be written, it has to be read and
> maintained later, often by someone who is not the person who
> originally wrote it.

Indeed.

> If someone thinks a language is better just because it lets you
> write programs faster, I'm not sure that person should be called a
> software engineer.

I do not accept your idea that expressive power is inversely
proportional to maintainability, which is essentially what you're
trying to imply.  Makes no sense.  You can have your cake, and eat it
too.  

Depending on the task and language, there will be cases where
implementation can be quick, without detriment to maintainability.  By
"quick", I don't mean hasty designless code, but simply choosing the
right tool for the job.

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 12.06.12 09:55, Dmitry A. Kazakov wrote:
> On Mon, 11 Jun 2012 22:50:33 +0200, Georg Bauhaus wrote:
>
>> Reason: numeric literals typically mean a number of some "arithmetic"
>> type.
>
> No, a numeric literal means what it tells "a number."

"A number" tells little to an average reader of a program
seeing just that number.


>>     Some_Time_Object :=  45 * Seconds;

> Technically Barnes is not quite right.

Oh, I believe he is right and makes sure this is understood:

"the expression uses the rule that a fixed[!] point value
can be multiplied by an integer giving a result of the same fixed
point type". (�18.3, p.465)

Using whole quantities of Seconds, Minutes, and so on will give
us aggregates and formulas that do not invite confusion by
stipulating that the fraction can be anything but 0.


> 2. You cannot multiply time, you do durations (time intervals);

Like in "two times"? "Time after Time"? "Many times"?


> 3. "s" or "second" is the proper name of the unit.

"Seconds" is the plural of a "second" (one unit of time).

"s" is asking for trouble, since "s" may well name a parameter
or variable, like when copied from a formula (s = v * t, say).

By comparison, is "m" the name of Meter or of Minute?


> http://www.dmitry-kazakov.de/ada/units.htm
>
>> When using U+number, the checks are performed by one subprogram ("+").
>
> Code points are numbers, not dimensioned numbers.

Unit does not say anything about dimensions. Actually, "unit" is
not the same as whatever dimension might mean. (Generic units...)

But, indeed, my intent was say "not just typed, but expressly so",
and checked.

> in a properly typed languages you need no special
> forms of literals. I guess that U+n stems from C-ish nL, nU etc.

Uhm, no! U+number is official U-nicode notation. (Also in ISO 10646.)

Can we agree that U'(16#03C0#) is o.K. even though it forces
handling of range constraint violations to be global?


> You can overload numeric literals in almost any context in Ada.

Overloading literals is the questionable part. It is what got me
started. No inference, please! Even when compilers can decide
whether or not there is that single assignable type!

What I consider silly is to insist that readers infer
the proper meaning of a sequence of digits when we can
do better. Distillation of source code should mean:
- to produce a fine executable,
not
- to produce  the smallest element from the set
   of technically equivalent source texts of varying lengths.


> The proper way to do this is:
>
>     UTF8_Pi : constant String := Image (16#0C30#);

How is that different from

       UTF8_Pi : constant String := U+16#0C30;

Apart from using the relatively unspecific name Image,
which conventionally refers to a "default print image"
of a type, frequently used in trace based debugging?

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Tue, 12 Jun 2012 11:48:43 +0200, Georg Bauhaus wrote:

> On 12.06.12 09:55, Dmitry A. Kazakov wrote:
>> On Mon, 11 Jun 2012 22:50:33 +0200, Georg Bauhaus wrote:
>>
>>> Reason: numeric literals typically mean a number of some "arithmetic"
>>> type.
>>
>> No, a numeric literal means what it tells "a number."
> 
> "A number" tells little to an average reader of a program
> seeing just that number.

Sorry for the reader, but numeric literal is just that: a number.

>>>     Some_Time_Object :=  45 * Seconds;
> 
>> Technically Barnes is not quite right.
> 
> Oh, I believe he is right and makes sure this is understood:
> 
> "the expression uses the rule that a fixed[!] point value
> can be multiplied by an integer giving a result of the same fixed
> point type". (�18.3, p.465)
>
> Using whole quantities of Seconds, Minutes, and so on will give
> us aggregates and formulas that do not invite confusion by
> stipulating that the fraction can be anything but 0.

It is very difficult if possible to create dimensioned fixed-point system
due to problems of handling accuracy. Note that the point of using fixed
point is to keep results exact.

>> 2. You cannot multiply time, you do durations (time intervals);
> 
> Like in "two times"? "Time after Time"? "Many times"?

The thing represented by Ada.Calendar.Time or Ada.Real_Time.Time has no
dimension. You can multiply durations by themselves and by other
dimensioned values and scalars. Times can be subtracted. Duration can be
added to time.
 
>> 3. "s" or "second" is the proper name of the unit.
> 
> "Seconds" is the plural of a "second" (one unit of time).

http://physics.nist.gov/cuu/Units/units.html
 
> "s" is asking for trouble, since "s" may well name a parameter
> or variable, like when copied from a formula (s = v * t, say).
> 
> By comparison, is "m" the name of Meter or of Minute?

"m" is meter. Minute is not a SI unit. Yes, there are many conflicting
names when irregular or units outside SI are involved.

As for conflicts with names of variables, that is not a problem in Ada.

>> in a properly typed languages you need no special
>> forms of literals. I guess that U+n stems from C-ish nL, nU etc.
> 
> Uhm, no! U+number is official U-nicode notation. (Also in ISO 10646.)

Yes, but C is where the ears are growing from.

If you want to follow the notation, you should to do it exactly, i.e.
U+0C20, without dashes around the number. If you don't, then use the most
appropriate way from the implementation language perspective. The middle
way would bring nothing but confusion.

>> You can overload numeric literals in almost any context in Ada.
> 
> Overloading literals is the questionable part. It is what got me
> started. No inference, please! Even when compilers can decide
> whether or not there is that single assignable type!
> 
> What I consider silly is to insist that readers infer
> the proper meaning of a sequence of digits when we can
> do better.

Sorry, but the program as a whole is not what it means. You have to
interpret the program in order to understand its semantics. A good language
design is to support trivial inference and require complex things explicit. 

Type annotation of operands of an expression *is* trivial, or else the
program is poorly designed.

>> The proper way to do this is:
>>
>>     UTF8_Pi : constant String := Image (16#0C30#);
> 
> How is that different from
> 
>        UTF8_Pi : constant String := U+16#0C30;

Compare:

   Image (16#0C30#) * 3

and

   U+16#0C30# * 3

Anyway, if U+n notation support seem the only problem with Ada UTF-8, I
gather that the issue is closed. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 12.06.12 13:44, Dmitry A. Kazakov wrote:

> Sorry for the reader, but numeric literal is just that: a number.
> 
>>>>     Some_Time_Object :=  45 * Seconds;

> It is very difficult if possible to create dimensioned fixed-point system
> due to problems of handling accuracy.

(Who cares about SI units when handling Unicode?)

> http://physics.nist.gov/cuu/Units/units.html

http://www.merriam-webster.com/dictionary/unit

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Tue, 12 Jun 2012 14:17:13 +0200, Georg Bauhaus wrote:

> (Who cares about SI units when handling Unicode?)

You?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Fritz Wuehler]

Nomen Nescio <nobody@dizum.com> wrote:

> > The length of time it takes to write a program isn't a valid metric.
> 
> Of course it is.  It's an accurate measure of the expressive power of
> a language for the task at hand.

It isn't a metric that's useful to people who write Ada since it doesn't
account for things like performance, maintainability, and most of all,
correctness. Considering the development process on any significant piece of
code, which would you rather use, Perl or Ada? Which would you rather
maintain, Perl or Ada? And which would you rather be responsible for?


> > If someone thinks a language is better just because it lets you
> > write programs faster, I'm not sure that person should be called a
> > software engineer.
> 
> I do not accept your idea that expressive power is inversely
> proportional to maintainability, which is essentially what you're
> trying to imply.  Makes no sense.  You can have your cake, and eat it
> too.  

In practice that doesn't seem to happen very often and  Perl is not an
argument for that view, quite the contrary.

> Depending on the task and language, there will be cases where
> implementation can be quick, without detriment to maintainability.  By
> "quick", I don't mean hasty designless code, but simply choosing the
> right tool for the job.

Fine, but Perl is not something that is readable nor maintainable, and it
should not be used for serious software that is intended to be placed in
service for a long period, nor for an application that is going to need to
grow and adapt. It is fine for quick-and-dirty one-off projects, which is
sort of the opposite of what Ada is about, and it's interpreted so it will
never perform as well as a traditional compiled language.

Re: Practicalities of Ada for app development

[i3text]

On Friday, June 8, 2012 1:48:40 PM UTC-7, wrp wrote:
> ...If I'm targeting x86-64 (and possibly ARM) is GNAT the
> only compiler option I have?

From what information I can find, it appears that GNAT really is the only Ada compiler (free or paid) that targets the x86-64 architecture. Please correct me if I'm wrong.

I see that in addition to Windows/OS X/Linux on x86-64, GNAT can also be used to target *BSD, Solaris, .Net, JVM, and Android/ARM. 

Well, that has me covered.

Re: Practicalities of Ada for app development

[Vadim Godunko]

> 
> 4. How about production quality, open source libraries for things like
> Unicode support, sockets, network communication, GUIs, etc? The stuff
> at www.dmitry-kazakov.de looks good, but most of what I have seen
> online is from the 1980s and pretty rough to begin with.
> 
Unicode support (and much more) can be found in Matreshka [1].

Cross-platform GUI can be implemented with QtAda [2].

[1] http://forge.ada-ru.org/matreshka
[2] http://www.qtada.com/

Re: Practicalities of Ada for app development

[i3text]

On Saturday, June 9, 2012 2:36:13 AM UTC-7, Dmitry A. Kazakov wrote:
> On Sat,  9 Jun 2012 11:25:05 +0200 (CEST), Nomen Nescio wrote:
> > The string library is feature-poor, so you'll find yourself writing basic
> > libraries for constructs that are included in many languages.
> 
> The constructs which should probably be forbidden in first place. It is
> amazing to see what programmers usually write in C++ or C# when faced
> trivial problems of parsing some simple input.

One of my primary concerns is handling UTF-8, UTF-32, and arbitrary local encodings. The two models I'm familiar with are the Unicode-aware approach of Python 3 and the strings-as-binaries approach of Erlang. What are the major differences between C and Ada in how you must approach Unicode text processing?

Re: Practicalities of Ada for app development

[Nomen Nescio]

Adam Beneschan <adam@irvine.com> wrote:
> 
> there are existing libraries to do such things in Ada.  I think
> Vadim Godunko has a regular expression matcher

Any high-level language can be expanded with libraries.  This
capability doesn't offer a means to claim that the language itself is
good for all problems.

One project might use Bob's String Parsing Machine (tm), while another
project becomes dependant on Vadim's Regex Swiss Army Knife (tm).  So
you have the wheel reinvented in multiple styles, and developers who
cannot count on homogeneous interfaces being available as they move
from one project to the next.  OTOH, you can count on developers to
know the language.  IOW, what would otherwise be common knowledge
becomes tribal knowledge - knowledge that's lost with turnover.  And
libs that are not held to the same standards and verification as the
compiler.

Re: Practicalities of Ada for app development

[Nomen Nescio]

Fritz Wuehler <fritz@spamexpire-201206.rodent.frell.theremailer.net> wrote:

> Nomen Nescio <nobody@dizum.com> wrote:
> 
> > > The length of time it takes to write a program isn't a valid metric.
> > 
> > Of course it is.  It's an accurate measure of the expressive power of
> > a language for the task at hand.
> 
> It isn't a metric that's useful to people who write Ada

You can replace "Ada" with any particular language, and the metric is
not useful to anyone where the language has already been decided on.

A metric can only be useful when using it for the right purpose.

> since it doesn't account for things like performance,
> maintainability, and most of all, correctness.

A single metric that captures many attributes is too blunt to be
useful for making engineering decisions.  Taking separate metrics,
each with a strong correlation to an attribute will give more useable
results.  

Metric's for expressive power are useful for comparing the languages
fitness for a particular purpose.  E.g. if the purpose is filtering
e-mail, it would be foolish to neglect to consider the language that
probably has the single most expressive power for that kind of job
(the procmail language).  The language was in fact specially designed
just for that purpose.

> > I do not accept your idea that expressive power is inversely
> > proportional to maintainability, which is essentially what you're
> > trying to imply.  Makes no sense.  You can have your cake, and eat it
> > too.  
> 
> In practice that doesn't seem to happen very often and  Perl is not an
> argument for that view, quite the contrary.

Perl has nothing to do with the thesis you're trying to address.  Perl
was merely part of an example illustrating a different point that I
was making earlier.

Re: Practicalities of Ada for app development

[Adam Beneschan]

On Tuesday, June 12, 2012 2:12:53 PM UTC-7, Nomen Nescio wrote:
> Adam Beneschan wrote:
> > 
> > there are existing libraries to do such things in Ada.  I think
> > Vadim Godunko has a regular expression matcher
> 
> Any high-level language can be expanded with libraries.  This
> capability doesn't offer a means to claim that the language itself is
> good for all problems.
> 
> One project might use Bob's String Parsing Machine (tm), while another
> project becomes dependant on Vadim's Regex Swiss Army Knife (tm).  So
> you have the wheel reinvented in multiple styles, and developers who
> cannot count on homogeneous interfaces being available as they move
> from one project to the next.  OTOH, you can count on developers to
> know the language.  IOW, what would otherwise be common knowledge
> becomes tribal knowledge - knowledge that's lost with turnover.  And
> libs that are not held to the same standards and verification as the
> compiler.

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.  

                          -- Adam

Re: Practicalities of Ada for app development

[Shark8]

On Tuesday, June 12, 2012 7:04:07 PM UTC-5, Adam Beneschan wrote:
> On Tuesday, June 12, 2012 2:12:53 PM UTC-7, Nomen Nescio wrote:
> > Adam Beneschan wrote:
> > > 
> > > there are existing libraries to do such things in Ada.  I think
> > > Vadim Godunko has a regular expression matcher
> > 
> > Any high-level language can be expanded with libraries.  This
> > capability doesn't offer a means to claim that the language itself is
> > good for all problems.
> > 
> > One project might use Bob's String Parsing Machine (tm), while another
> > project becomes dependant on Vadim's Regex Swiss Army Knife (tm).  So
> > you have the wheel reinvented in multiple styles, and developers who
> > cannot count on homogeneous interfaces being available as they move
> > from one project to the next.  OTOH, you can count on developers to
> > know the language.  IOW, what would otherwise be common knowledge
> > becomes tribal knowledge - knowledge that's lost with turnover.  And
> > libs that are not held to the same standards and verification as the
> > compiler.
> 
> 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.  
> 
>                           -- Adam

Good idea.
However, if it's a package devoted to text manipulation then we might want to use ropes rather than strings [ http://en.wikipedia.org/wiki/Rope_%28computer_science%29 ] and provide a To_String ana To_Unbounded_String functions. {I am assuming that it'll be a load-string, do-all-processing, store cycle with as few load/stores as possible.}

If it's allowed in 2012 perhaps something like:

GENERIC
   Use_Ropes : Boolean:= True
PACKAGE Text_Possessing is
--...
END Text_Possessing;

WITH Rope_Implementation, String_Implementation;
PACKAGE BODY Text_Possessing is
 Use (if Use_Ropes then Rope_Implementation else String_Implementation);
--...
END Text_Possessing;

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

> What are the major differences between C and Ada in how you must approach
> Unicode text processing?

No differences:

1. Read the input
2. Recode it into the format most useful for the application
3. Do whatever processing in that format
4. When output is needed, recode back

The best choice, at least for compiler writing and GUI text editors is IMO
UTF-8.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Tue, 12 Jun 2012 20:04:35 -0700 (PDT), Shark8 wrote:

> However, if it's a package devoted to text manipulation then we might want 
> to use ropes rather than strings

Rope is an implementation of string that uses certain internal
representation.

Similarly, encoding is an implementation of two interfaces one of which an
array of code points another is an array of storage or stream elements.

There is no need in any libraries to be cut and paste for each of the
infinite combination of string representations x implementation x code
point constraints x bounds constraints etc. It is insanity.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Wed, 13 Jun 2012 02:04:07 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
> Maybe this should be a challenge to the Ada community to come up with  
> some common package specification

I was wondering some days ago, if that already exist.

What's appealing in your idea, is the reference to specifications, not  
implementations. We should indeed focus on common specifications, above  
common libraries.

While I hardly believe a specification could match every one's style  
convention and every one's common patterns. Even such a simple thing as  
wither or not to use a “_Type” suffix on type names did not get an  
unanimously approved answer (remember previous talks here on c.l.a on the  
subject).

So indeed, this may be specifications instead of libraries, and there may  
also be two of three (probably more) specifications set for a given area.

Not a piece of cake.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Georg Bauhaus]

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.

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 13.06.12 10:37, Georg Bauhaus wrote:

> For example, given (ABC|BCD)E, and a function "&" returning
> a pattern type,
> 
>   Alternation'(To_Set ("ABC") & To_Set ("BCD"))
>      & To_Pattern ("E");

Correction:
   Alternation'(To_Pattern ("ABC") & To_Pattern ("BCD"))

Re: Practicalities of Ada for app development

[quiet_lad]

On Jun 8, 2:35 pm, Jeffrey Carter <spam.jrcarter....@spam.not.acm.org>
wrote:
> On 06/08/2012 01:48 PM, wrp wrote:
>
>
>
> > 1. To begin with, I've heard it said that Ada, designed for embedded
> > system building, is simply not suited to apps for a general computing
> > platform. That's rather vague and I haven't seen any detailed
> > justification of that claim. What would you say?
>
> I would say everything you've heard is wrong. Ada is a general-purpose language
> that has been used successfully in every application domain. Ada is the language
> of choice for S/W that must be correct. Since I want all my S/W to be correct, I
> always use Ada. Examples of small Ada applications I've written include one to
> choose the signature (like the one at the end of this message), one to choose
> the sound to be played next time I log in (next time it will say, "What is your
> favorite color?"), and one to display a quote in a dialog window (today's is,
> "If you think you got a nasty taunting this time, you ain't heard nothing
> yet!"). There seems to be a theme there.
>
> A larger application is the Mine Detector game
> (http://pragmada.x10hosting.com/mindet.html).
>
> At work we have a large, concurrent, distributed, soft-real-time, web-accessible
> call-center application, but large parts of it do DB access and things that
> would be common in the kind of applications you want to make.
>
> > 2. I don't need tools to be free, but they have to be affordable to a
> > small shop. If I'm targeting x86-64 (and possibly ARM) is GNAT the
> > only compiler option I have?
>
> RR Software's Janus/Ada (for Windows) is reasonably priced. You might also look
> at Atego.
>
> Note that most compiler are for Ada 95. Only 3 of 7 compilers I'm aware of
> support the entire language in the current standard (published in 2007). GNAT is
> the only compiler I'm aware of that supports features from the next standard
> (hopefully published this year).
>
> Ada 95 is a very good language, so that might not be a concern. (Even Ada 83 is
> a better language than most of the competition.)
>
> > 3. How about the quality and availablity of supporting tools like
> > debuggers and profilers?
>
> One nice thing about Ada is not needing to use a debugger.
>
> > 4. How about production quality, open source libraries for things like
> > Unicode support, sockets, network communication, GUIs, etc? The stuff
> > atwww.dmitry-kazakov.delooks good, but most of what I have seen
> > online is from the 1980s and pretty rough to begin with.
>
> There are plenty of libraries available. You can find many through adaic.org.
>
> > 5. How well is incremental development supported? I'm thinking of
> > things like modular compiling and speed of the edit-compile-test
> > cycle.
>
> Unlike C, Ada has modules ("packages"). With them, stubs, and separate
> compilation, incremental development is supported well.
>
> > 6. Size and latency are sometimes an issue. I've heard that since GNAT
> > is oriented to building larger systems, the executables it produces
> > are comparatively bulky. What is the situation relative to C in that
> > regard?
>
> As I've said, everything you've heard is wrong. Equivalent programs in Ada and C
> create executables of about the same size using gcc (the key word is
> "equivalent"). Robert Dewar of AdaCore claims to have a collection of equivalent
> Ada and C programs that produce identical object code using gcc.
>
> > 7. What advanced tutorial material is there for using Ada in this way?
> > Say that I have Norman Cohen's _Ada as a Second Language_. What more
> > advanced material is available on subjects other than concurrency,
> > distributed processing, or real-time systems? On a related note, what
> > projects would you recommend looking at as examples of great code?
>
> Cohen is a pretty good book; I'm not sure that you need anything else. Note that
> even small applications can sometimes benefit from concurrency. Since Ada
> tasking is high-level and safe, it would a mistake not to learn about it so you
> can use it when warranted. Barne's book is a good choice. You might want to look
> at "Ada Distilled" by Richard Riehle. Again, adaic.org has a list of texts and
> tutorials.
>
> --
> Jeff Carter
> "When Roman engineers built a bridge, they had to stand under it
> while the first legion marched across. If programmers today
> worked under similar ground rules, they might well find
> themselves getting much more interested in Ada!"
> Robert Dewar
> 62
>
> --- Posted via news://freenews.netfront.net/ - Complaints to n...@netfront.net ---

roman quote best this year!!!
wow is ada really even awesome for web?
watch out ruby!!
as unix admin I love idea of safety and correctness...

Re: Practicalities of Ada for app development

[quiet_lad]

On Jun 9, 2:36 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sat,  9 Jun 2012 11:25:05 +0200 (CEST), Nomen Nescio wrote:
> > wrp <i3t...@gmail.com> wrote:
>
> >> I develop small to medium sized tools. Tasks are mostly limited to
> >> text processing, database management, and simple visualization.
>
> > Ada is lousy for text/string manipulation.
>
> Which is good, because there practically is no task, which required text
> string manipulation. You should parse strings in place without moving
> anything except the cursor. The same applies to the formatted output.
>
> > The string library is feature-poor, so you'll find yourself writing basic
> > libraries for constructs that are included in many languages.
>
> The constructs which should probably be forbidden in first place. It is
> amazing to see what programmers usually write in C++ or C# when faced
> trivial problems of parsing some simple input.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

I am curious about this: how parse string in place etc?
What about say web apps?

Re: Practicalities of Ada for app development

[quiet_lad]

On Jun 9, 9:09 am, tmo...@acm.org wrote:
> >Ada is lousy for text/string manipulation.  Although I'm an Ada
> >enthusiast, I cannot think of a worse language in this regard.
>
>   Speak for yourself.  I find it easy to do text processing in Ada,
> given a few home-grown library routines.  But having written compilers
> in both Fortran and COBOL, perhaps my standards aren't up to your level.

Do you open source such routines?

Re: Practicalities of Ada for app development

[quiet_lad]

On Jun 10, 8:49 am, Shark8 <onewingedsh...@gmail.com> wrote:
> On Saturday, June 9, 2012 4:25:05 AM UTC-5, Nomen Nescio wrote:
>
> > Ada is (by design) a safe language.  But the side effect is that
> > strings are arrays of characters and the developer is forced to be
> > mindful of boundaries.. bogged down with detail.
>
> And yet, if we were not mindful of [array] bounds, we would be screaming at all the times using strings caused a buffer-overflow.
>
> There are ways to "work around" the problem, like the reading long/variable-length strings piece-at-a-time and constructing the result inside a function. (Using recursion:http://www.adapower.com/index.php?Command=Class&ClassID=Basics&CID=202)
>
> That said, there are languages that are made for text processing, SNOBOL [IIRC] is one such language. (Also, I think there's an Ada port of the SPITBOL macros as part of the GNAT-specific packages.) Ironically, most of them aren't used in the mainstream of software development which tends to fall back on C's string manipulation [style of] functions or Regex (which is horrible if you look at Regex from a maintenance perspective.).

How handle the strings without regex?

Re: Practicalities of Ada for app development

[quiet_lad]

On Jun 10, 12:47 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 10 Jun 2012 19:04:02 +0200, Yannick Duchêne (Hibou57) wrote:
> > Le Sun, 10 Jun 2012 17:49:40 +0200, Shark8 <onewingedsh...@gmail.com> a
> > écrit:
> >> Ironically, most of them aren't used in the mainstream of software
> >> development which tends to fall back on C's string manipulation [style
> >> of] functions or Regex (which is horrible if you look at Regex from a
> >> maintenance perspective.).
>
> > If Regular Expressions appears as is, as literals in the program, yes,
> > that's a maintenance nightmare. But you may decompose the expressions,
> > build them incrementally (I use to do it with Python), or even fork to
> > something similar which could use objects and structures instead of
> > unreadable literal expressions (I don't one, just an idea).
>
> That does not change the fact that SNOBOL patterns are far more powerful
> (the language generated is of a much wider class), much more readable. The
> problems are that any patterns are unmaintainable unless trivial. Trivial
> patterns require no special means. Another problem is not in having pattern
> as an object. This is well possible in Ada. The actual problem is to have a
> pattern matching construct in the language. You need something like
>
>    match Variable in Stream by Pattern do
>        ...
>    end match;
>
> which would initialize Variable or set of variables by matched parts of the
> Pattern while advancing Stream while the pattern is matched. It is very
> difficult to describe in a structured manner. The way SNOBOL handles that
> is total mess. Variables are specified in the pattern. Success and failure
> are just labels etc. It is not worth the efforts to bother about that,
> because, as I said, patterns is a bad idea in general.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

What does one do then with say 1000 websites on 1 web appserver? If
not use patterns?

Re: Practicalities of Ada for app development

[Maciej Sobczak]

On 13 Cze, 12:31, quiet_lad <gavcom...@gmail.com> wrote:

> How handle the strings without regex?

I see you insist very much on having support for regexps, but there is
something that bothers me about the way they are typically
implemented.
Programs that use regexps *usually* have them coded statically. The
run-time loading of regexp patterns is very rare. The problem with
static patterns is that they are anyway processed at run-time (they
are somehow analyzed at runtime and some internal representation is
*dynamically* created in memory that later helps in processing the
subject strings), meaning that every time the program is run, the same
"statically" coded pattern has to be analyzed and the structure has to
be constructed from scratch. That is, there is some conceptual
mismatch and potentially lost optimization opportunity, due to the
fact that we go from something that is known statically to something
that has a run-time nature. This is just counterproductive.

I would rather ask about an external tool that can take my regexp
pattern and generate the *static* code structure that processes input
strings accordingly. Such a generated code can be then included in the
final application just like IDL-generated serializers are used. The
advanta of such approach is that there is no tradeoff between regexp
analysis speed vs. string processing speed and there is no time wasted
on analyzing the same pattern many times.

In short: in a typical application (whether this is web service or
something else) you don't need regexp support in the language; you
need regexp processor code generator.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Wed, 13 Jun 2012 03:28:41 -0700 (PDT), quiet_lad wrote:

> I am curious about this: how parse string in place etc?

http://www.dmitry-kazakov.de/ada/components.htm#Parsers_etc

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Wed, 13 Jun 2012 03:35:05 -0700 (PDT), quiet_lad wrote:

> What does one do then with say 1000 websites on 1 web appserver? If
> not use patterns?

Especially in such cases. Pattern matching (even RE) is a very expensive
thing, eats lot of resources.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Shark8]

On Wednesday, June 13, 2012 3:21:04 AM UTC-5, Dmitry A. Kazakov wrote:
> On Tue, 12 Jun 2012 20:04:35 -0700 (PDT), Shark8 wrote:
> 
> > However, if it's a package devoted to text manipulation then we might want 
> > to use ropes rather than strings
> 
> Rope is an implementation of string that uses certain internal
> representation.

Right; perhaps I should have been more correct and said "character array"-based stings.

> 
> Similarly, encoding is an implementation of two interfaces one of which an
> array of code points another is an array of storage or stream elements.
> 
> There is no need in any libraries to be cut and paste for each of the
> infinite combination of string representations x implementation x code
> point constraints x bounds constraints etc. It is insanity.
 
Who said anything about using an infinitude of implementations? The array-based one is good for most short/simple string handling; but it's rather unsuitable for add-/delete-operation intensive tasks (on large-data) such as, say, a word-processor.

And given the very reasonable assumption that some data using a string[-and-pattern?]-manipulation package intends to do many such operations it behooves us to use an implementation conducive to the operations we will be performing.

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Wed, 13 Jun 2012 11:21:10 -0700 (PDT), Shark8 wrote:

>> Similarly, encoding is an implementation of two interfaces one of which an
>> array of code points another is an array of storage or stream elements.
>> 
>> There is no need in any libraries to be cut and paste for each of the
>> infinite combination of string representations x implementation x code
>> point constraints x bounds constraints etc. It is insanity.
>  
> Who said anything about using an infinitude of implementations?

The language forces this, because Ada is incapable to abstract
implementation from the interface in many cases. Array interface is among
them.

> The
> array-based one is good for most short/simple string handling; but it's
> rather unsuitable for add-/delete-operation intensive tasks (on
> large-data) such as, say, a word-processor.

Word processor does not operate strings, it does text buffers. Ropes are
not good for text buffers.

> And given the very reasonable assumption that some data using a
> string[-and-pattern?]-manipulation package intends to do many such
> operations it behooves us to use an implementation conducive to the
> operations we will be performing.

I don't see much use in string manipulation and even less in patterns.
Again, it is almost impossible to find cases where manipulation or patterns
were usable. Only very specialized patterns have any use.

But the major obstacle is that such library is impossible to develop in a
generic way to make it working for a cloud of classes of string types
taking into account variations I have described. There is a huge number of
such types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Wed, 13 Jun 2012 21:11:04 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 13 Jun 2012 11:21:10 -0700 (PDT), Shark8 wrote:
>
>>> Similarly, encoding is an implementation of two interfaces one of  
>>> which an
>>> array of code points another is an array of storage or stream elements.
>>>
>>> There is no need in any libraries to be cut and paste for each of the
>>> infinite combination of string representations x implementation x code
>>> point constraints x bounds constraints etc. It is insanity.
>>
>> Who said anything about using an infinitude of implementations?
>
> The language forces this, because Ada is incapable to abstract
> implementation from the interface in many cases. Array interface is among
> them.

You know, you can define an ADT with array behavior.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[quiet_lad]

On Jun 13, 6:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 13 Jun 2012 03:35:05 -0700 (PDT), quiet_lad wrote:
> > What does one do then with say 1000 websites on 1 web appserver? If
> > not use patterns?
>
> Especially in such cases. Pattern matching (even RE) is a very expensive
> thing, eats lot of resources.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

so what does one do? how do you match say name based virtual hosts on
aws?

Re: Practicalities of Ada for app development

[quiet_lad]

On Jun 13, 5:57 am, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 13 Cze, 12:31, quiet_lad <gavcom...@gmail.com> wrote:
>
> > How handle the strings without regex?
>
> I see you insist very much on having support for regexps, but there is
> something that bothers me about the way they are typically
> implemented.
> Programs that use regexps *usually* have them coded statically. The
> run-time loading of regexp patterns is very rare. The problem with
> static patterns is that they are anyway processed at run-time (they
> are somehow analyzed at runtime and some internal representation is
> *dynamically* created in memory that later helps in processing the
> subject strings), meaning that every time the program is run, the same
> "statically" coded pattern has to be analyzed and the structure has to
> be constructed from scratch. That is, there is some conceptual
> mismatch and potentially lost optimization opportunity, due to the
> fact that we go from something that is known statically to something
> that has a run-time nature. This is just counterproductive.
>
> I would rather ask about an external tool that can take my regexp
> pattern and generate the *static* code structure that processes input
> strings accordingly. Such a generated code can be then included in the
> final application just like IDL-generated serializers are used. The
> advanta of such approach is that there is no tradeoff between regexp
> analysis speed vs. string processing speed and there is no time wasted
> on analyzing the same pattern many times.
>
> In short: in a typical application (whether this is web service or
> something else) you don't need regexp support in the language; you
> need regexp processor code generator.
>
> --
> Maciej Sobczak *http://www.msobczak.com*http://www.inspirel.com

I do not insist.  I just see regex used and am amazed there is
alternative.  I am also glad there is one.

Re: Practicalities of Ada for app development

[Ludovic Brenta]

quiet_lad wrote on comp.lang.ada:
> I do not insist.  I just see regex used and am amazed there is
> alternative.  I am also glad there is one.

Apart from Ada.Strings.Fixed.Index and Ada.Fixed.Strings.Find_Token,
the language does not impose any serious pattern matching.  However
GNAT comes bundled with both regular expression (GNAT.Regexp) and
SNOBOL4 pattern matching engines (GNAT.SPITBOL.Patterns).

As Maciej rightly pointed out, regular expressions must be compiled
at run time (GNAT.Regexp.Compile).  One place where I used GNAT.Rexegp
long ago is in the regexp-based spam filter I wrote for myself.  It
reads regular expressions defining spam from my ~/.emacs file,
compiles each in turn and applies the filter to incoming mail
retrieved from a POP3 server.

http://www.ada-france.org:8081/branch/changes/org.ludovic-brenta.spamkiller

--
Ludovic Brenta.

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Wed, 13 Jun 2012 20:21:26 -0700 (PDT), quiet_lad wrote:

> On Jun 13, 6:09�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Wed, 13 Jun 2012 03:35:05 -0700 (PDT), quiet_lad wrote:
>>> What does one do then with say 1000 websites on 1 web appserver? If
>>> not use patterns?
>>
>> Especially in such cases. Pattern matching (even RE) is a very expensive
>> thing, eats lot of resources.

> so what does one do? how do you match say name based virtual hosts on
> aws?

What is the problem? I cannot decipher "match say name based virtual hosts
on aws."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Thu, 14 Jun 2012 00:01:49 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Wed, 13 Jun 2012 21:11:04 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Wed, 13 Jun 2012 11:21:10 -0700 (PDT), Shark8 wrote:
>>
>>>> Similarly, encoding is an implementation of two interfaces one of  
>>>> which an
>>>> array of code points another is an array of storage or stream elements.
>>>>
>>>> There is no need in any libraries to be cut and paste for each of the
>>>> infinite combination of string representations x implementation x code
>>>> point constraints x bounds constraints etc. It is insanity.
>>>
>>> Who said anything about using an infinitude of implementations?
>>
>> The language forces this, because Ada is incapable to abstract
>> implementation from the interface in many cases. Array interface is among
>> them.
> 
> You know, you can define an ADT with array behavior.

I made my point about *array interface*.

Encoding/representation issues require multiple array interfaces
implemented by the same type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Thu, 14 Jun 2012 09:58:10 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Wed, 13 Jun 2012 20:21:26 -0700 (PDT), quiet_lad wrote:
>
>> On Jun 13, 6:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>> On Wed, 13 Jun 2012 03:35:05 -0700 (PDT), quiet_lad wrote:
>>>> What does one do then with say 1000 websites on 1 web appserver? If
>>>> not use patterns?
>>>
>>> Especially in such cases. Pattern matching (even RE) is a very  
>>> expensive
>>> thing, eats lot of resources.
>
>> so what does one do? how do you match say name based virtual hosts on
>> aws?
>
> What is the problem? I cannot decipher "match say name based virtual  
> hosts
> on aws."
>

Web addresses have a domain name and a TLD, like in adalog.fr. The server  
is reached via DNS request returning the IP addresse for the domain. Web  
addresses may also have subdomains. An example could be archive.adaic.com.  
“archive”, is a subdomain of adaic.com. To reach the subdomain, you have  
to contact the server at the IP address associated to the domain  
adaic.com. That means archive.adaic.com has the same IP address as  
adaic.com. The same goes for any other subdomain like news.mysite.net,  
forum.mysite.net, wiki.mysite.net and so on, all reached via mysite.net's  
IP.

Now, they may be multiple way to associate a subdomain to a server. The  
most typical one for tiny to medium traffic, is to make a server handle  
the domain and all of its subdomains.

When an Apache server handles multiple domains and/or subdomains, these  
are configured as virtual hosts. Each virtual host configuration tells the  
server where to retrieve the document from or what CGI to invoke to return  
a document. This may be indeed done using pattern matching on the URL, but  
that's not one of the hottest use case of RegExp (:-P) .


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Yannick Duchêne (Hibou57)]

Le Thu, 14 Jun 2012 10:02:07 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Thu, 14 Jun 2012 00:01:49 +0200, Yannick Duchêne (Hibou57) wrote:
>
>> Le Wed, 13 Jun 2012 21:11:04 +0200, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>
>>>> Who said anything about using an infinitude of implementations?
>>>
>>> The language forces this, because Ada is incapable to abstract
>>> implementation from the interface in many cases. Array interface is  
>>> among
>>> them.
>>
>> You know, you can define an ADT with array behavior.
>
> I made my point about *array interface*.
>
> Encoding/representation issues require multiple array interfaces
> implemented by the same type.

Unless I don't understand your point, define facades.

If I don't understand your point, give an example.

Side note: sometime I feel you expect too much generalization from Ada.  
What I don't like with over‑generalization, is that it makes all idioms  
looks the same, which in turn makes their occurrences less distinct and  
visible.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Thu, 14 Jun 2012 10:39:49 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Thu, 14 Jun 2012 09:58:10 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> On Wed, 13 Jun 2012 20:21:26 -0700 (PDT), quiet_lad wrote:
>>
>>> On Jun 13, 6:09 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>> wrote:
>>>> On Wed, 13 Jun 2012 03:35:05 -0700 (PDT), quiet_lad wrote:
>>>>> What does one do then with say 1000 websites on 1 web appserver? If
>>>>> not use patterns?
>>>>
>>>> Especially in such cases. Pattern matching (even RE) is a very  
>>>> expensive
>>>> thing, eats lot of resources.
>>
>>> so what does one do? how do you match say name based virtual hosts on
>>> aws?
>>
>> What is the problem? I cannot decipher "match say name based virtual  
>> hosts
>> on aws."
>>
> 
> Web addresses have a domain name and a TLD, like in adalog.fr. The server  
> is reached via DNS request returning the IP addresse for the domain. Web  
> addresses may also have subdomains. An example could be archive.adaic.com.  
> “archive”, is a subdomain of adaic.com. To reach the subdomain, you have  
> to contact the server at the IP address associated to the domain  
> adaic.com. That means archive.adaic.com has the same IP address as  
> adaic.com. The same goes for any other subdomain like news.mysite.net,  
> forum.mysite.net, wiki.mysite.net and so on, all reached via mysite.net's  
> IP.

I still see no problem stated. Maybe maps or suffix tree (I am guessing).
Certainly not patterns.

The rule of thumb for patterns: they are used exclusively as the user
input, when he is asked to specify some set of string.

Patterns should never be used internally, because there always exist a
better method of handling a set of strings, since almost always the set of
strings from the problem domain is different from the formal language of
the patterns. Either it is stronger and patterns simply do not work, or it
weaker and thus patterns become too inefficient compared to specific
methods. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Dmitry A. Kazakov]

On Thu, 14 Jun 2012 11:10:39 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Thu, 14 Jun 2012 10:02:07 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> On Thu, 14 Jun 2012 00:01:49 +0200, Yannick Duch�ne (Hibou57) wrote:
>>
>>> Le Wed, 13 Jun 2012 21:11:04 +0200, Dmitry A. Kazakov
>>> <mailbox@dmitry-kazakov.de> a �crit:
>>>
>>>>> Who said anything about using an infinitude of implementations?
>>>>
>>>> The language forces this, because Ada is incapable to abstract
>>>> implementation from the interface in many cases. Array interface is  
>>>> among
>>>> them.
>>>
>>> You know, you can define an ADT with array behavior.
>>
>> I made my point about *array interface*.
>>
>> Encoding/representation issues require multiple array interfaces
>> implemented by the same type.
> 
> Unless I don't understand your point, define facades.
> 
> If I don't understand your point, give an example.

The example was given: UTF-8 string. It shall implement the interface of an
array of Wide_Wide_Character (code points), the interface of an array of
octets (encoding layer). Further interfaces are at your choice.

> Side note: sometime I feel you expect too much generalization from Ada.

I expect from Ada a type system which would not force me to bend design,
with as much static checks as possible.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Practicalities of Ada for app development

[Georg Bauhaus]

On 14.06.12 09:35, Ludovic Brenta wrote:

> As Maciej rightly pointed out, regular expressions must be compiled
> at run time (GNAT.Regexp.Compile).

Before putting much emphasis on having to compile RE patterns
at run-time, I suggest considering what the cost actually is,
in use cases of substantial relevance.

Some use cases for pattern matching:

1) [static, special] Highest possible efficiency of matching
methods is desired in terms of both time and space. For example,
for some FPGA, or for a program that is started and run many many
times per second in limited environments.

I bet there is money for funding this kind of approach in its
market. Looks like it has been done.
Not sure that this approach should be the goal of an Ada package
for general use.

2) [source text] A convenient and effective method of
specifying regular languages in source is desired, to meet
the needs of ubiquitous applications.
For example, finding sequences of digits in date strings
to be split apart (strings from data bases, user input, documents);
matching parts of URLs REs such as file name patterns,
or hashed session identifiers; finding good bits in white noise.

3) [external] Regular expressions are external to
the program. As is the case for configuration files,
when using shells, when "programming" mail filters,
etc.

So, we have static, (1) specialized REs, 82) REs in source text
(either static or dynamic), and (3) REs external to the program.

In case 3, the program *must* be capable of compiling,
or otherwise processing, the external RE.

In case 2, the fraction of time spent on compiling
plain REs is very likely a small fraction of the programs'
running times, especially of server programs' running times.

In case 1, the cost of the alternatives mentioned
do not seem to be negligible at all. That is, the cost of
maintaining a bulky extra parser for some regular language,
or the cost of integrating a source generator that produces
automata.


It is worth mentioning that the source code "generator"
built into C++'s template system can achieve some of the
desired effects for static REs.

Re: Practicalities of Ada for app development

[Nomen Nescio]

> Metric's for expressive power are useful for comparing the languages
> fitness for a particular purpose. 

I don't agree. Expressive power is useful for comparing the /ease/ of
applying the language for a particular purpose. Domain specific languages
are always easy to apply to the problem domain, by definition. But that is
not the whole story. How easy it is to apply the language to solving a
particular problem doesn't take into account other possibly overriding
factors like maintainability, performance, etc. In other words, just because
it's easy to code a particular solution in a certain language doesn't mean
that language is ideal or even good for that solution in other respects.
Domain specific languages are often lacking in industrial strength features,
and are best for prototyping or programming in the small.

To take your point to the extreme, Perl and most other modern scripting
languages would never have had to be written, since SNOBOL4 from the late
sixties is more expressive and powerful than those new languages. But we see
there are other overriding concerns like facilities to handle large source
projects, the ability to employ namespaces, and other aspects of the newer
scripting languages that trade off the power and expressiveness of SNOBOL4
for modern management features and OO constructs, etc.

> E.g. if the purpose is filtering e-mail, it would be foolish to neglect to
> consider the language that probably has the single most expressive power
> for that kind of job (the procmail language).  The language was in fact
> specially designed just for that purpose.

SNOBOL4 can filter better than any language I have seen. If you're not happy
with that, most modern scripting languages have regexp facilities. What
makes one better than the other? There are other factors that lead us to
choose this or that language, and ease of application is helpful but not
essential. What's essential is a correct, serviceable solution that performs
adequately.

As long as a baseline functionality to get the job done exists in your
solution set of languages, you should consider other features that make
writing and maintaining good code easier. 

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:jqur16$teu$1@adenine.netfront.net...
> On 06/08/2012 05:40 PM, Adam Beneschan wrote:
>> On Friday, June 8, 2012 2:35:55 PM UTC-7, Jeffrey Carter wrote:
>>
>>> One nice thing about Ada is not needing to use a debugger.
>>
>> I don't get this comment.  Ada is a lot nicer than some languages at
>> preventing you from making certain kinds of mistakes, but no language is 
>> able
>> to prevent logic errors and certain dumb typos.  And if you make this 
>> kind of
>> error and the program doesn't work, just the fact of its being written in 
>> Ada
>> doesn't help you much.  There may less need for a debugger because Ada 
>> will
>> prevent certain types of errors and things like constraint checks will 
>> catch
>> some others that would cause havoc in C.  But it can't catch everything, 
>> and
>> even if it does find an index that's out of range it won't tell you why 
>> the
>> index was out of range.  I mean, Ada is a much better language than 
>> certain
>> others for writing correct code, but this seems like a gross 
>> overstatement.
>
> I haven't used a debugger for a long time. Usually Ada gives an idea of 
> the kind of error and its location, and I can easily figure out what the 
> problem is. In the rare case that that isn't true, it's quicker to stick 
> in a few Put_Lines than to learn to use the debugger again. This is a 
> self-reinforcing situation, of course.

I tend to be with Jeff on this one. I sometimes use a debugger to figure out 
low-level problems in generated code (that is, to find compiler bugs), but 
that's pretty much it. (And I admit that the quality of our debugger has 
suffered because I don't use it enough to want to spend the time to improve 
it.)

Almost all of my programs include a built-in logging/tracing facility that 
can be controlled interactively (even for batch-oriented tools like our 
compiler), and combined with Ada's checks, that's enough 95% of the time. 
Virtually all of the rest of the time, it's easier to add some new tracing 
to the facility than to figure out how to compile a version of the program 
with debugging information on, get it linked properly, and then remember the 
quirks of the debugger.

Part of the problem is that there are a lot of problems for which a debugger 
will not help. For instance, when tracking down problems in Claw, we had to 
use an off-line logging facility, because adding anything to the program 
window changes the stream of messages, and thus tends to obscure the problem 
that we were trying to locate and fix.

I'm sure the situation is not the same for everyone, but I'm surprised that 
you (Adam) can get much use out of a debugger, since compilers and their 
tools is definitely one case where a debugger is pretty much worthless (the 
only exception being the rare code generation bug).

                                                 Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:7cd5phn5j7lp.ltw3lkjwnjkz.dlg@40tude.net...
>> What are the major differences between C and Ada in how you must approach
>> Unicode text processing?
>
> No differences:
>
> 1. Read the input
> 2. Recode it into the format most useful for the application
> 3. Do whatever processing in that format
> 4. When output is needed, recode back
>
> The best choice, at least for compiler writing and GUI text editors is IMO
> UTF-8.

And Ada 2012 has added libraries which directly support the "recoding" 
Dmitry mentions above.

(And I agree with UTF-8. Ada 2012 finally specifies that all Ada 2012 
compilers have to support source code in UTF-8 format, so we now have a 
standard format for Ada source code. Finally.)

                                           Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:3e8c1c78-31b0-462e-8341-6d661fbc8378@googlegroups.com...
>On Sunday, June 10, 2012 2:36:46 PM UTC-7, Nomen Nescio wrote:
>> "Dmitry A. Kazakov" wrote:
>> >
>> > > Please, why have you defined Code_Point as a modular type?
>> >
>> > Because code point is unsigned. When you declare something signed
>> > you do that because you want negative inverses. Signed integers have
>> > the base type with 0 in the middle of its range.
>>
>> That's no reason to use mod.  You can put boundaries where you want
>> them, integer, or mod.
>
>This isn't quite true because of subtleties of the language.  When you 
>define an  integer "type" with
> range 0..(2**32-1), the *type* you declare is actually a larger type than 
> that.  It has to be at least
> -(2**32-1) .. (2**32-1), which is a type that requires 33 bits (in 
> practice, it will probably be
> -2**64 .. 2**64-1).  You then get a subtype with range 0..(2**32-1).  But 
> some calculations
> have to be done using the base type, which means that using a signed 
> integer type can require
> some extra conversions, and can require additional processing time on a 
> machine that doesn't
> have 64-bit arithmetic instructions.  It probably wouldn't matter much if 
> the type is being used
> to represent a Unicode code point.  But in a more general case, you have 
> to be careful.  It's
> not really accurate to simply say "you can put boundaries where you want".

Right, but the real question here is why is 2**32 being used at all? Unicode 
specifically limits the code points to 2**21 (or something close to that, 
I'm not going to look it up right now); anything beyond that is garbage and 
not allowed in UTF-8 encoding. So the limit of the type ought to be that, 
and (based on the discussion), the numeric operators should be "removed" by 
declaring them abstract. In which case there is no problem using either form 
of declaration.

(If you're keeping the numeric operators, then the form of the declaration 
should be signed, since using mod means you also lose overflow checking --  
and that's almost never what you want.)

                                                  Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]


"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wfrdhbh1ule2fv@douda-yannick...
>Le Mon, 11 Jun 2012 20:29:47 +0200, Adam Beneschan <adam@irvine.com> a 
>�crit:
>> IIRC, some people have proposed adding unsigned integer types to the 
>> language; they've argued that modular types aren't good enough for some 
>> purposes.  But the idea was turned down.
>
>Why?

Why was it turned down? To much complication for to little gain, I think. 
There is a lot of overhead to having a new kind of type in the language (not 
only the type declaration, but also with generic formals, in Text_IO, etc.).

Janus/Ada has always supported unsigned representations of "signed" integer 
types (we did that in Ada 83, before there were modular types). I think most 
compilers do that, in fact. But as Adam says, you can force the signed 
representation in some cases, so for:

    type T is range 0 .. 2**32-1;

you have to support a signed version, which is easy to get -- just use 
T'Base. And for the largest integer representation supported by the compiler 
(32 or 64 or whatever), that's impossible, so Janus/Ada has to reject the 
above declaration. (We don't have general 64-bit integer support.)

                                                Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

"darkestkhan" <darkestkhan@gmail.com> wrote in message 
news:208be215-6db6-4965-8130-7c1daf618342@googlegroups.com...
...
> I know about matreshka - I'm only saying that language itself doesn't 
> support UTF8,
> which is different from `there is no library for handling UTF8 encoded 
> strings`.

Which is definitely False for Ada 2012: package Ada.Strings.Encoding and its 
children support UTF-8 directly. And Ada source code encoded using UTF-8 
*has* to be processed.

                                 Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wfvw0nytule2fv@douda-yannick...
...
>Web addresses have a domain name and a TLD, like in adalog.fr. The server 
>is reached via DNS request returning the IP addresse for the domain. Web 
>addresses may also have subdomains. An example could be archive.adaic.com. 
>"archive", is a subdomain of adaic.com. To reach the subdomain, you have 
>to contact the server at the IP address associated to the domain 
>adaic.com. That means archive.adaic.com has the same IP address as 
>adaic.com. The same goes for any other subdomain like news.mysite.net, 
>forum.mysite.net, wiki.mysite.net and so on, all reached via mysite.net's 
>IP.

Way off topic, but this description is quite wrong. "archive.adaic.com" runs 
on my web server, "adaic.com" runs on AdaCore's web server, and I'm pretty 
sure that AdaCore hasn't taken over my Internet and its IPs!

In fact, the subdomains are included in the DNS just like the domains, and 
can be found (directly) to have any IPs that you might desire. Indeed, 
subdomains are commonly used to direct mail to a different server than web 
traffic, as just one of many possible uses.

Your point was mainly about virtual hosting, which wasn't affected by this. 
(But my web server just does a direct string compare against a list of web 
sites, after the URL is normalized; no fancy pattern matching is used, it 
would be too expensive.)

                                                     Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Nomen Nescio" <nobody@dizum.com> wrote in message 
news:145eefe89c8eae1ef97489ba21b94d63@dizum.com...
...
> Metric's for expressive power are useful for comparing the languages
> fitness for a particular purpose.  E.g. if the purpose is filtering
> e-mail, it would be foolish to neglect to consider the language that
> probably has the single most expressive power for that kind of job
> (the procmail language).  The language was in fact specially designed
> just for that purpose.

I don't know about that -- learning another language adds a significant time 
investment, so special purpose languages have to be amazingly good to have 
any value. (Which they don't, IMHO.)

I wrote my spam filter in Ada (and on my own time, it never was intended to 
be a product), and the text processing was not that much of a problem. 
Indeed, the only real issue was that I refuse to use "use clauses", and thus 
a lot of the expressions became unreadable because of 
"Ada.Strings.Unbounded." everywhere. The less stuborn would not have that 
problem.

I think I spend a lot of time on the GUI, and on the SMTP implementation, 
but not that much on the string manipulation. Which I suspect mainly 
demonstrates that people tend to be the most productive using the tools that 
they are the most familar (and comfortable) with.

                                                   Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:m0g3o1rrco75$.699fudiit3dt$.dlg@40tude.net...
...
> The example was given: UTF-8 string. It shall implement the interface of 
> an
> array of Wide_Wide_Character (code points), the interface of an array of
> octets (encoding layer). Further interfaces are at your choice.

It's not hard to define a Root_String'Class in Ada 2012 that would provide 
all of the interfaces you would expect other than slicing and string 
literals. One can easily imagine extending existing capabilities to provide 
those.

The problem is that if we did that, we'd have to make new versions of every 
existing interface in the Standard (to use Root_String'Class rather than 
String). And that would cause compatibility problems with string literals 
because it wouldn't be clear which type is involved. (We can't get rid of 
the existing types, and we can't make String into a tagged type as that 
would be representation-incompatible, so it cannot be derived from 
Root_String'Class.)

That would be a problem for *any* implementation based on interfaces. I'm 
going to continue to pursue it (because the existing direction for 
internationalization is just one kludge on top of another), but there is no 
guarentee of success.

                                        Randy.

Re: Practicalities of Ada for app development

[Adam Beneschan]

On Thursday, June 21, 2012 10:14:45 AM UTC-7, Randy Brukardt wrote:

> 
> I'm sure the situation is not the same for everyone, but I'm surprised that 
> you (Adam) can get much use out of a debugger, since compilers and their 
> tools is definitely one case where a debugger is pretty much worthless (the 
> only exception being the rare code generation bug).

Well, since I do get a lot of use out of debuggers, the assertion in the second half of your sentence is demonstrably false.  I don't understand it, either.  Why would a compiler, or a compiler's tools, be of such a substantially different nature than other programs, that would make a debugger useful in one situation and useless in another?

So far, there have been at least a couple general assertions on this thread about the uselessness of debuggers (not merely observations based on experience,  but assertions as if it were a matter of fact), but I haven't seen a good explanation why this assertion should be true.  I'm beginning to think that either (1) everyone else's situation is substantially different from mine, or (2) I use debuggers in ways that others aren't used to using, or (3) I use debuggers that have features that aren't present in debuggers that others are used to using.

Maybe we could start by having those who don't think debuggers are useful for Ada answer this: what do you think a debugger would be used for, when it *is* useful?  If your answer to this is a lot smaller then the set of things I think it can be used for, that may help explain why there's such a difference of opinion.

                           -- Adam

Re: Practicalities of Ada for app development

[J-P. Rosen]

Le 21/06/2012 20:16, Adam Beneschan a �crit :

> Well, since I do get a lot of use out of debuggers, the assertion in
> the second half of your sentence is demonstrably false.  I don't
> understand it, either.  Why would a compiler, or a compiler's tools,
> be of such a substantially different nature than other programs, that
> would make a debugger useful in one situation and useless in another?

Here is my typical use case. Sometimes, AdaControl encounters an
unexpected combination of constructs, and generally fails with an Asis
message saying "improper element". The exception message tells me where
it happens, but generally the problem is slightly above, in the query
that produced the invalid value. I just add a trace message at this
query (I also have an integrated trace facility in AdaControl), and
rerun the program.

In general, I get /thousands/ of useless messages (and I can't predict
how many) before the one I'm interested in, that is, the last one before
the crash. I don't care, I just let the screen scroll... How could I do
that in a debugger? A breakpoint, and thousands of useless "go"
commands? No thanks.
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Practicalities of Ada for app development

[Adam Beneschan]

On Thursday, June 21, 2012 12:18:52 PM UTC-7, J-P. Rosen wrote:
> Le 21/06/2012 20:16, Adam Beneschan a écrit :
> 
> > Well, since I do get a lot of use out of debuggers, the assertion in
> > the second half of your sentence is demonstrably false.  I don't
> > understand it, either.  Why would a compiler, or a compiler's tools,
> > be of such a substantially different nature than other programs, that
> > would make a debugger useful in one situation and useless in another?
> 
> Here is my typical use case. Sometimes, AdaControl encounters an
> unexpected combination of constructs, and generally fails with an Asis
> message saying "improper element". The exception message tells me where
> it happens, but generally the problem is slightly above, in the query
> that produced the invalid value. I just add a trace message at this
> query (I also have an integrated trace facility in AdaControl), and
> rerun the program.
> 
> In general, I get /thousands/ of useless messages (and I can't predict
> how many) before the one I'm interested in, that is, the last one before
> the crash. I don't care, I just let the screen scroll... How could I do
> that in a debugger? A breakpoint, and thousands of useless "go"
> commands? No thanks.

Actually, that's a typical case where I find a debugger useful.  At the point where you add the trace message, I set a breakpoint, but set it up so that it continues automatically and doesn't display any message.  Then when the crash occurs, I ask the debugger to display information on the breakpoint, and find that it occurred N times.  Then I rerun the program, and set a breakpoint at that same place, telling the debugger to stop the program after it's hit that place N-1 times.  That way, I can see what's going on just before the crash.  I do that sort of thing quite frequently.  Of course, it only works if you can duplicate the run exactly, which isn't always going to be possible with some nondeterministic programs that depend on external events.

                             -- Adam

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:afa4c8e4-dba8-460c-877b-a848255c4572@googlegroups.com...
On Thursday, June 21, 2012 10:14:45 AM UTC-7, Randy Brukardt wrote:

>>
>> I'm sure the situation is not the same for everyone, but I'm surprised 
>> that
>> you (Adam) can get much use out of a debugger, since compilers and their
>> tools is definitely one case where a debugger is pretty much worthless 
>> (the
>> only exception being the rare code generation bug).
>
>Well, since I do get a lot of use out of debuggers, the assertion in the 
>second half of
>your sentence is demonstrably false.  I don't understand it, either.  Why 
>would a
>compiler, or a compiler's tools, be of such a substantially different 
>nature than other
>programs, that would make a debugger useful in one situation and useless in 
>another?

Perhaps I'm too tied to the design of our compiler, but it is not practical 
to debug any of our compiler passes other than the first. These are all 
separate programs that take a combination of in-memory input and temporary 
files to run. The first pass could be debugged, but there are never any 
errors in that (its just parsing). The few times I've tried to use a 
debugger on the compiler (to track down hard crashes that I couldn't find 
conventionally), I spend hours creating batch files and one-off harnesses in 
order to be able to run it more than once. (And you *always* have to run it 
more than once.)

Every compiler I'm familar with uses a design like that, so it would be 
complicated and painful to debug the later passes where the errors typically 
are.

>So far, there have been at least a couple general assertions on this thread 
>about the
> uselessness of debuggers (not merely observations based on experience, 
> but assertions
> as if it were a matter of fact), but I haven't seen a good explanation why 
> this assertion
> should be true.  I'm beginning to think that either (1) everyone else's 
> situation is substantially
>different from mine, or (2) I use debuggers in ways that others aren't used 
>to using, or (3) I
> use debuggers that have features that aren't present in debuggers that 
> others are used to
> using.

The latter might be the most likely, at least in my case. I've never had any 
luck with any "advanced" features in debuggers; I barely can get the basic 
ones to work. (Our own debugger is an exception, but it doesn't have any 
"advanced" features, so it doesn't change anything.) I've never gotten 
anything to work in any of the modern Microsoft debuggers, for instance; I 
can't even get them to display a memory location. (I use the debugger from 
Windows NT when I have to do that, because at least I can get basic commands 
to work in it.)

> Maybe we could start by having those who don't think debuggers are useful 
> for Ada answer
> this: what do you think a debugger would be used for, when it *is* useful? 
> If your answer to
> this is a lot smaller then the set of things I think it can be used for, 
> that may help explain why
> there's such a difference of opinion.

The only thing I've ever found a debugger useful for is single-stepping 
and/or executing to breakpoints. You have to do that multiple times before 
you hit on the magic incantation that gets you to that part of the program 
that you need to look at. And you can waste so much time attempting to do 
that that most of the time it is much easier to read the trace log from 
directly above the problem (since it is already built-in to the 
application). Plus adding a few traces, recompiling, rerunning, and looking 
at the results will find the bug before I could have even figured out 
exactly where the breakpoint needs to be.

The only time the debugger hassle is worth it is when the bug is 
sufficiently low-level that you can't debug it at the Ada level (as when a 
register has the wrong value for some reason, causing a hardware fault). And 
that usually takes me many hours (usually an entire working day) for a 
single problem, as opposed to dealing with a problem an hour or so at the 
Ada level.

                                Randy. 

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:92daaca1-46ae-43e1-abae-397b4bf6aa33@googlegroups.com...
...
> Actually, that's a typical case where I find a debugger useful.  At the 
> point where you add
> the trace message, I set a breakpoint, but set it up so that it continues 
> automatically and
> doesn't display any message.  Then when the crash occurs, I ask the 
> debugger to display
> information on the breakpoint, and find that it occurred N times.

I've never encountered any debugger that even claimed to have that 
information; I've surely never used one that has any sort of count or other 
information about a breakpoint (other than the address where it is set). 
They just break, period. The fanciest one I've ever heard of allowed 
attaching a boolean expression to the breakpoint, allowing it run until the 
expression is true (our debugger is supposed to have that capability, but it 
doesn't work).

> Then I rerun the program, and set a breakpoint at that same place, telling 
> the debugger
> to stop the program after it's hit that place N-1 times.  That way, I can 
> see what's going
> on just before the crash.  I do that sort of thing quite frequently.

That presumes that you have a debugger that records a pass count (as I said, 
I've never heard of such a thing, and I surely never thought it would be 
useful), AND you know where to put a breakpoint. (Half of the breakpoints I 
sent never get reached; it's really easy to miss and put it into the else 
part or something like that.)

By the time I got the breakpoint set, I probably could have added tracing, 
recompiled (30 seconds at most), relinked, rerun, and examined the output 
log a second time. I'd only come out ahead using a debugger if it took more 
than two iterations to find the bug (probably less than 10% of the cases).

I suppose, like everything, YMMV. (And if I was going to use a debugger with 
any regularity, I'd have to spend 3 man-months fixing ours to be more 
usable -- which I typically add into the expense of using it compared to 
just looking at logs.)

                                         Randy.

Re: Practicalities of Ada for app development

[J-P. Rosen]

Le 21/06/2012 22:30, Adam Beneschan a �crit :

> Actually, that's a typical case where I find a debugger useful.  At
> the point where you add the trace message, I set a breakpoint, but
> set it up so that it continues automatically and doesn't display any
> message.  Then when the crash occurs, I ask the debugger to display
> information on the breakpoint, and find that it occurred N times.
> Then I rerun the program, and set a breakpoint at that same place,
> telling the debugger to stop the program after it's hit that place
> N-1 times.  That way, I can see what's going on just before the
> crash.  I do that sort of thing quite frequently.  Of course, it only
> works if you can duplicate the run exactly, which isn't always going
> to be possible with some nondeterministic programs that depend on
> external events.
So, you have to run the program twice while I need only once. OTOH, once
you have the proper breakpoint, you could investigate more stuff. But in
my case (YMMV), my trace produces enough information, and there is not
much I could get from the debugger (ASIS elements are private types of
the implementation of ASIS - which I don't know, therefore there isn't
much I can learn from browsing them. My trace provides higher level
information)
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Practicalities of Ada for app development

[J-P. Rosen]

Le 21/06/2012 23:00, Randy Brukardt a �crit :
> The only time the debugger hassle is worth it is when the bug is 
> sufficiently low-level that you can't debug it at the Ada level (as when a 
> register has the wrong value for some reason, causing a hardware fault). And 
> that usually takes me many hours (usually an entire working day) for a 
> single problem, as opposed to dealing with a problem an hour or so at the 
> Ada level.
Although I fully agree with you, I can add another use case where a
debugger can be useful: when you enter an infinite loop and you don't
have the foggiest idea where it is - assuming that ^C works, which is
not always the case.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Practicalities of Ada for app development

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Adam Beneschan" <adam@irvine.com> wrote in message 
> news:92daaca1-46ae-43e1-abae-397b4bf6aa33@googlegroups.com...
> ...
>> Actually, that's a typical case where I find a debugger useful.  At
>> the point where you add the trace message, I set a breakpoint, but
>> set it up so that it continues automatically and doesn't display any
>> message.  Then when the crash occurs, I ask the debugger to display
>> information on the breakpoint, and find that it occurred N times.
>
> I've never encountered any debugger that even claimed to have that
> information; I've surely never used one that has any sort of count or
> other information about a breakpoint (other than the address where it
> is set).  They just break, period.

GDB does this.

(gdb) catch exception constraint_error
Catchpoint 1: `constraint_error' Ada exception
(gdb) commands 1
>continue
>end
(gdb) run
[lots of output]
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000100025fd7 `constraint_error' Ada exception
	breakpoint already hit 5 times
        continue

Re: Practicalities of Ada for app development

[Tero Koskinen]

On Fri, 22 Jun 2012 05:59:08 +0100
Simon Wright <simon@pushface.org> wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
> > "Adam Beneschan" <adam@irvine.com> wrote in message 
> > news:92daaca1-46ae-43e1-abae-397b4bf6aa33@googlegroups.com...
> > ...
> >> Actually, that's a typical case where I find a debugger useful.  At
> >> the point where you add the trace message, I set a breakpoint, but
> >> set it up so that it continues automatically and doesn't display any
> >> message.  Then when the crash occurs, I ask the debugger to display
> >> information on the breakpoint, and find that it occurred N times.
> >
> > I've never encountered any debugger that even claimed to have that
> > information; I've surely never used one that has any sort of count or
> > other information about a breakpoint (other than the address where it
> > is set).  They just break, period.
> 
> GDB does this.
> 
> (gdb) catch exception constraint_error
> Catchpoint 1: `constraint_error' Ada exception
> (gdb) commands 1

This "commands" command is also nice. You can define a set of actions
which automatically happen when the breakpoint is triggered.

Another nice feature of recent gdb (7.0) is Python scripting:
http://sourceware.org/gdb/onlinedocs/gdb/Python-Commands.html
http://napsy.wordpress.com/2009/10/11/gdb-7-scripting/


-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: Practicalities of Ada for app development

[Tero Koskinen]

On Thu, 21 Jun 2012 13:30:18 -0700 (PDT)
Adam Beneschan <adam@irvine.com> wrote:

> On Thursday, June 21, 2012 12:18:52 PM UTC-7, J-P. Rosen wrote:
> > In general, I get /thousands/ of useless messages (and I can't predict
> > how many) before the one I'm interested in, that is, the last one before
> > the crash. I don't care, I just let the screen scroll... How could I do
> > that in a debugger? A breakpoint, and thousands of useless "go"
> > commands? No thanks.
> 
> Actually, that's a typical case where I find a debugger useful.  At the point where you add the trace message, I set a breakpoint, but set it up so that it continues automatically and doesn't display any message.  Then when the crash occurs, I ask the debugger to display information on the breakpoint, and find that it occurred N times.  Then I rerun the program, and set a breakpoint at that same place, telling the debugger to stop the program after it's hit that place N-1 times.  That way, I can see what's going on just before the crash. 

Sometimes when the buggy program is unknown to me, I wrap the debugger
(gdb) inside an Expect script, set breakpoint to the start of the main
procedure, and instruct the script to send "go until next source code
line" to the debugger until the buggy program crashes.

Depending on the size of the program, this might take hours, but I get
automatically strace of every source code line (since gdb prints them
for me) before the crash all the way from the beginning of the program
and I don't even need to turn on separate tracing from the source code.

Also, if I am interested in some variable, I can instruct either gdb
or my Expect script to display it before continuing to the next line.

Btw, you Ada compiler vendors have it easy. Just imagine if Ada would
be a weakly-typed just-in-time compiled scripting language ran inside
the browser (on embedded device for extra kicks) when something happens
on the web site and you would have to debug why the browser crashes
when a certain script is run. ;)

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: Practicalities of Ada for app development

[Randy Brukardt]

"Tero Koskinen" <tero.koskinen@iki.fi> wrote in message 
news:20120622083215.f4d37d14bee6f2a5f144bbe6@iki.fi...
> On Fri, 22 Jun 2012 05:59:08 +0100
...
> Another nice feature of recent gdb (7.0) is Python scripting:
> http://sourceware.org/gdb/onlinedocs/gdb/Python-Commands.html
> http://napsy.wordpress.com/2009/10/11/gdb-7-scripting/

The Janus/Ada debugger uses an Ada-like language for this purpose (and, 
indeed, for all commands). (Although, as I previously mentioned, that 
feature doesn't work on breakpoints; never spent the time to figure out 
why.) Why learn another language when Ada does everything better already? 
;-)

[Seriously, an Ada debugger needs to be able to evaluate Ada expressions to 
be useful. Once you have that capability, adding assignment and if 
statements is pretty simple, and that's mainly what you need to write 
macros. Why implement a whole new language when the one you have it already 
pretty good and complete?]

                                   Randy.

Re: Practicalities of Ada for app development

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

"J-P. Rosen" <rosen@adalog.fr> wrote in message 
news:js032p$n1t$1@dont-email.me...
> Le 21/06/2012 23:00, Randy Brukardt a �crit :
>> The only time the debugger hassle is worth it is when the bug is
>> sufficiently low-level that you can't debug it at the Ada level (as when 
>> a
>> register has the wrong value for some reason, causing a hardware fault). 
>> And
>> that usually takes me many hours (usually an entire working day) for a
>> single problem, as opposed to dealing with a problem an hour or so at the
>> Ada level.
> Although I fully agree with you, I can add another use case where a
> debugger can be useful: when you enter an infinite loop and you don't
> have the foggiest idea where it is - assuming that ^C works, which is
> not always the case.

It rarely works usefully on Windows; you usually end up somewhere in the 
kernel and getting back to your program is iffy at best. I do my best to 
avoid writing infinite loops (this is arguably the most important value of 
the iterators in the containers libraries: you can't get an infinite loop 
from using them), but of course you can never be sure. I usually use 
incremental development in small enough steps that there are only one or two 
loops to look at for the problem - so usually the bug is obvious. When it's 
not, I just lose more hair...

                                   Randy.

Re: Practicalities of Ada for app development

[J-P. Rosen]

Le 22/06/2012 21:55, Randy Brukardt a �crit :
> I usually use 
> incremental development in small enough steps that there are only one or two 
> loops to look at for the problem - so usually the bug is obvious. When it's 
> not, I just lose more hair...
I also rarely have that problem; I just mentionned that this is one
(rare) case where I try to use a debugger - not always successfully.

But apparently, it has happened to me more often than to you, if we
compare hair...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Practicalities of Ada for app development

[Eryndlia Mavourneen]

>> Dmitry et al "SNOBOL patterns are far more powerful "

Yes!  SPITBOL was a much faster compiled version of the SNOBOL4 interpreter.  (SNOBOL4 was the version of SNOBOL with pattern matching.)  I once used SPITBOL to write a quick and dirty assembler for a truly ancient machine with only a paper tape reader.  lol.

However!  I truly fell in love with the ICON language, created at the University of Arizona by Ralph Griswold, one of the developers of SNOBOL4, and his students.  Unlike SNOBOL4, in which the pattern matching was a separate facility with its associated problems, as has been pointed out earlier in this thread, ICON integrated pattern matching into the normal (and natural!) expression evaluation.  In this way an expression, and potentially an entire statement, could be evaluated zero or more times until the pattern match was completely satisfied.  Very beautiful!

I still keep my ICON book and dream of integrating ICON pattern evaluation into Ada expressions.  A pipe dream, but one must live for something.  lol

Re: Practicalities of Ada for app development

[Eryndlia Mavourneen]

>> RE:  String processing in Ada.

There are existing, very good packages that do string processing as well as containers that do not exist in Ada 2012.  The Booch components are one, and I have seen any number of others, many from university.  Dmitry, do I recall that you have something along those lines?

Certainly in terms of efficiency, once should just process a string in-place, but that's not always fun, and efficiency doesn't always matter.

Re: Practicalities of Ada for app development

[Simon Wright]

Eryndlia Mavourneen <eryndlia@gmail.com> writes:

>>> RE:  String processing in Ada.
>
> There are existing, very good packages that do string processing as
> well as containers that do not exist in Ada 2012.  The Booch
> components are one, and I have seen any number of others, many from
> university.  Dmitry, do I recall that you have something along those
> lines?

The Ada BCs don't do string processing (Grady's C++ components had some
RE support; the manual is still in a packing box, but I do know that I
never implemented this feature in the Ada 95 version).