newbie can't get exceptions to work!

newbie can't get exceptions to work!

[Jeff Shipman]

Ok, I'm creating a generic stack package and I think
I've done everything properly, but I cannot seem to
get my STACK_EXCEPTION to work. This is what it
looks like in my gen_stack.ads file:

generic
   LEN : NATURAL := 100;      -- Size of the stack (default 100
   type ELM is private;       -- Used to store element type

   package GEN_STACK is
      STACK_ERROR : exception;        -- Raised when something bad
happens.
      
      procedure PUSH(E : in ELM);     -- Push E into the stack
      procedure POP(E : out ELM);     -- Pop element from stack; store
in E
      
      function  FULL return BOOLEAN;  -- Returns TRUE if stack is full
      function  EMPTY return BOOLEAN; -- Returns TRUE if stack is empty
   end GEN_STACK;

and I can use it just fine in my gen_stack.adb. The use_gen_stack.adb
file which uses the stacks works great up until the point I want to
handle the exceptions. My code for handling it looks like this:

   -- Handle exceptions
   exception
      when STACK_ERROR =>
      begin
         put_line("Error: Stack underflow/overflow");
      end;

When I try to compile, I get the following errors:

use_gen_stack.adb:214:12: "STACK_ERROR" is not visible
use_gen_stack.adb:214:12: multiple use clauses cause hiding
use_gen_stack.adb:214:12: hidden declaration at gen_stack.ads:14,
instance at line 32
use_gen_stack.adb:214:12: hidden declaration at gen_stack.ads:14,
instance at line 31
use_gen_stack.adb:214:12: hidden declaration at gen_stack.ads:14,
instance at line 30
use_gen_stack.adb:214:12: hidden declaration at gen_stack.ads:14,
instance at line 29
use_gen_stack.adb:214:12: hidden declaration at gen_stack.ads:14,
instance at line 28
use_gen_stack.adb:214:12: hidden declaration at gen_stack.ads:14,
instance at line 27
gnatmake: "use_gen_stack.adb" compilation error
make: *** [use_gen_stack] Error 4

Those relevant lines of code are:

   -- Convenient stack types we'll need
   package INT_STACK is new GEN_STACK(ELM => INTEGER, LEN => 10);
   package INT2_STACK is new GEN_STACK(ELM => INTEGER, LEN => 5);
   package FLOAT_STACK is new GEN_STACK(ELM => FLOAT, LEN => 12);
   package CHAR_STACK is new GEN_STACK(ELM => CHARACTER, LEN => 14);
   package STR_STACK is new GEN_STACK(ELM => STR, LEN => 3);
   package DAY_STACK is new GEN_STACK(ELM => DAY, LEN => 7);

   use INT_STACK; use INT2_STACK; use FLOAT_STACK;
   use CHAR_STACK; use STR_STACK; use DAY_STACK;

At the top of my file, I have the following:

with text_io; use text_io;
with ada.float_text_io; use ada.float_text_io;
with gen_stack;

I've tried putting in use STACK_ERROR in multiple
places. I just can't get this exception handler
to compile. I would greatly appreciate it if someone
could help me. I'm sure it's a very simple thing
I'm forgetting. By the error message, it seems like
it doesn't like the multiple instances of use, but
If I want to use those packages I created, I have
to do that!

Thanks in advance,
 
Jeff "Shippy" Shipman     E-Mail: shippy@nmt.edu
Computer Science Major    ICQ: 1786493
New Mexico Institute of Mining and Technology
Homepage: http://www.nmt.edu/~shippy

Re: newbie can't get exceptions to work!

[Ed Falis]

Jeff Shipman wrote:
> Ok, I'm creating a generic stack package and I think
> I've done everything properly, but I cannot seem to
> get my STACK_EXCEPTION to work. This is what it
> looks like in my gen_stack.ads file:


The following line in the error messages is the key:

use_gen_stack.adb:214:12: multiple use clauses cause hiding

Each instantiation of the stack package that you made created a
different exception Stack_Error.  The compiler can't tell which one you
intend to handle.  Either set up the exception handler with a choice
list using the fully qualified names:

when Inst_1.Stack_Error | Inst_2.Stack_Error =>  -- etc, listing all of
them

or just use a "when others => " choice.

- Ed

Re: newbie can't get exceptions to work!

[martin.m.dowie]

or do what the language does viz-a-viz Ada.Text_IO and create a separate
package to declare the exceptions and then raise them from within the
generic
body definitions. This way all instances use the same exception. I'll leave
it
to you to decide if this is a 'good thing' ;-) e.g.

package Stack_Exceptions is

   Usage_Error : exception;
   Overflow_Error : exception;

end Stack Exceptions;

with Stack_Exceptions;

package body GEN_STACK is
   -- stuff
   procedure PUSH (...) is
   begin
      --
      raise Stack_Exceptions.Overflow_Error;
      --
   end PUSH;
   --
end GEN_STACK;


Ed Falis wrote:

> Jeff Shipman wrote:
> > Ok, I'm creating a generic stack package and I think
> > I've done everything properly, but I cannot seem to
> > get my STACK_EXCEPTION to work. This is what it
> > looks like in my gen_stack.ads file:
>
> The following line in the error messages is the key:
>
> use_gen_stack.adb:214:12: multiple use clauses cause hiding
>
> Each instantiation of the stack package that you made created a
> different exception Stack_Error.  The compiler can't tell which one you
> intend to handle.  Either set up the exception handler with a choice
> list using the fully qualified names:
>
> when Inst_1.Stack_Error | Inst_2.Stack_Error =>  -- etc, listing all of
> them
>
> or just use a "when others => " choice.
>
> - Ed

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <3ACC5053.10D0BC7E@ntlworld.com>, martin.m.dowie says...
>
>or do what the language does viz-a-viz Ada.Text_IO and create a separate
>package to declare the exceptions and then raise them from within the
>generic body definitions. This way all instances use the same exception. 

Ahhhh. So *that's* why they did that! I'd always wondered about that; but since
I don't do "use"s, I'd never run into that issue. That's very interesting. 

I wonder what other extra problems "use" users have to contend with, of which
I'm blissfully unaware...  :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Fraser Wilson]

Ted Dennison<dennison@telepath.com> writes:

> In article <3ACC5053.10D0BC7E@ntlworld.com>, martin.m.dowie says...
> Ahhhh. So *that's* why they did that! I'd always wondered about that; but since
> I don't do "use"s, I'd never run into that issue. That's very interesting. 

Well, also the fact that there's no need for different exceptions for
each package that mean exactly the same thing ... I can't see a gain
from knowing what sort of file an End_Error came from.  Which
_particular_ file, yes.

> I wonder what other extra problems "use" users have to contend with, of which
> I'm blissfully unaware...  :-)

Readable code.  :)

Fraser.

Re: newbie can't get exceptions to work!

[Jeff Shipman]

>    -- Handle exceptions
>    exception
>       when STACK_ERROR =>
>       begin
>          put_line("Error: Stack underflow/overflow");
>       end;
> 

Ok...I figured it out. I needed to specify the type
of stack that I'm catching the error for. e.g.
DAY_STACK.STACK_ERROR, etc.

-- 
Jeff "Shippy" Shipman     E-Mail: shippy@nmt.edu
Computer Science Major    ICQ: 1786493
New Mexico Institute of Mining and Technology
Homepage: http://www.nmt.edu/~shippy

RE: newbie can't get exceptions to work!

[Wilhelm Spickermann]

On 05-Apr-01 Jeff Shipman wrote:
...
> generic
>    LEN : NATURAL := 100;      -- Size of the stack (default 100
>    type ELM is private;       -- Used to store element type
> 
>    package GEN_STACK is
>       STACK_ERROR : exception;        -- Raised when something bad
> happens.
>       
>       procedure PUSH(E : in ELM);     -- Push E into the stack
>       procedure POP(E : out ELM);     -- Pop element from stack;
> store
> in E
>       
>       function  FULL return BOOLEAN;  -- Returns TRUE if stack is
...
>    exception
>       when STACK_ERROR =>
...
> When I try to compile, I get the following errors:
> 
> use_gen_stack.adb:214:12: "STACK_ERROR" is not visible
> use_gen_stack.adb:214:12: multiple use clauses cause hiding

What should the program do, if You write "PUSH(4)"? Should it push into
INT_STACK or INT2_STACK?

You have created six _different_ exceptions, which are all called
STACK_ERROR. The compiler cannot possibly know which one You try to
handle. You could use names like FLOAT_STACK.STACK_ERROR etc.

You will run into the same problems with the other entities of the
generic package.

Such a "generic abstract data object" is very practical if only one
instantiation is needed at every place of use. If You really need
several stack in interleaved usage, you need a "generic abstract data
type".

Wilhelm

Re: RE: newbie can't get exceptions to work!

[Ted Dennison]

In article <mailman.986446867.31184.comp.lang.ada@ada.eu.org>, Wilhelm
Spickermann says...
>
>
>On 05-Apr-01 Jeff Shipman wrote:
>> When I try to compile, I get the following errors:
>> 
>> use_gen_stack.adb:214:12: "STACK_ERROR" is not visible
>> use_gen_stack.adb:214:12: multiple use clauses cause hiding
>
>You have created six _different_ exceptions, which are all called
>STACK_ERROR. The compiler cannot possibly know which one You try to
>handle. You could use names like FLOAT_STACK.STACK_ERROR etc.
>
>You will run into the same problems with the other entities of the
>generic package.

This is a very good example of why "newbies" should be discouraged from using
the "use" clause. It just adds a whole extra possible level of confusion and
screw-ups. Some people (myself included) believe that "use" should almost never
be used. But even those who disagree with that view would agree that it has to
be used wisely. A rank novice will not yet have the knowledge required to make
that determination properly. So novices should really just stick with full
named-notation. When they get their feet under them, then they can go and decide
when "use" is appropriate and when it is not.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: RE: newbie can't get exceptions to work!

[Wilhelm Spickermann]

On 05-Apr-01 Ted Dennison wrote:
...
> This is a very good example of why "newbies" should be discouraged
> from using
> the "use" clause. It just adds a whole extra possible level of
> confusion and
> screw-ups. Some people (myself included) believe that "use" should
> almost never
> be used. But even those who disagree with that view would agree that
> it has to be used wisely.

I agree -- as one of those "who disagree". The stack may be also a
good example for a use of "use" which is acceptable for me. If we define
an abstract data _type_ instead of the given abstract data object we get
calls like "Push (Stackname, Object_To_Be_Pushed)" and thats ok for me
(as long as it has the "usual" (:-)) semantics of a stack). 

> be used wisely. A rank novice will not yet have the knowledge
> required to make
> that determination properly. So novices should really just stick with
> full
> named-notation. When they get their feet under them, then they can go
> and decide
> when "use" is appropriate and when it is not.

Fully agreed. But running into the problems with this example is much
more impressing than everything we could say.

Wilhelm

Re: newbie can't get exceptions to work!

[Marc A. Criley]

Ted Dennison wrote:

  <snips>

> This is a very good example of why "newbies" should be discouraged from using
> the "use" clause. It just adds a whole extra possible level of confusion and
> screw-ups. Some people (myself included) believe that "use" should almost never
> be used. But even those who disagree with that view would agree that it has to
> be used wisely. 

I started out with the position that "use" should almost never be used,
but have been experimenting with a more liberal approach recently.

I was very pleased with the addition of "use type" to Ada 95, despite
the opinion of a some that it's an ugly addition that was included
merely to avoid having to write "renames" clauses for operators.  To me,
not having to write such renames clauses de-clutters the code, improving
its appearance and readability.

Some time ago I'd heard advocacy of using "use" clauses for
service/support packages.  E.g., string packages, time packages, data
structure packages.  I'd bought into that, and even put it into some of
the Ada programming standards I've worked on over the last few years.

Lately I've been trying out the approach that Dewar has advocated: 
Liberal use of the use clause, and rely on your source code browser to
locate definitions.  I haven't made up my mind on this approach yet.  On
the one hand, a lot of verbosity is omitted, especially when dealing
with hierarchical libraries:     

   SetUserObject(Top, Component_Node);

is still quite clear without qualifying the whole procedure call:

   Javax.Swing.Tree.DefaultMutableTreeNode.SetUserObject
        (Top, Component_Node);

...especially when you're making lots of invocations of procedures
provided by a number of hierarchical packages that are just as deep. 
Qualifying every such reference results in very dense blocks of text.

(I know about the possiblity of renaming packages to an abbreviation,
but I simply have an aversion to acronyms in code.  You have to know or
be able to figure out what it stands for, you run the risk of
abbreviating the same package different ways in different places, and I
recall some Ada presentation where it was noted that the language
designers consciously chose to spell out language terms--hence
"character" instead of "char".  So with me it's sort of an
all-or-nothing approach, either qualify it properly or don't at
all--don't confuse me with acronyms.)

On the other hand, in order to use the browser, the code has to compile,
and if I'm in the middle of performing open source surgery on a package
and want to check out a type definition or procedure spec, the package
is in no condition to compile and so I don't have access to the
browser.  At least not with Emacs/GLIDE.

We'll see...

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <3ACDB29E.45B91316@earthlink.net>, Marc A. Criley says...
>
>Lately I've been trying out the approach that Dewar has advocated: 
>Liberal use of the use clause, and rely on your source code browser to
>locate definitions.  I haven't made up my mind on this approach yet.  On
..
>On the other hand, in order to use the browser, the code has to compile,
>and if I'm in the middle of performing open source surgery on a package
>and want to check out a type definition or procedure spec, the package
>is in no condition to compile and so I don't have access to the
>browser.  At least not with Emacs/GLIDE.

That in a nutshell is my main problem with that argument. You are essentially
making your code unreadable (well, not that bad perhaps, but getting there),
except in a very narrow circumstance. It has to compile, you have to have the
entire baseline handy and available, you have to be using Emacs to read it, you
can't change compilers...

Also, I don't see why the opposite approach could not be taken. Why not add a
"Hide/Show Full Names" option to Emacs?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Robert A Duff]

"Marc A. Criley" <mcqada@earthlink.net> writes:

> I was very pleased with the addition of "use type" to Ada 95, despite
> the opinion of a some that it's an ugly addition that was included
> merely to avoid having to write "renames" clauses for operators.  To me,
> not having to write such renames clauses de-clutters the code, improving
> its appearance and readability.

Not only do the renames clutter -- they are also quite error prone.

Use type is better than nothing, but even that adds one line of clutter.
IMHO, you should be able to refer to operators *anywhere*, without
having to say anything special.  You don't have to say "use" in order to
write "X := Y"; why should you have to write "use" in order to write
"if X = Y ..."?

>    SetUserObject(Top, Component_Node);
> 
> is still quite clear without qualifying the whole procedure call:
> 
>    Javax.Swing.Tree.DefaultMutableTreeNode.SetUserObject
>         (Top, Component_Node);

One compromise is to have a "use Javax.Swing.Tree;", and then say:

    DefaultMutableTreeNode.SetUserObject(Top, Component_Node);

presuming there's only one package called DefaultMutableTreeNode around
the place.

- Bob

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <wccpueqou73.fsf@world.std.com>, Robert A Duff says...
>
>"Marc A. Criley" <mcqada@earthlink.net> writes:
>
>> I was very pleased with the addition of "use type" to Ada 95, despite
>> the opinion of a some that it's an ugly addition that was included
>> merely to avoid having to write "renames" clauses for operators.  To me,
>> not having to write such renames clauses de-clutters the code, improving
>> its appearance and readability.
>
>Not only do the renames clutter -- they are also quite error prone.

True. Everyone who's accidentally renamed "<" to ">", raise your hand...

*
|

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Robert A Duff]

Ted Dennison<dennison@telepath.com> writes:

> True. Everyone who's accidentally renamed "<" to ">", raise your hand...

Right.  The "cut and paste" kind of error.

- Bob

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Fri, 6 Apr 2001, Robert A Duff wrote:
> "Marc A. Criley" <mcqada@earthlink.net> writes:
> > I was very pleased with the addition of "use type" to Ada 95, despite
> > the opinion of a some that it's an ugly addition that was included
> > merely to avoid having to write "renames" clauses for operators.  

Hmmm. I think it's ugly because it was included merely to avoid having to
write use clauses. If you're a no-use fanatic, you should be content with
not using use clauses, but no, use-phobes thinks it's OK as long as the 
infix syntax is used. So the language is butchered to handle this special
case. 

> Not only do the renames clutter -- they are also quite error prone.
> 
> Use type is better than nothing,

Nah, no change would have been fine. The syntax is nicely messed up now. 
Once "with type" is part of the standard the mess will get messier, as 
we'll have with and use, with type and use type. 

> but even that adds one line of clutter.
> IMHO, you should be able to refer to operators *anywhere*, without
> having to say anything special.

Why, what's so special about operators? Well, OK, Ada makes them a bit
special by not allowing you to define new ones (an annoying restriction
IMO) but they are just functions, right?

> You don't have to say "use" in order to
> write "X := Y"; 

":=" is special. It's not a function, and you can't redefine it, except
for very special types. Yes, I know you know all this :-). 

> why should you have to write "use" in order to write
> "if X = Y ..."?

"=" is also kind of special, right? 

Are you proposing that assignment and equality are both special enough
that no use is necessary, or are you saying all operators should be exempt 
from being use (type)-ed? 

-- Brian

Re: newbie can't get exceptions to work!

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> On Fri, 6 Apr 2001, Robert A Duff wrote:
> > "Marc A. Criley" <mcqada@earthlink.net> writes:
> > > I was very pleased with the addition of "use type" to Ada 95, despite
> > > the opinion of a some that it's an ugly addition that was included
> > > merely to avoid having to write "renames" clauses for operators.  
> 
> Hmmm. I think it's ugly because it was included merely to avoid having to
> write use clauses. If you're a no-use fanatic, you should be content with
> not using use clauses, but no, use-phobes thinks it's OK as long as the 
> infix syntax is used. So the language is butchered to handle this special
> case. 

It has nothing to do with "writing".  It has to do with reading.

I'm neither use-phobe nor use-phile.  I think it depends on the package,
whether you should say "use" of it.  I take it you're a use-phile, and
don't really care if the use-phobes have to write unreadable code.  If
so, then I suppose you think "use" should be banished, and everything
should be use-visible by default?

> > Not only do the renames clutter -- they are also quite error prone.
> > 
> > Use type is better than nothing,
> 
> Nah, no change would have been fine. The syntax is nicely messed up now. 
> Once "with type" is part of the standard the mess will get messier, as 
> we'll have with and use, with type and use type. 
> 
> > but even that adds one line of clutter.
> > IMHO, you should be able to refer to operators *anywhere*, without
> > having to say anything special.
> 
> Why, what's so special about operators?

Operators are used when the programmer thinks the concise notation of
operator syntax makes the code more readable than identifier-named
functions.  Eg, we think that:

    A + B*C

is more readable than:

    Add(A, Multiply(B, C))

If that's true, it makes no sense at all to ever say:

    "+"(A, "*"(B, C))

or:

    Some_Package."+"(A, Some_Package."*"(B, C))

Given that the whole point of operators is to use a concise symbol
instead of an English word, I think one should always use operator
notation for calls to operator functions.  If you always "use"
everything, then you can do that.  But I think it makes sense not to
'use' a particular package, so you have to say
Some_Package.Some_Function, but still want to write calls to operators
using operator notation (infix, etc).

>... Well, OK, Ada makes them a bit
> special by not allowing you to define new ones (an annoying restriction
> IMO) but they are just functions, right?

I agree that it's an annoying restriction.  The reason, I guess, is that
if you allowed someone to define an operator "$" or "&^%$$##", you would
have to worry about the syntax.  What is the precedence of these
operators?  I think Cecil has a nice solution to the problem.

> > You don't have to say "use" in order to
> > write "X := Y"; 
> 
> ":=" is special. It's not a function, and you can't redefine it, except
> for very special types. Yes, I know you know all this :-). 

Yes, I know it, and I know you know it, and I know you know I know it. ;-)

I can still gripe about it.

It's not just ":=", but also notations like "in", "and then", and "A(I)"
(I would prefer "A[I]", by the way) and literal notation.  These are all
"special" in that you don't need to say "use" to use these notations
(and also in that you can't redefine them; sigh).  They look like
operators to me, but Ada says otherwise.

> > why should you have to write "use" in order to write
> > "if X = Y ..."?
> 
> "=" is also kind of special, right? 

Unfortunately true.

> Are you proposing that assignment and equality are both special enough
> that no use is necessary, or are you saying all operators should be exempt 
> from being use (type)-ed? 

I meant that all operators should be exempt.  I wasn't speaking
particularly about ":=" and "=" (and I realize that Ada defines "=" to
be an operator, but not ":=" or "in", etc).

- Bob

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Fri, 6 Apr 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > On Fri, 6 Apr 2001, Robert A Duff wrote:
> > > "Marc A. Criley" <mcqada@earthlink.net> writes:
> > > > I was very pleased with the addition of "use type" to Ada 95, despite
> > > > the opinion of a some that it's an ugly addition that was included
> > > > merely to avoid having to write "renames" clauses for operators.  
> > 
> > Hmmm. I think it's ugly because it was included merely to avoid having to
> > write use clauses. If you're a no-use fanatic, you should be content with
> > not using use clauses, but no, use-phobes thinks it's OK as long as the 
> > infix syntax is used. So the language is butchered to handle this special
> > case. 
> 
> It has nothing to do with "writing".  It has to do with reading.
> 
> I'm neither use-phobe nor use-phile.  I think it depends on the package,
> whether you should say "use" of it.  I take it you're a use-phile, and
> don't really care if the use-phobes have to write unreadable code.

Actually, I'm a use-phobe who believes that absolute rules *never* make 
sense :-). What that means in practice is that I like to write code in a 
use-phobe style, except that there are just always cases where use is
clearer, and when it is, I'd like to use it. And typically, when I do use
it, I heed J.P. Rosen's advice about restricting it's scope. In other
words, be careful using use (and goto, and exceptions, and overloading,
and dynamic dispatch, and ...) because if you aren't careful your code
will become unreadable. 

I don't think use-philes really exist (OK, maybe somewhere there are a
few), but use-phobia is quite a real phenomena. 

What I hate are statements to the effect of "don't think, never use X!". 

>  If
> so, then I suppose you think "use" should be banished, and everything
> should be use-visible by default?

No. I've adopted a style that's very use-phobe phriendly. 
 
> > Why, what's so special about operators?
> 
> Operators are used when the programmer thinks the concise notation of
> operator syntax makes the code more readable than identifier-named
> functions.  Eg, we think that:
> 
>     A + B*C
> 
> is more readable than:
> 
>     Add(A, Multiply(B, C))
> 
> If that's true, it makes no sense at all to ever say:
> 
>     "+"(A, "*"(B, C))
> 
> or:
> 
>     Some_Package."+"(A, Some_Package."*"(B, C))
> 
> Given that the whole point of operators is to use a concise symbol
> instead of an English word, I think one should always use operator
> notation for calls to operator functions.  If you always "use"
> everything, then you can do that.  But I think it makes sense not to
> 'use' a particular package, so you have to say
> Some_Package.Some_Function, but still want to write calls to operators
> using operator notation (infix, etc).

OK, I was sort of being a pain with that question. However, since we're 
redesigning the language :-), the right solution IMO would be to have a 
more precise form of import and export clause than what Ada has, so that 
if you want to use a package you can choose precisely what gets seen.
This way, the use type folks are happy, I'm happy (well, I'm always happy:)
you're happy (yes?), and Niklaus Wirth is vindicated. For example,
something like 

from Some_Package use "+", "-", "*", Some_Function;

...
Some_Package.Some_Other_Function(Some_Function(A + B * C));
...

I think that would be an improvement. The only bummer is use-type folks
would have to specify which operators they want, but there is no danger 
of cut and paste rename issues.

> >... Well, OK, Ada makes them a bit
> > special by not allowing you to define new ones (an annoying restriction
> > IMO) but they are just functions, right?
> 
> I agree that it's an annoying restriction.  The reason, I guess, is that
> if you allowed someone to define an operator "$" or "&^%$$##", you would
> have to worry about the syntax.  What is the precedence of these
> operators?  I think Cecil has a nice solution to the problem.

What's the Cecil solution? The OCaml solution is to have precedence and
associativity inherited from the first character of the operator, so 
+. and +/ are like +. Unfortunately OCaml doesn't yet have overloading so 
it really needs this feature. You're probably not surprised to learn that 
in many language communities (Modula-3, ML, Eiffel?) overloading is viewed 
by many the same way that "use" is viewed by many in the Ada world. And I 
respond the same way, sure overloading can make a mess for the reader but 
used well it makes code more readable.

> > > You don't have to say "use" in order to
> > > write "X := Y"; 
> > 
> > ":=" is special. It's not a function, and you can't redefine it, except
> > for very special types. Yes, I know you know all this :-). 
> 
> Yes, I know it, and I know you know it, and I know you know I know it. ;-)

:-)

> I can still gripe about it.

That's the beauty of Usenet. 
 
> It's not just ":=", but also notations like "in", "and then", and "A(I)"
> (I would prefer "A[I]", by the way) 

Thank you, I completely agree. I find the choice of () for array access
makes code far less readable, since my eyes can't distinguish from
function calls. 

> and literal notation.  These are all
> "special" in that you don't need to say "use" to use these notations
> (and also in that you can't redefine them; sigh).  They look like
> operators to me, but Ada says otherwise.

I tell you what, design this next language, and I'm on board. I'm willing
to give up full closures as long as pattern matching and parametric
polymorphism are in the language. Take a look at the Cyclone project as 
an example of a decent looking futuristic systems programming language, 
unfortunately based on C. 

http://cvs.metaprl.org:12000/cvsweb/~checkout~/cyclone/doc/cyc_users_guide.htm

> > > why should you have to write "use" in order to write
> > > "if X = Y ..."?
> > 
> > "=" is also kind of special, right? 
> 
> Unfortunately true.

This is actually a deep problem. SML has it's eqtypes, OCaml has it's
polymorphic comparison primitives. Neither seem satisfactory to me. 

> > Are you proposing that assignment and equality are both special enough
> > that no use is necessary, or are you saying all operators should be exempt 
> > from being use (type)-ed? 
> 
> I meant that all operators should be exempt.  I wasn't speaking
> particularly about ":=" and "=" (and I realize that Ada defines "=" to
> be an operator, but not ":=" or "in", etc).

Well, I think the Wirthian solution is probably better, and has the nice 
property of not treating operators specially. Why didn't Ada have such a 
selective import? 

-- Brian

Re: newbie can't get exceptions to work!

[Jeffrey Carter]

Almost all of these features date back to Ada 80. Ada 80 blew just about
everything else out of the water in 1980, in terms of expressive power.
These special cases didn't seem important, when there were so many
things you could do with the language that you couldn't do in other
languages.

Now we're looking back after 20 years. We expect a language to have the
kind of expressive power we find in Ada (though few do), and these
special cases seem jarring. Certainly if we were designing a language
from scratch, after all this experience with Ada, we could avoid many of
them. However, things could be worse than having to use Ada.

Much worse.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: newbie can't get exceptions to work!

[Robert A Duff]

Jeffrey Carter <jrcarter@acm.org> writes:

> Almost all of these features date back to Ada 80. Ada 80 blew just about
> everything else out of the water in 1980, in terms of expressive power.
> These special cases didn't seem important, when there were so many
> things you could do with the language that you couldn't do in other
> languages.
> 
> Now we're looking back after 20 years. We expect a language to have the
> kind of expressive power we find in Ada (though few do), and these
> special cases seem jarring. Certainly if we were designing a language
> from scratch, after all this experience with Ada, we could avoid many of
> them. However, things could be worse than having to use Ada.

I'm thinking about these things with 20-20 hindsight.  I hope my (minor)
complaints about Ada don't come off looking like I'm saying the
designers of Ada 83 were stupid.  On the contrary!

- Bob

Re: newbie can't get exceptions to work!

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> I tell you what, design this next language, and I'm on board. 

I think I'm competent to design the language.  What I don't know how to
do is get people to use it.

I suspect that to make a *popular* language these days, you have to make
it look like C (yuck), and you have to have enough money to generate
large amounts of hype.  Sigh.

- Bob

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Sat, 7 Apr 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > I tell you what, design this next language, and I'm on board. 
> 
> I think I'm competent to design the language.  What I don't know how to
> do is get people to use it.

That's something of a crap shoot. Having a really good implementation helps.
I think a language targeted at systems programming (I assume you want to
design an Ada successor, not a high level language) that generated code 
which is about as good as C code, has a decent chance of getting new fans.  

> I suspect that to make a *popular* language these days, you have to make
> it look like C (yuck), 

Python isn't popular? Visual Basic? 

I don't think you need to go quite as far as Cyclone. Dump "begin end" and
use "{ }". If you keep the procedure/function distinction, use shorter
names. Use [] for arrays. Use Pascal notation for pointers. Provide some 
shortcut operators like C. Keep Ada's modes. OK, so the language may look
a bit different from Ada syntactically but I think it could stay in the
spirit of Ada semantically. 

> and you have to have enough money to generate large amounts of hype.  Sigh.

It's not clear to me that that approach is such a win. There is something
of a Java backlash too. What do I know though, I write OCaml these days. I'd 
rather be an idealist than someone who follows the PL trends. 

-- Brian

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
news:Pine.BSF.4.21.0104071403390.4484-100000@shell5.ba.best.com...
> On Sat, 7 Apr 2001, Robert A Duff wrote:
> > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > I tell you what, design this next language, and I'm on board.
> >
> > I think I'm competent to design the language.  What I don't know how to
> > do is get people to use it.
>
> That's something of a crap shoot. Having a really good implementation
helps.
> I think a language targeted at systems programming (I assume you want to
> design an Ada successor, not a high level language) that generated code
> which is about as good as C code, has a decent chance of getting new fans.
>
> > I suspect that to make a *popular* language these days, you have to make
> > it look like C (yuck),
>
> Python isn't popular? Visual Basic?
>
> I don't think you need to go quite as far as Cyclone. Dump "begin end" and
> use "{ }". If you keep the procedure/function distinction, use shorter
> names. Use [] for arrays. Use Pascal notation for pointers. Provide some
> shortcut operators like C. Keep Ada's modes. OK, so the language may look
> a bit different from Ada syntactically but I think it could stay in the
> spirit of Ada semantically.

I agree with all of the above, while begin-end may improve visibility, no
programming language has to consider non-programmers as a target audiance.
So {} as block statement, as well as some of C's nicest syntax features,
with all of Ada's safety behind it, you would have at least me as a fan.

Re: newbie can't get exceptions to work!

[David Starner]

On Sat, 7 Apr 2001 23:25:41 +0200, Ayende Rahien <Dont@spam.me> wrote:
> I agree with all of the above, while begin-end may improve visibility, no
> programming language has to consider non-programmers as a target audiance.

No Ada-like programming language, maybe. But Fortran, Basic, Visual Basic 
and Hypercard are all programing languages that considered non-programmers
a target audience and had many users because of it.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9ao60n$aik1@news.cis.okstate.edu...
> On Sat, 7 Apr 2001 23:25:41 +0200, Ayende Rahien <Dont@spam.me> wrote:
> > I agree with all of the above, while begin-end may improve visibility,
no
> > programming language has to consider non-programmers as a target
audiance.
>
> No Ada-like programming language, maybe. But Fortran, Basic, Visual Basic
> and Hypercard are all programing languages that considered non-programmers
> a target audience and had many users because of it.

Basic was meant for beginners, VB is quite easy to learn syntax wise, but
everything else require quite some knowledge.
Hypercard is for Macs, isn't it?

I'm talking mostly about VB, but I think that other languages (except
fortran? I have heard, but never used it) sacrifise a lot in order to be
easy.

You are correct, of course, I ignored those languages.

Re: newbie can't get exceptions to work!

[Larry Hazel]

Ayende Rahien wrote:
> 
> "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> news:Pine.BSF.4.21.0104071403390.4484-100000@shell5.ba.best.com...
> > On Sat, 7 Apr 2001, Robert A Duff wrote:
> > > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > > I tell you what, design this next language, and I'm on board.
> > >
> > > I think I'm competent to design the language.  What I don't know how to
> > > do is get people to use it.
> >
> > That's something of a crap shoot. Having a really good implementation
> helps.
> > I think a language targeted at systems programming (I assume you want to
> > design an Ada successor, not a high level language) that generated code
> > which is about as good as C code, has a decent chance of getting new fans.
> >
> > > I suspect that to make a *popular* language these days, you have to make
> > > it look like C (yuck),
> >
> > Python isn't popular? Visual Basic?
> >
> > I don't think you need to go quite as far as Cyclone. Dump "begin end" and
> > use "{ }". If you keep the procedure/function distinction, use shorter
> > names. Use [] for arrays. Use Pascal notation for pointers. Provide some
> > shortcut operators like C. Keep Ada's modes. OK, so the language may look
> > a bit different from Ada syntactically but I think it could stay in the
> > spirit of Ada semantically.
> 
> I agree with all of the above, while begin-end may improve visibility, no
> programming language has to consider non-programmers as a target audiance.
> So {} as block statement, as well as some of C's nicest syntax features,
> with all of Ada's safety behind it, you would have at least me as a fan.

I personally think {} should be removed from the character set, or at least
require a minimum of 5 keystrokes to get either.  And keep () for array
indices.  I have often used arrays as approximations of complex functions in the
early stages of development.  Then, when the real algorithm is programmed later,
nothing changes except the package containing the array/function.

Larry

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"Larry Hazel" <lhazel@mindspring.com> wrote in message
news:3ACFC902.115624A1@mindspring.com...
> Ayende Rahien wrote:
> >
> > "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> > news:Pine.BSF.4.21.0104071403390.4484-100000@shell5.ba.best.com...
> > > On Sat, 7 Apr 2001, Robert A Duff wrote:
> > > > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > > > I tell you what, design this next language, and I'm on board.
> > > >
> > > > I think I'm competent to design the language.  What I don't know how
to
> > > > do is get people to use it.
> > >
> > > That's something of a crap shoot. Having a really good implementation
> > helps.
> > > I think a language targeted at systems programming (I assume you want
to
> > > design an Ada successor, not a high level language) that generated
code
> > > which is about as good as C code, has a decent chance of getting new
fans.
> > >
> > > > I suspect that to make a *popular* language these days, you have to
make
> > > > it look like C (yuck),
> > >
> > > Python isn't popular? Visual Basic?
> > >
> > > I don't think you need to go quite as far as Cyclone. Dump "begin end"
and
> > > use "{ }". If you keep the procedure/function distinction, use shorter
> > > names. Use [] for arrays. Use Pascal notation for pointers. Provide
some
> > > shortcut operators like C. Keep Ada's modes. OK, so the language may
look
> > > a bit different from Ada syntactically but I think it could stay in
the
> > > spirit of Ada semantically.
> >
> > I agree with all of the above, while begin-end may improve visibility,
no
> > programming language has to consider non-programmers as a target
audiance.
> > So {} as block statement, as well as some of C's nicest syntax features,
> > with all of Ada's safety behind it, you would have at least me as a fan.
>
> I personally think {} should be removed from the character set, or at
least
> require a minimum of 5 keystrokes to get either.  And keep () for array
> indices.  I have often used arrays as approximations of complex functions
in the
> early stages of development.  Then, when the real algorithm is programmed
later,
> nothing changes except the package containing the array/function.

I won't argue with that () statement, but why don't you like {}?
BTW, Alt+<ASCII value> would serve? it's only four keystrokes only fer each,
though.

Re: newbie can't get exceptions to work!

[Larry Hazel]

Ayende Rahien wrote:
> 
> "Larry Hazel" <lhazel@mindspring.com> wrote in message
> news:3ACFC902.115624A1@mindspring.com...
> > Ayende Rahien wrote:
> > >
> > > "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> > > news:Pine.BSF.4.21.0104071403390.4484-100000@shell5.ba.best.com...
> > > > On Sat, 7 Apr 2001, Robert A Duff wrote:
> > > > > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > > > > I tell you what, design this next language, and I'm on board.
> > > > >
> > > > > I think I'm competent to design the language.  What I don't know how
> to
> > > > > do is get people to use it.
> > > >
> > > > That's something of a crap shoot. Having a really good implementation
> > > helps.
> > > > I think a language targeted at systems programming (I assume you want
> to
> > > > design an Ada successor, not a high level language) that generated
> code
> > > > which is about as good as C code, has a decent chance of getting new
> fans.
> > > >
> > > > > I suspect that to make a *popular* language these days, you have to
> make
> > > > > it look like C (yuck),
> > > >
> > > > Python isn't popular? Visual Basic?
> > > >
> > > > I don't think you need to go quite as far as Cyclone. Dump "begin end"
> and
> > > > use "{ }". If you keep the procedure/function distinction, use shorter
> > > > names. Use [] for arrays. Use Pascal notation for pointers. Provide
> some
> > > > shortcut operators like C. Keep Ada's modes. OK, so the language may
> look
> > > > a bit different from Ada syntactically but I think it could stay in
> the
> > > > spirit of Ada semantically.
> > >
> > > I agree with all of the above, while begin-end may improve visibility,
> no
> > > programming language has to consider non-programmers as a target
> audiance.
> > > So {} as block statement, as well as some of C's nicest syntax features,
> > > with all of Ada's safety behind it, you would have at least me as a fan.
> >
> > I personally think {} should be removed from the character set, or at
> least
> > require a minimum of 5 keystrokes to get either.  And keep () for array
> > indices.  I have often used arrays as approximations of complex functions
> in the
> > early stages of development.  Then, when the real algorithm is programmed
> later,
> > nothing changes except the package containing the array/function.
> 
> I won't argue with that () statement, but why don't you like {}?
> BTW, Alt+<ASCII value> would serve? it's only four keystrokes only fer each,
> though.

The use of {} is part of what makes C so unreadable to me.  Every } is the end
of something, but I always have a hard time figuring out what, and they are easy
to miss.  But the wierd operators and terseness in general are even worse.

Larry

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"Larry Hazel" <lhazel@mindspring.com> wrote in message
news:3AD1E164.2E2CB0B4@mindspring.com...
> Ayende Rahien wrote:


> > I won't argue with that () statement, but why don't you like {}?
> > BTW, Alt+<ASCII value> would serve? it's only four keystrokes only fer
each,
> > though.
>
> The use of {} is part of what makes C so unreadable to me.  Every } is the
end
> of something, but I always have a hard time figuring out what, and they
are easy
> to miss.  But the wierd operators and terseness in general are even worse.

That is a syntax problem, there are number of IDEs out there that would mark
what { the } belongs too. If you are using VC, there are macros to do this.
They are quite convient.
I find the operators clear, you just had to memorize a dozen or so, and that
is it.
I think it's just a matter of personal dislike for C's syntax. Personally, I
would love to work with C style Ada.

Re: newbie can't get exceptions to work!

[James Rogers]

Ayende Rahien wrote:
> 
> That is a syntax problem, there are number of IDEs out there that would mark
> what { the } belongs too. If you are using VC, there are macros to do this.
> They are quite convient.

This is a particularly C way of expressing convenience. A syntax
problem is convenient because tools are available to deal with it.

I find it much more convenient to avoid the problem altogether.

> I find the operators clear, you just had to memorize a dozen or so, and that
> is it.
> I think it's just a matter of personal dislike for C's syntax. Personally, I
> would love to work with C style Ada.

I find the C syntax for dealing with pointers to be excessively
convenient, as defined above.

A pointer to an int is defined as:

int *iptr;

At the same time, the value pointed to by iptr is referenced as
*iptr. This is clearly convenient. 

Now let's discuss pointers and structs:

struct mystruct 
{
  int foo;
  float bar;
}

struct mystruct myinstance;
struct mystruct *myptr;

Now, let's have myptr reference myinstance:

myptr = &myinstance;

How do we now access the "foo" field in the struct?

Through the myinstance variable we use simple "." notation:

myinstance.foo

Through myptr we have two choices for syntax:

(*myptr).foo

myptr->foo

This is clearly a very convenient syntax. It gets even more
convenient when mixing pointers and arrays in C:

int a[10];
int *pa;

pa = &a[0];
*pa = 50;
*(++pa) = 51;
*(pa++) += 90;

Let's see how convenient this is:

First we assigned 50 to a[0], then we assigned 51 to a[1],
then we added 90 to a[1] and incremented pa.

Finally, let's look at the ultimate C convenience: pointers to
functions.

float f();  /* f is a function returning float. */
float *f(); /* f is a function returning a pointer to a float.*/
float (*f)(); /* f is a pointer to a function returning float. */
float *(*f)(); /* f is a pointer to a function returning a pointer 
                  to a float. */
float (*(*f)())(); /* f is a pointer to a function returning a
                      pointer to a function returning float */

Now, I must say I have never found this kind of convenience in Ada.

Jim Rogers
Colorado Springs, Colorado USA

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Sat, 7 Apr 2001, Larry Hazel wrote:
> Ayende Rahien wrote:
> > "Brian Rogoff" <bpr@shell5.ba.best.com> wrote in message
> > news:Pine.BSF.4.21.0104071403390.4484-100000@shell5.ba.best.com...
> > > On Sat, 7 Apr 2001, Robert A Duff wrote:
> > > > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > > > I tell you what, design this next language, and I'm on board.
> > > >
> > > > I think I'm competent to design the language.  What I don't know how to
> > > > do is get people to use it.
> > > I don't think you need to go quite as far as Cyclone. Dump "begin end" and
> > > use "{ }". If you keep the procedure/function distinction, use shorter
> > > names. Use [] for arrays. Use Pascal notation for pointers. Provide some
> > > shortcut operators like C. Keep Ada's modes. OK, so the language may look
> > > a bit different from Ada syntactically but I think it could stay in the
> > > spirit of Ada semantically.
> > 
> > I agree with all of the above, while begin-end may improve visibility, no
> > programming language has to consider non-programmers as a target audiance.
> > So {} as block statement, as well as some of C's nicest syntax features,
> > with all of Ada's safety behind it, you would have at least me as a fan.
> 
> I personally think {} should be removed from the character set, or at least
> require a minimum of 5 keystrokes to get either. 

Well, personally I think this opinion is crap. Any reasons behind your
opinion? We were discussing making a language popular, and Bob Duff
espoused the theory that C influenced syntax is popular, and that a new 
language might seek to emulate it. I don't find {} vs begin end to be 
terribly important, and not a reason that I like Ada over C and C++. 
In fact, single char brackets are arguably much better than keywords as 
bracketing constructs, even from the reader's POV. 

Of course, syntax is one of those things that people can flame over
endlessly. Suffice to say that a slightly less verbose, more C like 
surface syntax for an Ada like language isn't a bad idea IMO. 

> And keep () for array indices.  I have often used arrays as
> approximations of complex functions in the early stages of development.  

I've never done that, and besides () makes code so much less readable. If
you really want to do that, it's dead easy to do that with [] arrays. Need
a hint? Just wrap those arrays in function calls.  

Anyways, this was a post-facto justification of this awful choice in Ada. 
To be fair, it wasn't really a choice (of Ichbiah and co.) but a
requirement to the languages competing. 

-- Brian

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <Pine.BSF.4.21.0104081508050.8921-100000@shell5.ba.best.com>, Brian
Rogoff says...
>
>On Sat, 7 Apr 2001, Larry Hazel wrote:
>> I personally think {} should be removed from the character set, or at least
>> require a minimum of 5 keystrokes to get either. 
>
>Well, personally I think this opinion is crap. Any reasons behind your

Whose, yours or Larrys? :-)  One of my personal favorite quotes: "Opinions are
like a**holes...everybody's got one, and they all stink."

>opinion? We were discussing making a language popular, and Bob Duff
>espoused the theory that C influenced syntax is popular, and that a new 
>language might seek to emulate it. I don't find {} vs begin end to be 
>terribly important, and not a reason that I like Ada over C and C++. 

There is absolutely no evidence that language popularity has anything to do with
syntax. That being the case, you'd like to strive for readability, not tersenes.
Curly-braces look quite a bit like parens at first glance (and sometimes upon
further glances too, depending on the font). Being a single chararacter, they
are fairly easy to miss with the eye, and are harder for the eye to properly
line up with distant lines (thus perhaps cause misapprehension of the proper
nesting level). In fact, the impression of pointing in a certian direction
causes a mild optical illusion which worsens the problem. Being mostly vertical,
they can also get accidentally hidden  behind the mouse pointer or an insertion
cursor.

>endlessly. Suffice to say that a slightly less verbose, more C like 
>surface syntax for an Ada like language isn't a bad idea IMO. 
If you want to favor the writer over the reader, perhaps. That is not The Ada
Way, though.

>> And keep () for array indices.  I have often used arrays as
>> approximations of complex functions in the early stages of development.  
>
>I've never done that, and besides () makes code so much less readable. If
I have. Its damn handy. I don't find it unreadable at all. It takes "information
hiding" one step further. An array is really just a prebuilt mapping function.
The main difference from the client perspective is that if its not a constant
array, you can modify the mappings on the fly with assignment syntax. But for
someone who just uses the mapping, why should they care how its implemented?

If I were looking to design my own language, what I'd look to do is extend this
analogy to somehow cover record objects as well.

>Anyways, this was a post-facto justification of this awful choice in Ada. 
>To be fair, it wasn't really a choice (of Ichbiah and co.) but a
>requirement to the languages competing. 
Are you sure? My understanding was that this was done *on purpose* for just this
reason.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Mon, 9 Apr 2001, Ted Dennison wrote:
> In article <Pine.BSF.4.21.0104081508050.8921-100000@shell5.ba.best.com>, Brian
> Rogoff says...
> >
> >On Sat, 7 Apr 2001, Larry Hazel wrote:
> >> I personally think {} should be removed from the character set, or at least
> >> require a minimum of 5 keystrokes to get either. 
> >
> >Well, personally I think this opinion is crap. Any reasons behind your
> 
> Whose, yours or Larrys? :-) 

Larry's of course. You mean OpenToken couldn't figure that out? What a 
useless library! :-)

> >opinion? We were discussing making a language popular, and Bob Duff
> >espoused the theory that C influenced syntax is popular, and that a new 
> >language might seek to emulate it. I don't find {} vs begin end to be 
> >terribly important, and not a reason that I like Ada over C and C++. 
> 
> There is absolutely no evidence that language popularity has anything
> to do with syntax.

Bob Duff apparently disagrees. While I don't entirely share his opinion, I
have to admit that there is a fair bit of evidence in support of it. 

> That being the case, you'd like to strive for readability, not tersenes.

False dichotomy. In many cases, terse notation is more readable. 

Besides, I imagine English keywords, rather than French, German, Chinese,
or Hindi, were chosen for some reason. Assume that there are far more
programmers (C, C++, Java, ....) who use a programming language with {} 
instead of begin-end nowadays, I think it's a fairly obvious argument
which suggests that today {} is a readable choice based on the experience 
of readers. 

If you don't care at all about the readers expectations based on previous
experience, an argument can be made for indentation based block structure
as in Python and Haskell. I find that very readable.

> Curly-braces look quite a bit like parens at first glance (and sometimes upon
> further glances too, depending on the font). Being a single chararacter, they
> are fairly easy to miss with the eye, and are harder for the eye to properly
> line up with distant lines (thus perhaps cause misapprehension of the proper
> nesting level). In fact, the impression of pointing in a certian direction
> causes a mild optical illusion which worsens the problem. Being mostly vertical,
> they can also get accidentally hidden  behind the mouse pointer or an insertion
> cursor.

You're really reaching here!

I've never had these problems, in many years of C, C++, and Java programming. 
I have had the problem of not being able to pick out arrays easily in the
code of Ada since nothing really stands out in Ada. A good syntax should
make different things look different. 

> >endlessly. Suffice to say that a slightly less verbose, more C like 
> >surface syntax for an Ada like language isn't a bad idea IMO. 
> If you want to favor the writer over the reader, perhaps. 

That's bullshit. This reader doesn't find Ada syntax all that great, nor C 
*syntax* that bad. Well, OK, modulo the declaration syntax. But I did say 
"copy Pascal" not C there. 

I suspect that most people who push this argument think that there is some 
objective criteria for readability which Ada optimizes. Please state it
precisely. 

> That is not The Ada Way, though.

I find Ada more readable than C++ because it has a lot fewer surprises in
it's semantics. For instance, the combination of implicit coercion with 
overloading in C++ is a nightmare. Ada's modes express the programmer intent 
well, so I suggested keeping them. Syntax in C++ is gruesome, but in Java 
it isn't too bad. It's only bad because OO is largely a bunch of crap, not
because of it's syntax.

> >> And keep () for array indices.  I have often used arrays as
> >> approximations of complex functions in the early stages of development.  
> >
> >I've never done that, and besides () makes code so much less readable. If
> I have. Its damn handy. I don't find it unreadable at all. It takes "information
> hiding" one step further. An array is really just a prebuilt mapping function.

More BS. Arrays and strings are data, not functions. 

> >Anyways, this was a post-facto justification of this awful choice in Ada. 
> >To be fair, it wasn't really a choice (of Ichbiah and co.) but a
> >requirement to the languages competing. 
> Are you sure? My understanding was that this was done *on purpose* for
> just this reason.

My recollection is that the last time this was discussed Robert Dewar
confirmed the statement that there was no discussion of using [] as array 
brackets at all, the choice of () had to do with the DoD requirements on
the character set to support (now) obsolete machines. All of this singing
and dancing about the virtues of this choice are post facto
rationalizations.

-- Brian

Re: newbie can't get exceptions to work!

[Laurent Guerby]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> On Mon, 9 Apr 2001, Ted Dennison wrote:
> > That being the case, you'd like to strive for readability, not tersenes.
> 
> False dichotomy. In many cases, terse notation is more readable. 
> 
> Besides, I imagine English keywords, rather than French, German, Chinese,
> or Hindi, were chosen for some reason. 

I hope you're not thinking terseness here, if you do a simple french
translation of common english programming language keywords, you'll
get the same length for most, may be one character more but that's all
(begin => debut, end => fin, if => si, else => sinon, ...). 

The reason for the choice of english is probably due to the language
being used to vehiculate scientific knowledge, and may be 7-bit ASCII
only supporting english and not really well other european or non
european languages.

> Assume that there are far more programmers (C, C++, Java, ....) who
> use a programming language with {} instead of begin-end nowadays, I
> think it's a fairly obvious argument which suggests that today {} is
> a readable choice based on the experience of readers.

I think the {} vs begin/end issue being completly unsignificant vs,
for example, brain damaged declarations, broken case statements,
unambiguous and readable if/then/elsif/else/endif nesting, named and
order free arguments and agregates, silly numerous levels of operator
priority and operator character choice, conflict between those silly
operators and template syntax in C++, idiotic comma operator, and in
general hard to parse by simple technique syntax (ask C++ compiler
writers). And I would absolute religious belief in keeping those
historical mistakes around (see Java).

If {} vs begin/end is issue for a new language, allow both and end of
the story.

PS: also, on a french keyboard, {} [] are a major pain to type ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On 9 Apr 2001, Laurent Guerby wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > On Mon, 9 Apr 2001, Ted Dennison wrote:
> > > That being the case, you'd like to strive for readability, not tersenes.
> > 
> > False dichotomy. In many cases, terse notation is more readable. 
> > 
> > Besides, I imagine English keywords, rather than French, German, Chinese,
> > or Hindi, were chosen for some reason. 
> 
> I hope you're not thinking terseness here,

No, I was thinking that most of the educated world can read English so
choosing English rather than French as the language from which the
keywords are drawn makes sense. From there, I reason that if we accept
familiarity as an argument (familiar symbols are more readable) then 
the choice of {} for begin end is so well ingrained in some huge fraction
of systems programmers (I assume you believe that C is more popular than
Ada; if not, we don't have much to talk about :) that it is a reasonable
choice. 

> The reason for the choice of english is probably due to the language
> being used to vehiculate scientific knowledge, 

That's definitely it. 

> and may be 7-bit ASCII only supporting english and not really well
> other european or non european languages.

Well, no doubt some Dutch speaker could put forth Nederlands as a choice, 
and there is already some precedent there on account of the names for the 
semaphor operations ;-). 

> > Assume that there are far more programmers (C, C++, Java, ....) who
> > use a programming language with {} instead of begin-end nowadays, I
> > think it's a fairly obvious argument which suggests that today {} is
> > a readable choice based on the experience of readers.
> 
> I think the {} vs begin/end issue being completly unsignificant vs,
> for example, 

Yes, I completely agree. Let's look at some of these

> brain damaged declarations,

Hey, I said ditch the C declaration syntax, didn't I? 

> broken case statements,

Broken semantically. Using the name switch wouldn't make a difference. 
Besides, I much prefer ML or Haskell pattern matching to Ada's case 
statement. More readable, more powerful, terser, better. 

> unambiguous and readable if/then/elsif/else/endif nesting,

Yes. C is very weak here. elsif and mandatory {} would help a lot. 

> named and order free arguments and agregates, 

Would be nice. There is some discussion about adding this to Ocaml now
too. You can use labelled params, but commuting arguments are still up in
the air. 

> silly numerous levels of operator priority 

Of course. 

> and operator character choice, 

True, but I must say that the += and friends are nice. Of course an Ada
version would be +:= and still nice. And while I don't like the syntax,
the ? : of C is also nice, but, as you know, I'm a functional kind of guy
now. 

> conflict between those silly operators and template syntax in C++, 

Right, and no need to go to C++ for that, as a similar problem pops up 
(albeit far less frequently) in C with "x = numerator /*p_denominator;"

> idiotic comma operator, and in
> general hard to parse by simple technique syntax (ask C++ compiler
> writers).

Sure. Some guy wrote a paper called "C++ Resyntaxed" which fixed a lot of 
these problems. And you forgot to mention how many ways the keyword
"static" is used, and... well, I guess we could go on forever. 

> And I would absolute religious belief in keeping those
> historical mistakes around (see Java).

I can't parse that. Let me guess, "And I would add, an absolute ..."?
I agree. C++ can be forgiven, as can Ada 95, since backwards compatibility
was a goal. Java just sucks. Does C# fix that stupid drop through case
problem, or was that botched too? 

> If {} vs begin/end is issue for a new language, allow both and end of
> the story.

That would be a mistake. Personally, I can go either way, begin-end or {}. 
I'm just annoyed at the bizarre thinking that puts one of these as greatly 
superior to the other. I really find () to be a bummer about Ada syntax
and I don't agree that wordier is always better. 

> PS: also, on a french keyboard, {} [] are a major pain to type ;-).

Hey man, get an American keyboard!

-- Brian

Re: newbie can't get exceptions to work!

[Laurent Guerby]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> On 9 Apr 2001, Laurent Guerby wrote:
> > broken case statements,
> 
> Broken semantically. Using the name switch wouldn't make a difference. 
> Besides, I much prefer ML or Haskell pattern matching to Ada's case 
> statement. More readable, more powerful, terser, better. 

Well, that's no longer syntax ;-). The horror I was refering too was
the optional break as you might have guessed. Also I find the
mandatory enumerate all rule in alternatives of Ada is quite useful.

I agree that pattern matching is something very nice to have anyway.

> > named and order free arguments and agregates, 
> 
> Would be nice. There is some discussion about adding this to Ocaml now
> too. You can use labelled params, but commuting arguments are still up in
> the air. 

I must admit I don't understand why every language doesn't have this
feature, especially all those conceived after Ada like OCaml. I
suspect we should mandate Ada history and design rationale lectures to
all language creators, a lot of engineering went into Ada, and we've
had a lot of time to judge the work done.

My favourite citation here is from Steve McConnell in "code Complete":

   Finally, the goto was incorporated into the Ada language, the
   most carefully engineered programming language in history.

> > and operator character choice, 
> 
> True, but I must say that the += and friends are nice. Of course an Ada
> version would be +:= and still nice. 

That's a possibility. Another is to have a way to generate tersely
procedural versions of operators, may be (ok ugly ;-)

procedure Inc is procedural "+";
-- Inc (X : in out T; Y : in T) is begin X := X + Y; end Inc;

Not really functional BTW ;-).

> And while I don't like the syntax, the ? : of C is also nice, but,
> as you know, I'm a functional kind of guy now.

This is not just syntax here, Ada doesn't have a way to do the same as
C here because of strictness in argument evaluation. I recently
designed a small language with an Ada-style syntax and I added "if"
expressions :

X : constant T := if C1  then V1 elsif C2 then V2 else V3;

This is something I think people miss in Ada, may be someone should
wrote an extension proposal ;-).

> > And I would absolute religious belief in keeping those
> > historical mistakes around (see Java).
> 
> I can't parse that. Let me guess, "And I would add, an absolute ..."?

You have a powerful syntax recovery parser in your brain ;-).

> > If {} vs begin/end is issue for a new language, allow both and end of
> > the story.
> 
> That would be a mistake. Personally, I can go either way, begin-end or {}. 
> I'm just annoyed at the bizarre thinking that puts one of these as greatly 
> superior to the other. I really find () to be a bummer about Ada syntax
> and I don't agree that wordier is always better. 

As other people pointed out, another advantage of end syntax is the
"end thing" which is quite nice. I think that if you allow declarations
to float around, the argument about terseness of {} becomes moot, eg:

procedure P is
   variable X : T := Initial;
   while Cond (X) loop  
      constant Tmp : T := G (X);
      if Cond (Tmp) then
         Do_Thing (Tmp, X);
      end if;
      Next (X);
   end loop;
end P;

would not gain much from {}.

And I of course forgot the mandatory () for function calls without
args silliness ;-).

> > PS: also, on a french keyboard, {} [] are a major pain to type ;-).
> 
> Hey man, get an American keyboard!

No, I just program in Ada at home and work ;-) ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On 10 Apr 2001, Laurent Guerby wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > On 9 Apr 2001, Laurent Guerby wrote:
> > > broken case statements,
> > 
> > Broken semantically. Using the name switch wouldn't make a difference. 
> > Besides, I much prefer ML or Haskell pattern matching to Ada's case 
> > statement. More readable, more powerful, terser, better. 
> 
> Well, that's no longer syntax ;-). The horror I was refering too was
> the optional break as you might have guessed. Also I find the
> mandatory enumerate all rule in alternatives of Ada is quite useful.

Oh yes. For all of those who complain about Microsoft, I just checked and 
they did *not* carry on this abomination in C#. This is a big issue IMO, 
and a real source of bugs in my experience with C. So MS language
designers are far bettre than Sun's. :-)
> 
> I agree that pattern matching is something very nice to have anyway.
> 
> > > named and order free arguments and agregates, 
> > 
> > Would be nice. There is some discussion about adding this to Ocaml now
> > too. You can use labelled params, but commuting arguments are still up in
> > the air. 
> 
> I must admit I don't understand why every language doesn't have this
> feature, especially all those conceived after Ada like OCaml. 

Well, I'm doing what I can on the OCaml mailing list to get nice little
features of Ada adopted. In the case of labeled and optional arguments,
it's a lot tougher in OCaml than Ada, which has type inference and higher
order functions. If you look at the recent discussions on the mailing
list, Jacques Garrigue (the label inventor and main proponent) is laying
out the alternatives and it looks like the only way to get commuting
labels is to have labels be non-optional. I don't like that. 
  
> suspect we should mandate Ada history and design rationale lectures to
> all language creators, a lot of engineering went into Ada, and we've
> had a lot of time to judge the work done.

Yes, I completely agree. And, for the record, I prefer begin-end to {} :-).
I would just like to point out that it isn't an earth shattering change,
and the reasons I much prefer Ada have little to do with it's surface
syntax, and much more to do with it's mostly non-surprising semantics.

> My favourite citation here is from Steve McConnell in "code Complete":
> 
>    Finally, the goto was incorporated into the Ada language, the
>    most carefully engineered programming language in history.

Actually, if Ada had downward funargs and maybe lighweight anonymous
functions, it would be pretty easy to write the state machine example 
in continuation passing style and that would be just as readable as 
using goto's. Please, no flames, I find using gotos for FSMs to be much
much nicer than using extra vars and case statements. 

> > > and operator character choice, 
> > 
> > True, but I must say that the += and friends are nice. Of course an Ada
> > version would be +:= and still nice. 
> 
> That's a possibility. Another is to have a way to generate tersely
> procedural versions of operators, may be (ok ugly ;-)
> 
> procedure Inc is procedural "+";
> -- Inc (X : in out T; Y : in T) is begin X := X + Y; end Inc;
> 
> Not really functional BTW ;-).

That's OK, as an ML fan I'm really only "mostly functional". Haskell,
Clean, and Mercury fans spit at me when I walk by. No need to describe
what they do to Ada or C++ fans ;-). 


> > And while I don't like the syntax, the ? : of C is also nice, but,
> > as you know, I'm a functional kind of guy now.
> 
> This is not just syntax here, Ada doesn't have a way to do the same as
> C here because of strictness in argument evaluation. I recently
> designed a small language with an Ada-style syntax and I added "if"
> expressions :
> 
> X : constant T := if C1  then V1 elsif C2 then V2 else V3;
> 
> This is something I think people miss in Ada, may be someone should
> wrote an extension proposal ;-).

That would work. OTOH, since Ada is statement oriented rather than
expression oriented, perhaps a different syntax for conditional
expressions is warranted?

> > > And I would absolute religious belief in keeping those
> > > historical mistakes around (see Java).
> > 
> > I can't parse that. Let me guess, "And I would add, an absolute ..."?
> 
> You have a powerful syntax recovery parser in your brain ;-).

Influenced by GNAT, as you must know ;-).

> > > If {} vs begin/end is issue for a new language, allow both and end of
> > > the story.
> > 
> > That would be a mistake. Personally, I can go either way, begin-end or {}. 
> > I'm just annoyed at the bizarre thinking that puts one of these as greatly 
> > superior to the other. I really find () to be a bummer about Ada syntax
> > and I don't agree that wordier is always better. 
> 
> As other people pointed out, another advantage of end syntax is the
> "end thing" which is quite nice. I think that if you allow declarations
> to float around, the argument about terseness of {} becomes moot, eg:
> 
> procedure P is
>    variable X : T := Initial;
>    while Cond (X) loop  
>       constant Tmp : T := G (X);
>       if Cond (Tmp) then
>          Do_Thing (Tmp, X);
>       end if;
>       Next (X);
>    end loop;
> end P;
> 
> would not gain much from {}.

Allowing declarations to float is nice. However, if, as I suggested, we
allow downward funargs (only downward, we don't want to require GC :) 
and anonymous functions, the {} has the advantage that function
definitions are lightweight enough to be expressed inline more easily. 

Even in ML, I don't use anonymous functions too much though, since there
is usually just enough work to be done by a function that it can't be
expressed easily in one line. I maintain a piece of code where someone
wrote an anonymous function over 100 lines long. Mama mia! 

> And I of course forgot the mandatory () for function calls without 
> args silliness ;-).

A great feature. Some people hate it though. 

> > > PS: also, on a french keyboard, {} [] are a major pain to type ;-).
> > 
> > Hey man, get an American keyboard!
> 
> No, I just program in Ada at home and work ;-) ;-).

Lucky you! I've switched to OCaml. Something about French designed
languages, eh? :-)

-- Brian

Re: newbie can't get exceptions to work!

[Laurent Guerby]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> Well, I'm doing what I can on the OCaml mailing list to get nice little
> features of Ada adopted. In the case of labeled and optional arguments,
> it's a lot tougher in OCaml than Ada, which has type inference and higher
> order functions. If you look at the recent discussions on the mailing
> list, Jacques Garrigue (the label inventor and main proponent) is laying
> out the alternatives and it looks like the only way to get commuting
> labels is to have labels be non-optional. I don't like that. 

I see label and optional arguments being two separate issue. If you do
only labels, it shouldn't cause any problem at all, you can even
disallow overloading with only label changes while keeping most of the
interesting thing about labels (call site clarity). But even keeping
overloading should be near trivial.

Optional argument are a whole different beast, and I think much less
useful, and I think likely to cause trouble.

Is it that the conjunction of both feature is being considered and
hence the problems (my advice would be to just drop optional
arguments), or am I missing something obvious?

I agree with you that mandating labels is not a good idea.

> > X : constant T := if C1  then V1 elsif C2 then V2 else V3;
> > 
> > This is something I think people miss in Ada, may be someone should
> > wrote an extension proposal ;-).
> 
> That would work. OTOH, since Ada is statement oriented rather than
> expression oriented, perhaps a different syntax for conditional
> expressions is warranted?

I don't buy the statement oriented thing, you can do lots of thing
without statements in Ada (the missing thing is this conditional
feature ;-), and I see no need to invent new syntax here (but well
that's a taste & color issue here ;-).

> Allowing declarations to float is nice. However, if, as I suggested, we
> allow downward funargs (only downward, we don't want to require GC :) 
> and anonymous functions, the {} has the advantage that function
> definitions are lightweight enough to be expressed inline more easily. 

If you type arguments, that's not going to be one liners hence the { }
won't buy you much. (I find SmallTalk syntax for blocks quite nice,
but let's say it's really typed ;-).

> > And I of course forgot the mandatory () for function calls without 
> > args silliness ;-).
> 
> A great feature. Some people hate it though. 

I don't know the history, but I'd say it's mostly because of the
statement = expression + fonction = pointer syntax horrors of C that
forces a hack to disambiguate, not because of methodology that argless
func/proc calls must specify ().

Why are people liking this?

Only C/C++/Java have inherited this syntax, other languages including
most FP do not have it and that's much better this way (am I missing
something obvious here?).

> > No, I just program in Ada at home and work ;-) ;-).
> Lucky you! I've switched to OCaml. 

I looked at the FP situation two years ago when we switched languages
at work (from C to Ada 95), but there was no real industrial stuff
available (with formal support and available even for idiotic
proprietary platforms). 

Right now, I think there's Erlang (we write numerical code and even
the Erlang manual says it's not for us ;-) and may be OCaml if out of
the recently announced consortium a real support company pops up.

As you might have guessed our support comes from ACT Europe and we're
using GNAT.

> Something about French designed languages, eh? :-)

May be ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: newbie can't get exceptions to work!

[Samuel T. Harris]

Laurent Guerby wrote:
> 
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > Well, I'm doing what I can on the OCaml mailing list to get nice little
> > features of Ada adopted. In the case of labeled and optional arguments,
> > it's a lot tougher in OCaml than Ada, which has type inference and higher
> > order functions. If you look at the recent discussions on the mailing
> > list, Jacques Garrigue (the label inventor and main proponent) is laying
> > out the alternatives and it looks like the only way to get commuting
> > labels is to have labels be non-optional. I don't like that.
> 
> I see label and optional arguments being two separate issue. If you do
> only labels, it shouldn't cause any problem at all, you can even
> disallow overloading with only label changes while keeping most of the
> interesting thing about labels (call site clarity). But even keeping
> overloading should be near trivial.
> 
> Optional argument are a whole different beast, and I think much less
> useful, and I think likely to cause trouble.
> 
> Is it that the conjunction of both feature is being considered and
> hence the problems (my advice would be to just drop optional
> arguments), or am I missing something obvious?
> 

Agreement here (mostly). Say a subprogram has an optional parameter.
The parameter is optional because the subprogram specification
has a default expression for the parameter specification.

It is a trivial refactoring to define a new subprogram
of the same name and the same argument profile except
it is missing the optional argument. The new subprogram's
body is a one-liner calling the first subprogram while
supplying the default expression. The first subprogram
is changed to exclude the default expression. One can
even pragma inline the new subprogram.

This refactoring causes NO code changes on callers.

So, what did the optional argument (i.e. default
parameter initial expression) buy me in the first place?

1. The default expression can be an important for
   its documentation value and not is effect of making
   the parameter optional.

2. What if I have a subprogram with many optional
   parameters? The above subprogram refactoring
   needs to provide new subprograms for every
   combination of present and missing parameters.
   That can be alot of subprograms.

3. Using optional parameters employs a conservation
   of declarations. One declaration handle two variations.
   Imaging package ada.text_io being specified with
   two of every put and get routine because the form
   parameter is optional.

As counter-point to the above benefits of optional
parameters, consider a real problem we experienced.
Using the VADS Ada compiler, we extensively use
the current_exception.exception_name function call.
Migrating to Apex we were pleased to find it defines
just such a call so we did not feel a problem on
this portability issue. That is until I discovered,
through Apex complaining about it, that some of our
code uses a subprogram rename declaration and that
this subprogram rename declaration would not compile
because Rational had added an optional parameter
to current_exception.exception_name. This clearly
shows that a subprogram with an optional parameter
is NOT semantically equivalent to two subprograms,
one with and one without, said parameter.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: newbie can't get exceptions to work!

[Robert A Duff]

"Samuel T. Harris" <u61783@gsde.hou.us.ray.com> writes:

> 3. Using optional parameters employs a conservation
>    of declarations. One declaration handle two variations.
>    Imaging package ada.text_io being specified with
>    two of every put and get routine because the form
>    parameter is optional.

But it's interesting that Text_IO does have two of every routine -- one
for Current_Output, and one where the file is specified explicitly.
This is because the file parameter comes first, and the Ada rules do not
define optional parameters to be equivalent to all the subprograms with
all combinations of having or not-having the parameter.  Perhaps it
should.

> As counter-point to the above benefits of optional
> parameters, consider a real problem we experienced.
> Using the VADS Ada compiler, we extensively use
> the current_exception.exception_name function call.
> Migrating to Apex we were pleased to find it defines
> just such a call so we did not feel a problem on
> this portability issue. That is until I discovered,
> through Apex complaining about it, that some of our
> code uses a subprogram rename declaration and that
> this subprogram rename declaration would not compile
> because Rational had added an optional parameter
> to current_exception.exception_name. This clearly
> shows that a subprogram with an optional parameter
> is NOT semantically equivalent to two subprograms,
> one with and one without, said parameter.

Right.  I think it probably should be semantically equivalent, but that
leads to a lot of implementation headaches.

- Bob

Re: newbie can't get exceptions to work!

[Mike Silva]

"Laurent Guerby" <guerby@acm.org> wrote in message
news:86puej8gbu.fsf@acm.org...

>...two years ago when we switched languages
> at work (from C to Ada 95)...

Would you care to tell us more about the why and how of this switch, and the
results?  I'm fishing, naturally, for another Ada Success Story :)

Mike

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On 11 Apr 2001, Laurent Guerby wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> I see label and optional arguments being two separate issue. If you do
> only labels, it shouldn't cause any problem at all, you can even
> disallow overloading with only label changes while keeping most of the
> interesting thing about labels (call site clarity). But even keeping
> overloading should be near trivial.
> 
> Optional argument are a whole different beast, and I think much less
> useful, and I think likely to cause trouble.
> 
> Is it that the conjunction of both feature is being considered and
> hence the problems (my advice would be to just drop optional
> arguments), or am I missing something obvious?

You should know that nothing is obvious when you're discussing the OCaml
type system :-). OK, that's not fair. It is obvious when considered in the 
context of mathematically sound type systems. If you're not well versed in
the theory of such type systems, simple explanations won't be helpful. 
Check the caml-list for the mail of the past few weeks titled "The Future
of Labels" or somesuch.

> I agree with you that mandating labels is not a good idea.

The likely solution will be that if you use labels in the function
definition, you'll need them at the call site. Once again, if you're 
interested in the why's you'd be better off reading the list, or checking 
Jacques Garrigue's home page and puzzling through the papers.

> > > X : constant T := if C1  then V1 elsif C2 then V2 else V3;
> > > 
> > > This is something I think people miss in Ada, may be someone should
> > > wrote an extension proposal ;-).
> > 
> > That would work. OTOH, since Ada is statement oriented rather than
> > expression oriented, perhaps a different syntax for conditional
> > expressions is warranted?
> 
> I don't buy the statement oriented thing, you can do lots of thing
> without statements in Ada (the missing thing is this conditional
> feature ;-), and I see no need to invent new syntax here (but well
> that's a taste & color issue here ;-).

Well, compared to Scheme, or ML, or any functional language Ada is surely 
statement oriented as opposed to expression oriented.

> > Allowing declarations to float is nice. However, if, as I suggested, we
> > allow downward funargs (only downward, we don't want to require GC :) 
> > and anonymous functions, the {} has the advantage that function
> > definitions are lightweight enough to be expressed inline more easily. 
> 
> If you type arguments, that's not going to be one liners hence the { }
> won't buy you much. (I find SmallTalk syntax for blocks quite nice,
> but let's say it's really typed ;-).

One line functions are not a compelling argument for me anyways, since I 
rarely ever use one liners. Besides, OCaml has pretty damned strong static
type checking and the syntax for one liners is pretty simple (only Haskell 
is a lot terser). 

# List.map (fun n -> n * n) [1; 2; 3; 4];;
- : int list = [1; 4; 9; 16]

> > > And I of course forgot the mandatory () for function calls without 
> > > args silliness ;-).
> > 
> > A great feature. Some people hate it though. 
> 
> I don't know the history, but I'd say it's mostly because of the
> statement = expression + fonction = pointer syntax horrors of C that
> forces a hack to disambiguate, not because of methodology that argless
> func/proc calls must specify ().
> 
> Why are people liking this?
> 
> Only C/C++/Java have inherited this syntax, other languages including
> most FP do not have it and that's much better this way (am I missing
> something obvious here?).

Just a question of (bad ;) taste. Anyways, the argument is that some like
to know it is a function call. 

Incidentally, CLU and it's successor Theta have this syntax too.

> > > No, I just program in Ada at home and work ;-) ;-).
> > Lucky you! I've switched to OCaml. 
> 
> I looked at the FP situation two years ago when we switched languages
> at work (from C to Ada 95), but there was no real industrial stuff
> available (with formal support and available even for idiotic
> proprietary platforms). 

Which idiotic platforms?

> Right now, I think there's Erlang (we write numerical code and even
> the Erlang manual says it's not for us ;-) and may be OCaml if out of
> the recently announced consortium a real support company pops up.

I don't believe such a support compant will pop up. I'll probably
represent my company at the Consortium, so I'll tell you if I hear
anything. 

I believe you made the right decision. It was a brave one too, since I bet 
there was a strong push for C++. Ada would be my choice too, given what
you told me. 

I mentioned Ada to my manager, and I often mention Ada when we discuss
language design. He now believes Ada is great, and if it were a choice
between Ada and C++ I believe he'd make the right choice. But the
competition in our company is with OCaml, and I'm not so sure that for 
what we do that Ada comes out on top.
 
> As you might have guessed our support comes from ACT Europe and we're
> using GNAT.

I trust the support has been good? 

-- Brian

Re: newbie can't get exceptions to work!

[Laurent Guerby]

Brian Rogoff <bpr@shell5.ba.best.com> writes:
> You should know that nothing is obvious when you're discussing the
> OCaml type system :-). OK, that's not fair. It is obvious when
> considered in the context of mathematically sound type systems. If
> you're not well versed in the theory of such type systems, simple
> explanations won't be helpful.  Check the caml-list for the mail of
> the past few weeks titled "The Future of Labels" or somesuch.

I'm not super-versed in those things (I've read a whole bunch of
papers and FP conference proeedings over the years but never
implemented anything), but as I see it, raw labeled arguments
are a near syntactic feature. Let's say you have:

f x y = x + y

Then either you don't use labels

z = f 2 3

or you use them for all args

z = f (y => 3, x => 2)

The compiler finds out the special => syntax, looks up for a matching
function name and labels, and then just reorders according to declaration

z = f 3 2

And you're back to the regular thing (you need to be a bit smart in
your match to handle currying, but you can drop that if it's too much
of a problem). If the labeled syntax can be recognized without too
much fuss, it won't interfere at all with the regular type analysis
since it will be separate prior pass.

> Which idiotic platforms?

All commercial UNIXes (AIX, IRIX, Solaris, OSF1) and VMS, plus NT, all
with threading correctly supported.

> I believe you made the right decision. It was a brave one too, since
> I bet there was a strong push for C++. Ada would be my choice too,
> given what you told me.

I didn't tell you the major thing ;-), namely that most of the team
writing the software are not trained software engineers but financial
and numerical people. C/C++ is just suicide in this environment (no
array bound checking, pointers all over the place, awful error
messages and brain-dead syntax...). I spent one whole year of my life
chasing out of bound access, memory management errors and random hard
to find crashes in a >500KSLOC of C software with crapping debugging
technology (Visual C++ released compiled software bugs usually go away
when you compile in debug mode, I still don't know how people tolerate
this...), I think this qualifies me for having an opinion on the topic
;-).

As for the strong push for C++, that was everyone but two people, but
management did trust us and choosed Ada after three monthes of
reflexion.  Now the C++ people are all saying C++ is legacy and doing
Java, and Java people are right now wondering about C#... Needless to
say their technology opinion is now 0 weighted as far as my management
is concerned. The software survived one merger, introduction of
distributed computations, growth of the team and is greatly satisfying
to business.

But even if written in Ada, the code keeps FP-like technique like
being stateless, having non mutable objects and provably not leaking
reference counting GC scheme (no cycles can be created with non
mutable objects).

> I trust the support has been good? 

Ups and downs, but our bugs do get fixed, our technical questions
about use of the technology get excellent and timely answer, and the
GNAT technology is definitely evolving in the right direction over the
years (new tools, new platforms).

Talking about support in the software tool business is kinda tricky,
for example I know about no other tools used here where users get
fixes from the vendor at all except at the mandatory update to new
versions.

Aren't you worried about lack of formal support for OCaml in your
company?

-- 
Laurent Guerby <guerby@acm.org>

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On 13 Apr 2001, Laurent Guerby wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > You should know that nothing is obvious when you're discussing the
> > OCaml type system :-). OK, that's not fair. It is obvious when
> > considered in the context of mathematically sound type systems. If
> > you're not well versed in the theory of such type systems, simple
> > explanations won't be helpful.  Check the caml-list for the mail of
> > the past few weeks titled "The Future of Labels" or somesuch.
> 
> I'm not super-versed in those things (I've read a whole bunch of
> papers and FP conference proeedings over the years but never
> implemented anything), but as I see it, raw labeled arguments
> are a near syntactic feature. Let's say you have:

No, unfortunately they aren't. Remember, this isn't Ada we're taling
about, but a higher order language with type inference and currying. 
The issues are different for Ada. Anyways, here's a pointer to the start
of the most recent discussion 

http://caml.inria.fr/archives/200103/msg00248.html

and here is Jacques' home page from which you can download any of his
publications which interest you 

http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/

> > Which idiotic platforms?
> 
> All commercial UNIXes (AIX, IRIX, Solaris, OSF1) and VMS, plus NT, all
> with threading correctly supported.

Ah. VMS support is hard to come by for non-mainstream languages. 

> > I believe you made the right decision. It was a brave one too, since
> > I bet there was a strong push for C++. Ada would be my choice too,
> > given what you told me.
> 
> I didn't tell you the major thing ;-), namely that most of the team
> writing the software are not trained software engineers but financial
> and numerical people. C/C++ is just suicide in this environment (no
> array bound checking, pointers all over the place, awful error
> messages and brain-dead syntax...). I spent one whole year of my life
> chasing out of bound access, memory management errors and random hard
> to find crashes in a >500KSLOC of C software with crapping debugging
> technology (Visual C++ released compiled software bugs usually go away
> when you compile in debug mode, I still don't know how people tolerate
> this...), I think this qualifies me for having an opinion on the topic
> ;-).

Well, debugging C is a nightmare. I just don't think that {} vs begin-end
is even a tiny part of why C sucks. Paraphrasing a former President

   It's the semantics, stupid. 

I remember how when I first played with Ada about five years ago I wrote a
smallish test program (between 500 and 1000 LOC) and after I silenced the 
compiler I was prepared to debug... and it worked the first time it ran!

Now, I have been able to get runtime crashes with Ada, and doesn't do
everything, but the difference between C/C++/ObjC and Ada is like night
and day.

> As for the strong push for C++, that was everyone but two people, but
> management did trust us and choosed Ada after three monthes of
> reflexion.  Now the C++ people are all saying C++ is legacy and doing
> Java, and Java people are right now wondering about C#... Needless to
> say their technology opinion is now 0 weighted as far as my management
> is concerned. 

:-)

> The software survived one merger, introduction of distributed
> computations, growth of the team and is greatly satisfying
> to business.

That's great to hear. I love non-defense Ada success stories. I'm not
anti-defense, I think everyone should have a shoulder launched SAM in
their garage (I've got two, and one extra for the wife :), but it's 
nice to hear of success in other industries.

> But even if written in Ada, the code keeps FP-like technique like
> being stateless, having non mutable objects and provably not leaking
> reference counting GC scheme (no cycles can be created with non
> mutable objects).

Well, that's good.

> > I trust the support has been good? 
> 
> Ups and downs, but our bugs do get fixed, our technical questions
> about use of the technology get excellent and timely answer, and the
> GNAT technology is definitely evolving in the right direction over the
> years (new tools, new platforms).

Yes, GNAT is great. I wouldn't have a lot of confidence in the future of
Ada were it not for GNAT.

> Talking about support in the software tool business is kinda tricky,
> for example I know about no other tools used here where users get
> fixes from the vendor at all except at the mandatory update to new
> versions.

Yes indeed, see my answer to your next question. 

> Aren't you worried about lack of formal support for OCaml in your
> company?

A little. The Consortium guarantees that if Projet Cristal folds we
get the rights to the source. I'm fairly confident that it won't fold. 
The compiler code is very understandable, though very sparsely documented. 
I guess I have a vested interest in the popularity of OCaml now. Ada too, 
BTW. I do my best to promote Ada when people aren't shoving their fingers
in their ears :-). I even do a bit of that on the Caml list.

Anyways, I wonder how important formal support *really* is. If you used
some proprietary language X compiler and the company that makes it folds,
where are you then? And, as you mention, most "support" from companies is 
a !@#$ing joke. OCaml source is under CVS web, so I can always get the
latest version, and get up to date bug fixes. So I'm not convinced
that just having some company which supports the software is very 
meaningful. 

Obviously GNAT is safer, since it is free software, but I wonder about
commercial compilers. I think if I were able to get Ada used in house I'd
pay for GNAT. However, it would be nicer if the most up to date version of
GNAT were always available. Even in that case, I'd want to pay, but it 
gives me the warm-fuzzies when lots of people are hacking on it.

-- Brian

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"Laurent Guerby" <guerby@acm.org> wrote in message
news:86wv8sfwec.fsf@acm.org...

> And I of course forgot the mandatory () for function calls without
> args silliness ;-).

No, I disagree with you about this one. It make reading far easier.
You *know* that it's a function, and not some variable.
Beside, it remind me of VB's abominationable () behaviour.

Re: newbie can't get exceptions to work!

[Mats Karlssohn]

Ayende Rahien wrote:
> 
> "Laurent Guerby" <guerby@acm.org> wrote in message
> news:86wv8sfwec.fsf@acm.org...
> 
> > And I of course forgot the mandatory () for function calls without
> > args silliness ;-).
> 
> No, I disagree with you about this one. It make reading far easier.
> You *know* that it's a function, and not some variable.
> Beside, it remind me of VB's abominationable () behaviour.

This is really the same issue as () vs. [] for arrays. I and many
other feel that, in the expresssion x := foo; knowing that foo is
a constant, a variable or a parameterless function, is just an
implementation detail. And thus having to use () to denote a
function call is an annoying exception to uniformity.


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"Mats Karlssohn" <mats@mida.se> wrote in message
news:3AD458AF.22279994@mida.se...
> Ayende Rahien wrote:
> >
> > "Laurent Guerby" <guerby@acm.org> wrote in message
> > news:86wv8sfwec.fsf@acm.org...
> >
> > > And I of course forgot the mandatory () for function calls without
> > > args silliness ;-).
> >
> > No, I disagree with you about this one. It make reading far easier.
> > You *know* that it's a function, and not some variable.
> > Beside, it remind me of VB's abominationable () behaviour.
>
> This is really the same issue as () vs. [] for arrays. I and many
> other feel that, in the expresssion x := foo; knowing that foo is
> a constant, a variable or a parameterless function, is just an
> implementation detail. And thus having to use () to denote a
> function call is an annoying exception to uniformity.

I can see their point, although I disagree.
Just as long as you don't go VB's way about it, I think everyone can accept
it.

Re: newbie can't get exceptions to work!

[Fraser Wilson]

Mats Karlssohn <mats@mida.se> writes:

> This is really the same issue as () vs. [] for arrays. I and many
> other feel that, in the expresssion x := foo; knowing that foo is
> a constant, a variable or a parameterless function, is just an
> implementation detail.

That's quite true.  And let's not forget that this () for
parameterless functions is what causes C++ code to be full of

	class C { int m_var; public int var() { return m_var; }};

I like Eiffel's way of doing it -- exported member variables are read
only outside the class and are thus indistinguishable from access
functions.

Also, imagine this:

   type T is (A, B, C);

   X : T := A();

Ouch!

Fraser.

Re: newbie can't get exceptions to work!

[Robert A Duff]

Fraser Wilson <blancolioni@blancolioni.org> writes:

> Also, imagine this:
> 
>    type T is (A, B, C);
> 
>    X : T := A();

Well, surely the fault there lies in the fact that Ada wants enumeration
literals to be functions, which is just plain silly in my opinion.

- Bob

Re: newbie can't get exceptions to work!

[Robert A Duff]

Laurent Guerby <guerby@acm.org> writes:

> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > On Mon, 9 Apr 2001, Ted Dennison wrote:
> > > That being the case, you'd like to strive for readability, not tersenes.
> > 
> > False dichotomy. In many cases, terse notation is more readable. 
> > 
> > Besides, I imagine English keywords, rather than French, German, Chinese,
> > or Hindi, were chosen for some reason. 

Umm, surely Ada keywords are in English because the design of Ada was
done for the United States Department of Defense, which tends to use
English (or at least a dialect of it).  It doesn't mean English is
"better" than anything else.

If I design a programming language, the keywords will be in English,
because that's all I know (unfortunately).

The original designer of Ada spoke French as his first language.

- Bob

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Tue, 10 Apr 2001, Robert A Duff wrote:
> 
> > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > On Mon, 9 Apr 2001, Ted Dennison wrote:
> > > > That being the case, you'd like to strive for readability, not tersenes.
> > > 
> > > False dichotomy. In many cases, terse notation is more readable. 
> > > 
> > > Besides, I imagine English keywords, rather than French, German, Chinese,
> > > or Hindi, were chosen for some reason. 
> 
> Umm, surely Ada keywords are in English because the design of Ada was
> done for the United States Department of Defense, which tends to use
> English (or at least a dialect of it).  It doesn't mean English is
> "better" than anything else.

Ummm, surely I know that's the case. The point is that if people are
familiar with a particular notation for a simple concept like a delimiter, 
they'll be able to read it, keyword or no, begin end, {}, if-fi do-od
case-esac, (), etc. 

> If I design a programming language, the keywords will be in English,
> because that's all I know (unfortunately).

But, as you suggested earlier, superficial similarity to C syntax may be 
advantageous for the purposes of achieving poularity. I'm arguing that
that is not horrible. 

-- Brian

Ada keywords (was: Re: newbie can't get exceptions to work!)

[Marin David Condic]

I understand why the official standard for Ada wouldn't allow keywords to be
translated to other languages - obvious possible problems with collisions of
keywords with identifiers & all the validation problems that would ensue.
However why would it be a problem for some company - say in France - that
wanted to use Ada (and had no porting issues) to go ahead and define their
own language. Call it "La Ada" or something else. It would be simple to
write a preprocessor that would translate French keywords into the
corresponding English keywords and so long as you never used the English
keywords for identifiers, it should pass straight into a standard Ada
compiler. Problem solved? (Aside from the fact that I generally dislike
preprocessors - this one at least wouldn't be much of an intrusion into
normal life since it doesn't change anything semantically.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wcc7l0t5wq1.fsf@world.std.com...
> Umm, surely Ada keywords are in English because the design of Ada was
> done for the United States Department of Defense, which tends to use
> English (or at least a dialect of it).  It doesn't mean English is
> "better" than anything else.
>
> If I design a programming language, the keywords will be in English,
> because that's all I know (unfortunately).
>
> The original designer of Ada spoke French as his first language.
>
> - Bob

Re: Ada keywords (was: Re: newbie can't get exceptions to work!)

[Jean-Pierre Rosen]

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


"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans le message news: 9av2gs$n7f$1@nh.pace.co.uk...
> I understand why the official standard for Ada wouldn't allow keywords to be
> translated to other languages - obvious possible problems with collisions of
> keywords with identifiers & all the validation problems that would ensue.
> However why would it be a problem for some company - say in France - that
> wanted to use Ada (and had no porting issues) to go ahead and define their
> own language. Call it "La Ada" or something else. It would be simple to
> write a preprocessor that would translate French keywords into the
> corresponding English keywords and so long as you never used the English
> keywords for identifiers, it should pass straight into a standard Ada
> compiler. Problem solved? (Aside from the fact that I generally dislike
> preprocessors - this one at least wouldn't be much of an intrusion into
> normal life since it doesn't change anything semantically.)
>
OK, let's play RBKD while he's not listening...

Well, of course, this is simply a matter of source representation, and the standard has nothing to say about source representation.
You can perfectly assume that the source representation for "if" is "si", no problem...

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <Pine.BSF.4.21.0104090948440.6359-100000@shell5.ba.best.com>, Brian
Rogoff says...
>
>On Mon, 9 Apr 2001, Ted Dennison wrote:
>False dichotomy. In many cases, terse notation is more readable. 

I didn't say there was a dichotomy, just that terse notation is not the goal,
and thus can't be put forth as a good unto itself, when weighed against other
factors.

>Besides, I imagine English keywords, rather than French, German, Chinese,
>or Hindi, were chosen for some reason. Assume that there are far more

I'd say that if the Hindi words for "begin" and "end" were used, it would still
be a better choice than using a single, practicly 1-dimensional character.


>> Curly-braces look quite a bit like parens at first glance (and sometimes upon
>> further glances too, depending on the font). Being a single chararacter, they
>> are fairly easy to miss with the eye, and are harder for the eye to properly
>> line up with distant lines (thus perhaps cause misapprehension of the proper
>> nesting level). In fact, the impression of pointing in a certian direction
>> causes a mild optical illusion which worsens the problem. Being mostly vertical,
>> they can also get accidentally hidden  behind the mouse pointer or an insertion
>> cursor.

>I've never had these problems, in many years of C, C++, and Java programming. 

I've had every single one of them. The problems lining begin-end blocks up is
particularly nasty when trying to understand someone else's code heavily
indented code, especially those who use less than 3 spaces for indentation.

>I have had the problem of not being able to pick out arrays easily in the
>code of Ada since nothing really stands out in Ada. A good syntax should
>make different things look different. 

Why do you *need* to pick out arrays?

I'd say that a good syntax should *not* point out differences that are of no
consequence to the user. Another good example of this principle is the use of
dot-notation syntax. In Ada MyObject.Field could refer to:
o   A record object with a field named "Field".
o   A pointer that is being dereferenced, which points to the above.
o   An object named Field in the package MyObject.
o   A routine named Field in the package MyObject.

These are all quite different things underneath the scenes, but as long as they
return a value of the correct type the user doesn't really care about that.
That's good for me as a reader, because that hides detail that I don't really
care about in trying to figure out the code in which it appears. If I start to
worry about how MyObject.Field gets its value, *then* I'll go track down its
definition. I take it you don't like this either?

>More BS. Arrays and strings are data, not functions. 

Ahhh, now we are getting into software metaphisics. At a low level, its all just
bits. But we don't (often) read the code in binary. 
At an equally silly high-level, we've got this "black box" program. Somewhere in
the middle, we have concepts like "arrays" and "functions". As our high-level
language source code representation is somewhere in the middle, there is going
to be a certain amount of abstraction. It sounds like you just like a smidge
less abstraction in your source code than I do. As a matter of taste, that's
fair enough. But I wouldn't try to claim that its somehow better that way. That
would be fighting history.


>My recollection is that the last time this was discussed Robert Dewar
>confirmed the statement that there was no discussion of using [] as array 
>brackets at all, the choice of () had to do with the DoD requirements on
>the character set to support (now) obsolete machines. All of this singing

That does seem to sound a bit familiar. Still, every now and then the bread
lands jelly-side-up. :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Mon, 9 Apr 2001, Ted Dennison wrote:

> In article <Pine.BSF.4.21.0104090948440.6359-100000@shell5.ba.best.com>, Brian
> Rogoff says...
> >
> >On Mon, 9 Apr 2001, Ted Dennison wrote:
> >False dichotomy. In many cases, terse notation is more readable. 
> 
> I didn't say there was a dichotomy, just that terse notation is not the goal,
> and thus can't be put forth as a good unto itself, when weighed against other
> factors.

When did I do that? Try reading what I wrote, not making up interpretations 
of your own. If two notations are equally readable, but one is terser
than the other, I assume you chose the more verbose one? 

> >Besides, I imagine English keywords, rather than French, German, Chinese,
> >or Hindi, were chosen for some reason. Assume that there are far more
> 
> I'd say that if the Hindi words for "begin" and "end" were used, it would still
> be a better choice than using a single, practicly 1-dimensional character.

I'll be sure not to use a language you design in the future!

> >> Curly-braces look quite a bit like parens at first glance (and sometimes upon
> >> further glances too, depending on the font). Being a single chararacter, they
> >> are fairly easy to miss with the eye, and are harder for the eye to properly
> >> line up with distant lines (thus perhaps cause misapprehension of the proper
> >> nesting level). In fact, the impression of pointing in a certian direction
> >> causes a mild optical illusion which worsens the problem. Being mostly vertical,
> >> they can also get accidentally hidden  behind the mouse pointer or an insertion
> >> cursor.
> 
> >I've never had these problems, in many years of C, C++, and Java
> >programming. 
> 
> I've had every single one of them.

What can I say. Some people learn one language and like it so much that they 
are unable to get past superficial syntactic issues in other languages. 
I've never been much of a syntax fanatic, though I do have preferences. 
Lisp, Forth, Haskell, and others never really caused me pain syntax-wise, 
though I admit getting used to their semantics took a fair bit of work. 
C and Ada are practically the same to me from a syntax point of view. I
suspect you're just used to very few languages. 

> The problems lining begin-end blocks up is
> particularly nasty when trying to understand someone else's code heavily
> indented code, especially those who use less than 3 spaces for indentation.

Poorly indented code in any language doesn't read well, and that includes
Ada.  And 2 spaces works just fine, thanks, though I indent 4 when I have
the choice. 

> >I have had the problem of not being able to pick out arrays easily in the
> >code of Ada since nothing really stands out in Ada. A good syntax should
> >make different things look different. 
> 
> Why do you *need* to pick out arrays?

Because I am a programmer. Reading code is just one of those things that I
do from time to time. Given that arrays and functions are different,
programmers who read other people's code need to know what's what when
reading. 

> I'd say that a good syntax should *not* point out differences that are of no
> consequence to the user. 

Can you treat an functions and arrays the same way? Or is there something
about arrays and strings that suggests that they are different? 

> These are all quite different things underneath the scenes, but as long as they
> return a value of the correct type the user doesn't really care about that.
> That's good for me as a reader, because that hides detail that I don't really
> care about in trying to figure out the code in which it appears. If I start to
> worry about how MyObject.Field gets its value, *then* I'll go track down its
> definition. I take it you don't like this either?

You take it wrong. However, I wouldn't mind if a different symbol were
used for method invocation in C++, since it really isn't the same thing 
as accessing a field. Also, I much prefer Ada's unification of . and -> 
syntax, since I really don't care in this case. As far as package and
record access, they're pretty close. In a language with first class
modules, records and modules would in fact be the same thing. Cayenne is 
that kind of language. 

> >More BS. Arrays and strings are data, not functions. 
> 
> Ahhh, now we are getting into software metaphisics. At a low level, its all just
> bits.

Thanks for the lesson. This is really deep stuff. You must be really
smart. 

Don't like sarcasm? Don't talk down to your interlocutors.

You typically use arrays as containers. You get slices. You do lots of
things that you don't do with functions. And vice versa. rather than 
pretend that they are the same, I say just accept reality and give them a 
diferent syntax. Of course, Ichbiah didn't have that choice. there was no
discussion, so he had to do what he did. Sure, you can find some advantages 
for this, but it looks like a flaw to me!

> At an equally silly high-level, we've got this "black box" program. Somewhere in
> the middle, we have concepts like "arrays" and "functions". As our high-level
> language source code representation is somewhere in the middle, there is going
> to be a certain amount of abstraction. It sounds like you just like a smidge
> less abstraction in your source code than I do.

Sounds like you'd prefer a language where strings, arrays, and functions
all had exactly the same restrictions, or were possibly even just
implemented exactly the same way. Perhaps the untyped lambda calculus is 
what you'd like to program in. As a matter of taste, that's fair enough. 
Etc., etc...

> >My recollection is that the last time this was discussed Robert Dewar
> >confirmed the statement that there was no discussion of using [] as array 
> >brackets at all, the choice of () had to do with the DoD requirements on
> >the character set to support (now) obsolete machines. All of this singing
> 
> That does seem to sound a bit familiar. Still, every now and then the bread
> lands jelly-side-up. :-)

But, given that two of the Reviewer Roberts seem to prefer [] (just need 
Robert Eachus for the hat trick :) over () I think it looks more like 
a mistake, or at least a suboptimal choice. Anyone know what Jean Ichbiah's 
take on this is, as in would he have done this if he didn't have to? Pretty 
clearly Niklaus Wirth favors [] ...

-- Brian

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <Pine.BSF.4.21.0104091353580.6359-100000@shell5.ba.best.com>, Brian
Rogoff says...
>
>> Why do you *need* to pick out arrays?
>
>Because I am a programmer. Reading code is just one of those things that I
>do from time to time. Given that arrays and functions are different,
>programmers who read other people's code need to know what's what when
>reading. 

I had guessed that you are a programmer. I was hoping for a reason that's a
little more specific. I still don't see why someone trying to track down an
unrelated problem in some source code always needs to know that a particular
value came out of an array instead of a function.

>> worry about how MyObject.Field gets its value, *then* I'll go track down its
>> definition. I take it you don't like this either?
>
>You take it wrong. However, I wouldn't mind if a different symbol were

I'm confused. Exactly why is it that you consider "MyObject.Field" (record or
function call) ok, but "MyObject(Index)" (array or function call) bad?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:KgqA6.1193$FY5.91793@www.newsranger.com...
> In article <Pine.BSF.4.21.0104091353580.6359-100000@shell5.ba.best.com>,
Brian
> Rogoff says...
> >
> >> Why do you *need* to pick out arrays?
> >
> >Because I am a programmer. Reading code is just one of those things that
I
> >do from time to time. Given that arrays and functions are different,
> >programmers who read other people's code need to know what's what when
> >reading.
>
> I had guessed that you are a programmer. I was hoping for a reason that's
a
> little more specific. I still don't see why someone trying to track down
an
> unrelated problem in some source code always needs to know that a
particular
> value came out of an array instead of a function.

What about just *understanding* a code?
For large works, you need to read a lot of code, and knowing that X is an
array can save you trying to understand what is going on here.
However, if we are talking about it. Implementing it in [1,2,3] no [1][2][3]
is clearer, IMO.

An array is a container for data, a function is something that return data
based on some code that is in it.
Implementing arrays & functions in a way which the reader can't visually
detect which one is which is wrong.

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <9atph1$n3h$1@taliesin.netcom.net.uk>, Ayende Rahien says...
>
>
>"Ted Dennison" <dennison@telepath.com> wrote in message
>news:KgqA6.1193$FY5.91793@www.newsranger.com...
>> little more specific. I still don't see why someone trying to track down
>> an unrelated problem in some source code always needs to know that a
>> particular value came out of an array instead of a function.
>
>What about just *understanding* a code?
>For large works, you need to read a lot of code, and knowing that X is an

That's my exact point. For small works, its OK to try to take in every little
detail about how everything works in at once. If you are a reaonsably sharp
person, you ought to be able to do it. But attempting to do that in a large
program would be disasterous. If you can do that, you should be off defeating
Kasparof and Deep Blue, not toying around with programming. :-)

For a large program, you need to be able to read things in general first,
without getting bogged down in nitty implementation details. You'd like to know
generally where data comes from in the system, which you should be able to get
from the object/subprogram name. But how that data is retrieved (record, array,
complicated calculation, etc.) is only important for the particular path that
contains the bug you are looking for (or other paths that you suspect might).
There are only so many things I can keep in my head at once. If the syntax
provides detailed implementation information when I don't need it, it is
squandering some of my brain space. Perhaps some of you are just much better
endowed than I in that regard. :-)

>An array is a container for data, a function is something that return data
>based on some code that is in it.
When its just sitting in memory doing nothing, yes its just data. But if you
want to access that data by indexing into the array, that takes code to
accomplish. We are not talking about an array, we are talking about an array
*indexing operation*. This is something that returns data, using a canned
function that maps one discrete value to a (hopefully) pre-loaded object using a
simple mathamatical calculation. There is code involved, just like with any
function. In fact we could, if we wanted, write a (pragma inlined) function that
did the exact same thing and generates the exact same object code. But since
this particular function is so common and useful, it got its own type and
syntax. That doesn't make it fundametally different from a function.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Fraser Wilson]

"Ayende Rahien" <Dont@spam.me> writes:

> An array is a container for data, a function is something that return data
> based on some code that is in it.

To me, that's an implementation detail.  In the circumstances where
arrays and functions are indistinguishable syntactically, they do
essentially the same thing -- map a value or values to another value.

Seguing into a topic from some other corner of the thread, I really
like the idea, in languages that allow you to define operators, of
assigning precedences only to related operators, and requiring
parentheses for the rest.  What an elegant solution.

User-defined new operators would be entirely inappropriate for Ada of
course.

Fraser.

Re: newbie can't get exceptions to work!

[Mats Karlssohn]

Ted Dennison wrote:
> 
> In article <Pine.BSF.4.21.0104090948440.6359-100000@shell5.ba.best.com>, Brian
> Rogoff says...
%<
> >I have had the problem of not being able to pick out arrays easily in the
> >code of Ada since nothing really stands out in Ada. A good syntax should
> >make different things look different.
> 
> Why do you *need* to pick out arrays?
%<
> These are all quite different things underneath the scenes, but as long as they
> return a value of the correct type the user doesn't really care about that.
> That's good for me as a reader, because that hides detail that I don't really
> care about in trying to figure out the code in which it appears. If I start to
> worry about how MyObject.Field gets its value, *then* I'll go track down its
> definition. I take it you don't like this either?

Just to mention it (I do not intend to start another too long argument
:)

Could we get the language to handle dispatching calls that in some of
the
cases dispatches to a function and in some cases just get the return
value
from one array *big smile* ? I've quite recently implemented a hirarchy
with these properties by wrapping the arrays in functions. It would be
nice if the compiler could generate the wrappers by itself. But maybe
this
isn't a common enough problem ? 

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <3AD2AF50.6B5DD470@mida.se>, Mats Karlssohn says...
>
>Could we get the language to handle dispatching calls that in some of
>the
>cases dispatches to a function and in some cases just get the return
>value
>from one array *big smile* ? I've quite recently implemented a hirarchy
>with these properties by wrapping the arrays in functions. It would be
>nice if the compiler could generate the wrappers by itself. But maybe

Interesting example. :-)

First off, I don't think it would be consistent to do this kind of thing unless
you also allowed an array to be a tagged type (not a component, but a tagged
type in and of itself). Otherwise, what's the syntax for deciding what array to
use? There may be some neat way of doing that, but I don't see it.

But let's pretend that wasn't an issue (now we're off in never-never land of
course). In other posts I've been equating array indexing to an automaticly
pragma-inlined canned mapping function. 

Now I think dispatching can be split into two cases: dynamic and static. Static
dispatch is just the insertion of the proper type's function call into the
generated code. It shouldn't be too big of a deal for a compile to insert the
indexing code rather than a function call when appropriate.

For dynamic dispatch, the compiler essentially generates a big case statement,
based on the object's tag, where each branch contains a function call. You could
also think of it as a jump (to subroutine) table. Now if the compiler is just
doing a table lookup and JSR'ing to the result, then there's going to be a
subroutine call anyway. So you aren't really buying anything by not having to
write that function that does nothing but index into an array. 

However, if it actually is a big case statement, then there would be nothing
wrong with having an inlined routine on one of the branches. In that case it
would be doable. (Is pragma inline allowed for a dispatching call?)


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Mark Biggar]

Ted Dennison wrote:
> (Is pragma inline allowed for a dispatching call?)

Sure, but like any progam inline there is nothing in the LRM that 
requires that the compiler actually do anything with it.  Remember,
a compiler is free to totaly ingore all pragma inlines. I imagine
that most (if not all) Ada compilers don't do anything special and
just ignore pragma inline on dymnamic dispatching calls.

--
mark.a.biggar@home.com

Re: newbie can't get exceptions to work!

[Mats Karlssohn]

Mark Biggar wrote:
> 
> Ted Dennison wrote:
> > (Is pragma inline allowed for a dispatching call?)
> 
> Sure, but like any progam inline there is nothing in the LRM that
> requires that the compiler actually do anything with it.  Remember,
> a compiler is free to totaly ingore all pragma inlines. I imagine
> that most (if not all) Ada compilers don't do anything special and
> just ignore pragma inline on dymnamic dispatching calls.

Without thinking it through, shouldn't it be quite easy just to
replace the jump-to-subroutine in the (equivalent of a) case statement
with the inlined code ? Maybe not, I guess it depends on how the
lookup is done. 

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: newbie can't get exceptions to work!

[Samuel T. Harris]

Mats Karlssohn wrote:
> 
> Mark Biggar wrote:
> >
> > Ted Dennison wrote:
> > > (Is pragma inline allowed for a dispatching call?)
> >
> > Sure, but like any progam inline there is nothing in the LRM that
> > requires that the compiler actually do anything with it.  Remember,
> > a compiler is free to totaly ingore all pragma inlines. I imagine
> > that most (if not all) Ada compilers don't do anything special and
> > just ignore pragma inline on dymnamic dispatching calls.
> 
> Without thinking it through, shouldn't it be quite easy just to
> replace the jump-to-subroutine in the (equivalent of a) case statement
> with the inlined code ? Maybe not, I guess it depends on how the
> lookup is done.
> 

Since a dynamic dispatching call involves a access to a class-wide
type and the caller class does not have knowledge at compile time
of ALL the tagged types under the class-wide type, the compiler
cannot inline while compiling the call. It would have to insert
the appropriate inlining during some binding stage just before
linking when all the compilation artifacts are available.

Many compilers require the body of an inlined subprogram
to be _already_ compiled in order for inlining to work. Such
compilers will definitely not suppor the notion of inline
dispatching calls.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: newbie can't get exceptions to work!

[Pat Rogers]

"Samuel T. Harris" <u61783@gsde.hou.us.ray.com> wrote in message
news:3AD46B6E.6A8592A@gsde.hou.us.ray.com...
<snip>
> Since a dynamic dispatching call involves a access to a class-wide
> type <snip>

Too strong.  Dynamic dispatching requires a class-wide *value*, which thus
includes class-wide parameters and class-wide view conversions, in addition
to dereferenced class-wide access values.  It is certainly the case that
class-wide access types are common due to their flexibility, but that isn't
the only way to get the class-wide value that then causes dispatching.

Lest there by any confusion (Sam already knows this, of course), there is
really only one rule here: dynamic dispatching only occurs when a class-wide
value is passed as the actual parameter to a primitive operation of a type
in the derivation class.


---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com        Real-Time/OO Languages
progers@classwide.com          Hard Deadline Schedulability Analysis
(281)648-3165                          Software Fault Tolerance

Re: newbie can't get exceptions to work!

[Mats Karlssohn]

"Samuel T. Harris" wrote:
%<
> Since a dynamic dispatching call involves a access to a class-wide
> type and the caller class does not have knowledge at compile time
> of ALL the tagged types under the class-wide type, the compiler
> cannot inline while compiling the call. It would have to insert
> the appropriate inlining during some binding stage just before
> linking when all the compilation artifacts are available.

Yes, I see. Of the compilers in the market, how many already has
parts of such functionality in the binder/prelinker/linker ?
Can anyone give an educated guess ?

> Many compilers require the body of an inlined subprogram
> to be _already_ compiled in order for inlining to work. Such
> compilers will definitely not suppor the notion of inline
> dispatching calls.

OK, that makes sense, tnx for clering my mind up!


-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: newbie can't get exceptions to work!

[Mats Karlssohn]

Ted Dennison wrote:
> 
> In article <3AD2AF50.6B5DD470@mida.se>, Mats Karlssohn says...
> >
> >Could we get the language to handle dispatching calls that in some of
> >the
> >cases dispatches to a function and in some cases just get the return
> >value
> >from one array *big smile* ? I've quite recently implemented a hirarchy
> >with these properties by wrapping the arrays in functions. It would be
> >nice if the compiler could generate the wrappers by itself. But maybe
> 
> Interesting example. :-)

Thanks, I try to be an interesting guy ;)

> First off, I don't think it would be consistent to do this kind of thing unless
> you also allowed an array to be a tagged type (not a component, but a tagged
> type in and of itself). Otherwise, what's the syntax for deciding what array to
> use? There may be some neat way of doing that, but I don't see it.

In my example the arrays were components of a tagged record, but
generalizing them to be tagged types themselves would be at least
interesting, possibly fruitful.

To clarify: I made an hirarchy (spl ?) of tagged records, one
dispatched function takes an integer argument and returns a
string. For some cases, the string needs to be calculated from
other components in the record. For other cases the string is
constant only depending on the integer, and thus (IMHO) best
implemented as an array of (constant) strings, so I had to
implement (inlined) functions that returns a value from the
array. Implementing the functions were no major hassle, since
there were quite few of them, BUT it feels kind of stupid to
do it this way.

As I'm writing this I realize that I should have tried to
implement the lookup functions as a generic function. I'll
have to try that (shouldn't be a big problem I guess).

BTW, the system I'm talking about in the example is part of
a status monitoring for distributed embedded processors. The
part I'm discussing is translating numeric status codes to
human readable messages.

> But let's pretend that wasn't an issue (now we're off in never-never land of
> course). In other posts I've been equating array indexing to an automaticly
> pragma-inlined canned mapping function.

Yes, IMHO that's a correct way of viewing it. I do have some
background in formal logic so I can se most relations as mapping
functions. However, I can also see the view that an array is just
data storage (thus ignoring the work needed to access the data).

> Now I think dispatching can be split into two cases: dynamic and static. Static
> dispatch is just the insertion of the proper type's function call into the
> generated code. It shouldn't be too big of a deal for a compile to insert the
> indexing code rather than a function call when appropriate.

Yes.

> For dynamic dispatch, the compiler essentially generates a big case statement,
> based on the object's tag, where each branch contains a function call. You could
> also think of it as a jump (to subroutine) table. Now if the compiler is just
> doing a table lookup and JSR'ing to the result, then there's going to be a
> subroutine call anyway. So you aren't really buying anything by not having to
> write that function that does nothing but index into an array.

That's right I guess. What is saved is the work of writing the
lookup functions (not a big deal) and more important we save
som cluttering of the source. I'd say that it'd be easier to
read if the compiler automatically generated the lookup function.

> However, if it actually is a big case statement, then there would be nothing
> wrong with having an inlined routine on one of the branches. In that case it
> would be doable. (Is pragma inline allowed for a dispatching call?)

Exactly my point. I don't know if it's legal or not.

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: newbie can't get exceptions to work!

[Robert A Duff]

Mats Karlssohn <mats@mida.se> writes:

> Yes, IMHO that's a correct way of viewing it. I do have some
> background in formal logic so I can se most relations as mapping
> functions. However, I can also see the view that an array is just
> data storage (thus ignoring the work needed to access the data).

I think it depends on how the array is being used.  For example, I think
of a String as a sequence of characters, not as a mapping from a subset
of the positive integers to characters.  Arrays (in Ada) are a fairly
low-level abstraction, and can be used to implement many different
higher-level concepts.

- Bob

Re: newbie can't get exceptions to work!

[Matthew Woodcraft]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> My recollection is that the last time this was discussed Robert Dewar
> confirmed the statement that there was no discussion of using [] as array 
> brackets at all, the choice of () had to do with the DoD requirements on
> the character set to support (now) obsolete machines. All of this singing
> and dancing about the virtues of this choice are post facto
> rationalizations.

But it does allow an interesting possibility for a language extension: []
could be allowed as a user-defined 'operator' for array-like types, without
any fear of introducing ambiguities with the existing forms of array
reference. Not very elegant, maybe, but practical and safe.

-M-

Re: newbie can't get exceptions to work!

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> On Sat, 7 Apr 2001, Robert A Duff wrote:
> > I suspect that to make a *popular* language these days, you have to make
> > it look like C (yuck), 
> 
> Python isn't popular? Visual Basic? 

Granted.  And Lisp and Smalltalk are still popular in in their niche.
And Perl is popular, though I find it an abomination.

> I don't think you need to go quite as far as Cyclone. Dump "begin end" and
> use "{ }".

Well, it's not just "begin end", but also "if ... end if", "procedure P
... end P", and so forth.

Anyway, I like being able to see what the "end" is end of (as in "end
if" or "end P"), so I don't like just "}".

>... If you keep the procedure/function distinction, use shorter
> names.

I would call them both "procedure".  I find the C syntax for functions
very unreadable -- it's hard to tell a procedure header from an
expression.

>... Use [] for arrays.

Agreed.

> Use Pascal notation for pointers.

Yes!  I hate ".all", and I long for the days of "X^.Y".

>... Provide some 
> shortcut operators like C.

OK, but I might decide to call it Incr(X) instead X++.

>... Keep Ada's modes. OK, so the language may look
> a bit different from Ada syntactically but I think it could stay in the
> spirit of Ada semantically. 
> 
> > and you have to have enough money to generate large amounts of hype.  Sigh.
> 
> It's not clear to me that that approach is such a win. There is something
> of a Java backlash too.

If I could design a language that inspired as much backlash as Java,
I would consider myself quite a success!

>... What do I know though, I write OCaml these days. I'd 
> rather be an idealist than someone who follows the PL trends.

- Bob

Re: newbie can't get exceptions to work!

[James Rogers]

Robert A Duff wrote:
> 
> Well, it's not just "begin end", but also "if ... end if", "procedure P
> ... end P", and so forth.
> 
> Anyway, I like being able to see what the "end" is end of (as in "end
> if" or "end P"), so I don't like just "}".

Even more interesting is the common practice among experienced C,
C++, and Java programmers to comment the closing "}" with an
indication of the block being closed:

  } // end if

or

  } // end getCount()

If this is a common practice, then how are "{}" better than
"begin end"? The need to use "{}" then follow up with clarifying
comments indicates that "{}" is, in fact, less readable.


Jim Rogers
Colorado Springs, Colorado USA

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Tue, 10 Apr 2001, James Rogers wrote:
> Robert A Duff wrote:
> > 
> > Well, it's not just "begin end", but also "if ... end if", "procedure P
> > ... end P", and so forth.
> > 
> > Anyway, I like being able to see what the "end" is end of (as in "end
> > if" or "end P"), so I don't like just "}".
> 
> Even more interesting is the common practice among experienced C,
> C++, and Java programmers to comment the closing "}" with an
> indication of the block being closed:
> 
>   } // end if
> 
> or
> 
>   } // end getCount()

That's a very good point. I use that practice in all of my code where the
length of a subprogram or conditional becomes a bit too long. I suppose,
using the kind of argument used to justify some Ada restrictions, that
someone could say that I should factor the code better. :-)

> If this is a common practice, then how are "{}" better than
> "begin end"? The need to use "{}" then follow up with clarifying
> comments indicates that "{}" is, in fact, less readable.

In any case, it's also dead easy to do this with {} as long as there is a 
trailing ";", so this anti {} argument still flounders. 

proc P is { } P;

if cond then {} elsif cond {} endif; -- ok, somewhat superfluous

package P is {
private
} P;

etc.

Please, when I say replace begin end with {} that doesn't mean idiotically
adopt every C mistake, OK? Where is RBKD, who understands the idea of
trying to argue both sides as a way to get to the bottom of things?

In any case, this is an excellent feature of Ada. 

-- Brian

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <Pine.BSF.4.21.0104092047500.4414-100000@shell5.ba.best.com>, Brian
Rogoff says...
>
>On Tue, 10 Apr 2001, James Rogers wrote:
>> Robert A Duff wrote:
>> Even more interesting is the common practice among experienced C,
>> C++, and Java programmers to comment the closing "}" with an
>> indication of the block being closed:
>> 
>>   } // end if
>> 
>> or
>> 
>>   } // end getCount()
>
>That's a very good point. I use that practice in all of my code where the
>length of a subprogram or conditional becomes a bit too long. I suppose,
>using the kind of argument used to justify some Ada restrictions, that
>someone could say that I should factor the code better. :-)

I should point out that if your putatative language were to *require* those
endings somehow (eg: ditch the "// end" from the above constuctions), it would
annul most (if not all) of my complaints against using curly-braces.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[Ayende Rahien]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:pcLA6.2553$FY5.178009@www.newsranger.com...
> In article <Pine.BSF.4.21.0104092047500.4414-100000@shell5.ba.best.com>,
Brian
> Rogoff says...
> >
> >On Tue, 10 Apr 2001, James Rogers wrote:
> >> Robert A Duff wrote:
> >> Even more interesting is the common practice among experienced C,
> >> C++, and Java programmers to comment the closing "}" with an
> >> indication of the block being closed:
> >>
> >>   } // end if
> >>
> >> or
> >>
> >>   } // end getCount()
> >
> >That's a very good point. I use that practice in all of my code where the
> >length of a subprogram or conditional becomes a bit too long. I suppose,
> >using the kind of argument used to justify some Ada restrictions, that
> >someone could say that I should factor the code better. :-)
>
> I should point out that if your putatative language were to *require*
those
> endings somehow (eg: ditch the "// end" from the above constuctions), it
would
> annul most (if not all) of my complaints against using curly-braces.

Brian Rogoff suggested this:
procedure P(){
} P;

if (condition) {
} if;

I think it has the best of both worlds.

Re: newbie can't get exceptions to work!

[James Rogers]

Ayende Rahien wrote:
> Brian Rogoff suggested this:
> procedure P(){
> } P;
> 
> if (condition) {
> } if;
> 
> I think it has the best of both worlds.

Now why must we begin to place boolean expressions inside parens?
According to the logic used to defend [] versus () for arrays,
doesn't this make an "if" statement look like a function call
followed by a code block? 

Also, the supposed virtues of "{}" (imho) fade when you need to 
add a label to the closing brace. You now manage to save exactly
two characters (en), but you must add an additional semicolon.

In C, C++, and Java you can entirely omit the "{}", making the
"if" statement unbracketed. That is a bad practice in those
languages. It should not be adopted in any other langauges.

Another point of observation concerning "{}". Look at the code
for anonymous inner classes in Java. I am not convinced that
curly braces are better than Ada's "begin/end" pairs.

For those not familiar with Java anonymous inner class syntax I
offer the following example:

this.addWindowListener( new WindowAdapter() {
   public void windowClosed(WindowEvent e) {
      System.exit(0);
   }
});

Jim Rogers
Colorado Springs, Colorado USA

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Wed, 11 Apr 2001, James Rogers wrote:
> Ayende Rahien wrote:
> > Brian Rogoff suggested this:
> > procedure P(){
> > } P;
> > 
> > if (condition) {
> > } if;
> > 
> > I think it has the best of both worlds.
> 
> Now why must we begin to place boolean expressions inside parens?

If you read my original off the cuff proposal, you'll note that I didn't 
put the boolean expressions in parens, and I used endif, and elsif. 

Note that Dylan, which is an infix Lisp-like language with an Algolesque 
syntax, does parenthesize booleans in conditionals. I prefer the Ada
choice here too.

> According to the logic used to defend [] versus () for arrays,
> doesn't this make an "if" statement look like a function call
> followed by a code block? 

According to the logic used for defending () versus [] for arrays, we
should just make everything look the same, like Lisp :-). 

> Also, the supposed virtues of "{}" (imho) fade when you need to 
> add a label to the closing brace. You now manage to save exactly
> two characters (en), but you must add an additional semicolon.

I'd make it optional, but, as in Ada, force matching if it is included. 
That way you get the benefit for short blocks.

> In C, C++, and Java you can entirely omit the "{}", making the
> "if" statement unbracketed. That is a bad practice in those
> languages. It should not be adopted in any other langauges.

Agreed. 

> Another point of observation concerning "{}". Look at the code
> for anonymous inner classes in Java. I am not convinced that
> curly braces are better than Ada's "begin/end" pairs.

I explicitly said I thought that the syntax is *not* better, didn't I?
OTOH, I don't think that it's that much worse of a choice, either. I 
agreed with Laurent that for a relatively unbiased programmer (I know,
that's an oxymoron) it's really a non-issue, and that if you accept the 
idea that many programmers who are familiar with C syntax are unable to 
adapt, a strategy for a new Ada like language to be successful would
include making it look a bit more like C.

-- Brian

Re: newbie can't get exceptions to work!

[Mats Karlssohn]

Brian Rogoff wrote:
%<
> According to the logic used for defending () versus [] for arrays, we
> should just make everything look the same, like Lisp :-).

Or Perl... =)

--
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Thu, 12 Apr 2001, Mats Karlssohn wrote:
> Brian Rogoff wrote:
> %<
> > According to the logic used for defending () versus [] for arrays, we
> > should just make everything look the same, like Lisp :-).
> 
> Or Perl... =)

Huh? Perl uses special characters in variable names to carve up the
namespace, so Perl is not a good example of unifying similar notations. 
Or, maybe you mean that most Perl code looks like undiscriminated
line-noise? Well, I won't argue with that ;-)

I guess the first step in unifying Ada notations (if you think () is so
great :) is to get rid of the attribute syntax and replace that with
function call notation. This would actually be a bit more consistent too,
since you can't define a new 'Image but you can define a new Image(X) :-)

-- Brian

Re: newbie can't get exceptions to work!

[Mats Karlssohn]

Brian Rogoff wrote:
[SNIP - perl stuff]
>
> I guess the first step in unifying Ada notations (if you think () is so
> great :) is to get rid of the attribute syntax and replace that with
> function call notation. This would actually be a bit more consistent too,
> since you can't define a new 'Image but you can define a new Image(X) :-)

This is actually a really good point, I've always (almost anyway)
wondered why the attributes were designed to have the syntax that they
have today. Not that I find them that annoying, but in half of their
use the attributes behaves just like functions, the other half (when
setting object'size := 14; for example) is another matter.

Do someone remember the history behind this ?

-- 
Mats Karlssohn, developer                         mailto:mats@mida.se  
Mida Systemutveckling AB                          http://www.mida.se
Box 64, S-732 22 ARBOGA, SWEDEN
Phone: +46-(0)589-89808   Fax: +46-(0)589-89809

Re: newbie can't get exceptions to work!

[Jean-Pierre Rosen]

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


"Mats Karlssohn" <mats@mida.se> a �crit dans le message news:
3ADBEAE0.7D69463E@mida.se...
> [...], I've always (almost anyway)
> wondered why the attributes were designed to have the syntax that they
> have today. Not that I find them that annoying, but in half of their
> use the attributes behaves just like functions, the other half (when
> setting object'size := 14; for example) is another matter.
>
> Do someone remember the history behind this ?
>
Here is how I explain it to my students.
When you declare a type, the compiler defines some constants and functions
that can be helpful. Now the problem is that the compiler must find names
for these constants and functions, and those names must not conflict with
names defined by the user. The trick is that the compiler allows itself to
put an apostrophe in the name, something that is not allowed to regular
identifiers. Therefore, there can be no conflict. In short, when you define:
   type My_Int is range 0..100;
the compiler adds the declarations:
   My_Int'First : constant My_Int := 0;
   My_Int'Last : constant My_Int := 100;
   function My_Int'Image (Item : My_Int) return String;
   etc.

So, if you see attributes not as special constructs, but simply as
identifiers with a special character in them, they are not different from
other language constructs, and allowing the user to define them would defeat
their purpose. Actually, I find it quite nice that their is no "magic"
identifier recognized in a special way by the compiler, like sizeof() in C
for example.
With attributes, you know without ambiguity what is defined by the compiler
and what is defined by the user.

(David: if you want to put this in the FAQ, you are welcome)

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: newbie can't get exceptions to work!

[Ted Dennison]

In article <3AD4D3C2.E45751D9@worldnet.att.net>, James Rogers says...
>Also, the supposed virtues of "{}" (imho) fade when you need to 
>add a label to the closing brace. You now manage to save exactly
>two characters (en), but you must add an additional semicolon.

Well...since the incredible terseness was at the root of most of my problems
with "}", arguing that it is no longer terse is a sure recipe for having us
chasing our tails. :-)  And acutally, you save *less* than that (it might even
be *more* typing), because those endings are not required in Ada, as we propose
they will be in this new language.

I'd actually agree with you that its silly. However, with the extra stuff on the
end its at least not *harmful* any more, so I can live with the sillyness. I
don't for a minute buy the argument that people stay away from Ada because they
don't want to type "end" instead of "}". That's an *excuse*, not a serious
argument. But some folks here seem to honestly believe it, and this ought to at
least make them happy.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: newbie can't get exceptions to work!

[James Rogers]

Ted Dennison wrote:
> I'd actually agree with you that its silly. However, with the extra stuff on the
> end its at least not *harmful* any more, so I can live with the sillyness. I
> don't for a minute buy the argument that people stay away from Ada because they
> don't want to type "end" instead of "}". That's an *excuse*, not a serious
> argument. But some folks here seem to honestly believe it, and this ought to at
> least make them happy.

I remember when most students learned Pascal as their first
programming language. Several students were more comfortable with C
if they added the following bits of code:

#define BEGIN {
#define END }

They could then write their source code without the "{}" pairs, and
the proprocessor would make the appropriate substitutions.
I also remember that serious C enthusiasts found this adjustment to
be revolting.

Example:

#define BEGIN {
#define END }
#include <stdio.h>

int main ()
BEGIN
   printf("Hello World\n");
END

Jim Rogers
Colorado Springs, Colorado USA

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Tue, 10 Apr 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > On Sat, 7 Apr 2001, Robert A Duff wrote:
> > > I suspect that to make a *popular* language these days, you have to make
> > > it look like C (yuck), 
> > 
> > Python isn't popular? Visual Basic? 
> 
> Granted.  And Lisp and Smalltalk are still popular in in their niche.
> And Perl is popular, though I find it an abomination.
> 
> > I don't think you need to go quite as far as Cyclone. Dump "begin end" and
> > use "{ }".
> 
> Well, it's not just "begin end", but also "if ... end if", "procedure P
> ... end P", and so forth.
> 
> Anyway, I like being able to see what the "end" is end of (as in "end
> if" or "end P"), so I don't like just "}".

Right, I responded in another post that this is a good thing. If we keep 
Ada's approach to semi-colons then we can easily keep those trailing
names. Incidentally, I hate the optional {} on if rule of C, and I always
found Ada's semi-colon as terminator rule easy. I realize that's another 
flamewar, but I'm just shooting out an opinion.

> >... If you keep the procedure/function distinction, use shorter
> > names.
> 
> I would call them both "procedure".  I find the C syntax for functions
> very unreadable -- it's hard to tell a procedure header from an
> expression.

I agree, but since you proposed going C like, let's go for shorter names,
like proc. And no "returns" either, let's regress to a Pascalish :.

> >... Use [] for arrays.
> 
> Agreed.
> 
> > Use Pascal notation for pointers.
> 
> Yes!  I hate ".all", and I long for the days of "X^.Y".

Phew. Good that we're getting some agreement. 

> >... Provide some 
> > shortcut operators like C.
> 
> OK, but I might decide to call it Incr(X) instead X++.

OK. I think C folks will whine though. I have a generic package for these
in Ada, and I use Incr and Decr. 

> >... Keep Ada's modes. OK, so the language may look
> > a bit different from Ada syntactically but I think it could stay in the
> > spirit of Ada semantically. 
> > 
> > > and you have to have enough money to generate large amounts of hype.  Sigh.
> > 
> > It's not clear to me that that approach is such a win. There is something
> > of a Java backlash too.
> 
> If I could design a language that inspired as much backlash as Java,
> I would consider myself quite a success!

:-). 

I think if the language could generate code as good as C, and be at a
significantly higher level, you might get some interest. IMO, the
important thing is to have a good compiler that runs on lots of machines. 
A simple command line job, no point in wasting time with an IDE until 
enough folks are interested. 

Anyways, Python, Tcl, Ruby and others didn't have large marketing budgets. 

-- Brian

Re: newbie can't get exceptions to work!

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> I agree, but since you proposed going C like, let's go for shorter names,
> like proc. And no "returns" either, let's regress to a Pascalish :.

Well, I didn't really "propose" going C like.  I was merely griping that
one might be *forced* to go C like in order to gain popularity.  I
realize it's an exageration.  And of course, as you point out, one might
be able to borrow some *good* ideas from C, too.

> OK. I think C folks will whine though. I have a generic package for these
> in Ada, and I use Incr and Decr. 

But you unfortunately have to clutter the code with instantiations,
which negates the benfit, IMHO.

> Anyways, Python, Tcl, Ruby and others didn't have large marketing budgets. 

Granted.

- Bob

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Wed, 11 Apr 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > I agree, but since you proposed going C like, let's go for shorter names,
> > like proc. And no "returns" either, let's regress to a Pascalish :.
> 
> Well, I didn't really "propose" going C like.  I was merely griping that
> one might be *forced* to go C like in order to gain popularity. 

Yes you're right. I realize you weren't completely serious, but I think
that point (about syntax) has been made many times, and even though I 
generally like Ada syntax much better I thought I'd argue the C side. 

> I realize it's an exageration.  And of course, as you point out, one might
> be able to borrow some *good* ideas from C, too.

Truthfully, I don't know that there is that much good to borrow from
C. Pascal and the other Wirth languages already used [] for arrays. Ada 
got the ability to get a pointer to a local variable, and did it better
than C IMO. 

As Lauernt Guerby rightly observed, {} versus begin-end is mostly a
non-issue. A huge number of programmers used to C derived syntaxes are
used to that choice, and find it readable. By adding a semi-colon after
the closing brace we can get back the nice feature of Ada which matches
opening names (and I admit this is a very nice feature, which I emulate in 
C/C++/Java/OCaml/... with comments :-( ). So, I think it's possible to get 
much closer to C without losing fundamentally good Ada features. 

As far as [] goes, sure, my degrees are in mathematics, I'm very well
aware that you can view an array as a (partial) function, but as a
programmer, I just don't see things that way. If I want a very formal
mathematical language I wouldn't use Ada at all, I'd use Haskell or Clean. 

> > OK. I think C folks will whine though. I have a generic package for these
> > in Ada, and I use Incr and Decr. 
> 
> But you unfortunately have to clutter the code with instantiations,
> which negates the benfit, IMHO.

Absolutely right. So one good idea we could steal from (gasp! shudder!) C++ 
is automatic instantiation of generics. There was a paper on this in
Tri-Ada 91, and one of the authors (Shen) has a PhD thesis exploring this
idea in more detail.

> > Anyways, Python, Tcl, Ruby and others didn't have large marketing budgets. 
> 
> Granted.

The question then, if you want to go the cheapo route, is to find a group
of programmers whose needs aren't being well met by the available choices. 
I always think of Ada as a low level language (despite the weird VHLL
description) used for embedded, real-time, and systems programming work. 
Is there a need for another language there? 

-- Brian

Re: newbie can't get exceptions to work!

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> OK, I was sort of being a pain with that question. However, since we're 
> redesigning the language :-), the right solution IMO would be to have a 
> more precise form of import and export clause than what Ada has, so that 
> if you want to use a package you can choose precisely what gets seen.
> This way, the use type folks are happy, I'm happy (well, I'm always happy:)
> you're happy (yes?),

Me?  Happy?  I'll be happy when I've designed the perfect programming
language (or somebody else beats me to it).  I.e., never.  ;-)

>... and Niklaus Wirth is vindicated. For example,
> something like 
> 
> from Some_Package use "+", "-", "*", Some_Function;
> 
> ...
> Some_Package.Some_Other_Function(Some_Function(A + B * C));

I think this idea has some merit, but I tend to think that most of the
decisions should be on the other end.  That is, the person who chose the
names for Some_Function and Some_Other_Function is in a better position
to choose whether they should be used with "Some_Package." notation.

But for operators, I still insist that they should *never* be used with
dot notation, so if they're used at all, operator notation should be
used.  (Mike Yoder posted an obscure counter-example to my "never"
claim, some months ago.  Still...)

> > I agree that it's an annoying restriction.  The reason, I guess, is that
> > if you allowed someone to define an operator "$" or "&^%$$##", you would
> > have to worry about the syntax.  What is the precedence of these
> > operators?  I think Cecil has a nice solution to the problem.
> 
> What's the Cecil solution?

The problem with most languages that allow (more-or-less) arbitrary
operator symbols is that they view precedence as a relationship between
any pair of operators.  You get to define the precedence "level" of, say
$*&(^, and then it relates to the normal + and so forth as specified.
But that's error prone.

The cool thing about Cecil is that you define precedence among related
operators.  If two operators are unrelated, you have to parenthesize.
This seems much less error prone to me.

>... The OCaml solution is to have precedence and
> associativity inherited from the first character of the operator, so 
> +. and +/ are like +.

Sounds error prone.  If +/ is unrelated to +, then

    X +/ Y + Z

should require parentheses.

>... Unfortunately OCaml doesn't yet have overloading so 
> it really needs this feature. You're probably not surprised to learn that 
> in many language communities (Modula-3, ML, Eiffel?) overloading is viewed 
> by many the same way that "use" is viewed by many in the Ada world. And I 
> respond the same way, sure overloading can make a mess for the reader but 
> used well it makes code more readable.

Agreed.  It's hard to get too hot and bothered about the dangers of
overloading, which is resolved at compile time, in a language like
Eiffel (or Ada), where a given name is dispatched at *run* time.
Yes, it's potentially confusing, but it's also potentially good.

> I tell you what, design this next language, and I'm on board. I'm willing
> to give up full closures as long as pattern matching and parametric
> polymorphism are in the language.

Please explain to me why pattern matching is so wonderful.  I know about
ML and the like, and pattern matching seems kind of nice, but why do ML
advocates seem to think it's so much more than just "nice".  Why is it
so much more wonderful than an 'if' statement?

And is your answer specific to OCaml, or does it apply equally to ML?

 Take a look at the Cyclone project as 
> an example of a decent looking futuristic systems programming language, 
> unfortunately based on C. 
> 
> http://cvs.metaprl.org:12000/cvsweb/~checkout~/cyclone/doc/cyc_users_guide.htm
> 
> > > > why should you have to write "use" in order to write
> > > > "if X = Y ..."?
> > > 
> > > "=" is also kind of special, right? 
> > 
> > Unfortunately true.
> 
> This is actually a deep problem.

Indeed.  I don't know the right answer.

>... SML has it's eqtypes, OCaml has it's
> polymorphic comparison primitives. Neither seem satisfactory to me. 
> 
> > I meant that all operators should be exempt.  I wasn't speaking
> > particularly about ":=" and "=" (and I realize that Ada defines "=" to
> > be an operator, but not ":=" or "in", etc).
> 
> Well, I think the Wirthian solution is probably better, and has the nice 
> property of not treating operators specially. 

I don't think that treating operators non-specially is a good thing.
Sure, it seems elegant (more uniform), but in practise, surely you want
operators to be visible with no fuss or bother.  Operator symbols *are*
special, because the programmer chose to use concise syntax over
wordiness ("*" vs "Multiply", for example).

Does it bother you that if we have:

    X: Some_Package.Some_Type;
    Y: Some_Package.Some_Type;

you can say (in Ada):

    X := Y;

Or would you prefer to require (the Wirthian?):

    from Some_Package import ":=";

first?

>...Why didn't Ada have such a
> selective import? 

I don't know the history of that.

- Bob

Re: newbie can't get exceptions to work!

[Brian Rogoff]

On Tue, 10 Apr 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > OK, I was sort of being a pain with that question. However, since we're 
> > redesigning the language :-), the right solution IMO would be to have a 
> > more precise form of import and export clause than what Ada has, so that 
> > if you want to use a package you can choose precisely what gets seen.
> > This way, the use type folks are happy, I'm happy (well, I'm always happy:)
> > you're happy (yes?),
> 
> Me?  Happy?  I'll be happy when I've designed the perfect programming
> language (or somebody else beats me to it).  I.e., never.  ;-)

Well, I doubt that there will ever be a perfect programming language for
*all* programming tasks. There are just too many conflicting requirements. 
Would you be happy with, say, 10 really good ones? :-)

> >... and Niklaus Wirth is vindicated. For example,
> > something like 
> > 
> > from Some_Package use "+", "-", "*", Some_Function;
> > 
> > ...
> > Some_Package.Some_Other_Function(Some_Function(A + B * C));
> 
> I think this idea has some merit, but I tend to think that most of the
> decisions should be on the other end.  That is, the person who chose the
> names for Some_Function and Some_Other_Function is in a better position
> to choose whether they should be used with "Some_Package." notation.

I disagree, at least a bit. I think the package designer can tell me he
will allow me to see, but after that I (the client) may decide that I 
don't want to see everything. 

> But for operators, I still insist that they should *never* be used with
> dot notation, so if they're used at all, operator notation should be
> used.  (Mike Yoder posted an obscure counter-example to my "never"
> claim, some months ago.  Still...)

That's fine. I'd force you to use some renaming then, or to import a
prefix function as an operator. As long as the syntax is lightweight
enough, I don't think that's a problem.
 
> > > I agree that it's an annoying restriction.  The reason, I guess, is that
> > > if you allowed someone to define an operator "$" or "&^%$$##", you would
> > > have to worry about the syntax.  What is the precedence of these
> > > operators?  I think Cecil has a nice solution to the problem.
> > 
> > What's the Cecil solution?
> 
> The problem with most languages that allow (more-or-less) arbitrary
> operator symbols is that they view precedence as a relationship between
> any pair of operators.  You get to define the precedence "level" of, say
> $*&(^, and then it relates to the normal + and so forth as specified.
> But that's error prone.
> 
> The cool thing about Cecil is that you define precedence among related
> operators.  If two operators are unrelated, you have to parenthesize.
> This seems much less error prone to me.

But it still seems error prone. Another possibility is fixed precedence
and associativity, and always force parenthesization. That's what Haskell 
does with it's alphanumeric infixes, like 

	11 `plus` 13

> >... The OCaml solution is to have precedence and
> > associativity inherited from the first character of the operator, so 
> > +. and +/ are like +.
> 
> Sounds error prone.  If +/ is unrelated to +, then
> 
>     X +/ Y + Z
> 
> should require parentheses.

I guess you didn't read ahead :-). No overloading in OCaml, that's a type
error.

> >... Unfortunately OCaml doesn't yet have overloading so 
> > it really needs this feature. You're probably not surprised to learn that 
> > in many language communities (Modula-3, ML, Eiffel?) overloading is viewed 
> > by many the same way that "use" is viewed by many in the Ada world. And I 
> > respond the same way, sure overloading can make a mess for the reader but 
> > used well it makes code more readable.
> 
> Agreed.  It's hard to get too hot and bothered about the dangers of
> overloading, which is resolved at compile time, in a language like
> Eiffel (or Ada), where a given name is dispatched at *run* time.
> Yes, it's potentially confusing, but it's also potentially good.
> 
> > I tell you what, design this next language, and I'm on board. I'm willing
> > to give up full closures as long as pattern matching and parametric
> > polymorphism are in the language.
> 
> Please explain to me why pattern matching is so wonderful.  I know about
> ML and the like, and pattern matching seems kind of nice, but why do ML
> advocates seem to think it's so much more than just "nice".  Why is it
> so much more wonderful than an 'if' statement?
> 
> And is your answer specific to OCaml, or does it apply equally to ML?

My answer applies equally to SML, Erlang, Haskell, Clean, ...

Do you know SML? Pattern matching is so much more wonderful than "if" or
"case" because the same kind of construction that takes many lines of 
code in such a language is far fewer lines in a language with pattern
matching *and* very readable (IMO of course :). An example perhaps? 
This is using short names (E for Empty, R for Red, B for Black, T for
Tree,...)

module RedBlackSet (Element : ORDERED)
  : (SET with type elem = Element.t) =
struct
  type elem = Element.t

  type color = R | B
  type tree  = E | T of color * tree * elem * tree
  type set   = tree

  let empty = E

  let rec member x s = match x, s with
    | _, E -> false
    | _, T (_, a, y, b) ->
        if Element.lt x y then member x a
        else if Element.lt y x then member x b
        else true

  let balance = function
    | B,T (R,T (R,a,x,b),y,c),z,d -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | B,T (R,a,x,T (R,b,y,c)),z,d -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | B,a,x,T (R,T (R,b,y,c),z,d) -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | B,a,x,T (R,b,y,T (R,c,z,d)) -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | a,b,c,d                     -> T (a,b,c,d)

  let insert x s =
    let rec ins = function
      | E -> T (R, E, x, E)
      | T (color, a, y, b) as s ->
          if Element.lt x y then balance (color, ins a, y, b)
          else if Element.lt y x then balance (color, a, y, ins b)
          else s in
    match ins s with  (* guaranteed to be non-empty *)
      | T (_, a, y, b) -> T (B, a, y, b)
      | _              -> impossible_pat "insert"
end

If you understand the balancing operations, which are decidedly
non-trivial, you'll find that the pattern match is a direct transcription. 

> > > I meant that all operators should be exempt.  I wasn't speaking
> > > particularly about ":=" and "=" (and I realize that Ada defines "=" to
> > > be an operator, but not ":=" or "in", etc).
> > 
> > Well, I think the Wirthian solution is probably better, and has the nice 
> > property of not treating operators specially. 
> 
> I don't think that treating operators non-specially is a good thing.
> Sure, it seems elegant (more uniform), but in practise, surely you want
> operators to be visible with no fuss or bother.  Operator symbols *are*
> special, because the programmer chose to use concise syntax over
> wordiness ("*" vs "Multiply", for example).
> 
> Does it bother you that if we have:
> 
>     X: Some_Package.Some_Type;
>     Y: Some_Package.Some_Type;
> 
> you can say (in Ada):
> 
>     X := Y;
> 
> Or would you prefer to require (the Wirthian?):
> 
>     from Some_Package import ":=";
> 
> first?

Well, assignment and equality are "special", so I'm relatively comfortable
with a range of choices. I certainly wouldn't mind the Wirthian
approach. In this case it seems like you could use it to get limited
(in the Ada sense) views. But I certainly would prefer 

from Some_Package import "*";

to just letting infix operators be automatically used. Difference of
opinion here I guess. 

> >...Why didn't Ada have such a
> > selective import? 
> 
> I don't know the history of that.

Now that is something I'd like to find out. Jean Ichbiah did an amazing
job with Ada in the late seventies. I don't even know if Wirth had come up
with these features then. Too bad RBKD has vanished, since he usually
knows the answer to these questions...

-- Brian

Re: newbie can't get exceptions to work!

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> On Tue, 10 Apr 2001, Robert A Duff wrote:
> > Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > > OK, I was sort of being a pain with that question. However, since we're 
> > > redesigning the language :-), the right solution IMO would be to have a 
> > > more precise form of import and export clause than what Ada has, so that 
> > > if you want to use a package you can choose precisely what gets seen.
> > > This way, the use type folks are happy, I'm happy (well, I'm always happy:)
> > > you're happy (yes?),
> > 
> > Me?  Happy?  I'll be happy when I've designed the perfect programming
> > language (or somebody else beats me to it).  I.e., never.  ;-)
> 
> Well, I doubt that there will ever be a perfect programming language for
> *all* programming tasks. There are just too many conflicting requirements. 

There's also an awful lot of commonality.  Surely almost every
application area can benefit from a language that makes it easy to write
readable code!?

And if you look at the differences between current programming
languages, they're mostly arbitrary choices of the language designer,
rather than being particularly beneficial to some particular use.
For example, "end" vs "}", which we have been discussing:  I can
understand somebody liking one or the other, but I can't understand how
one could be better for, say, numerics, whereas the other is better for
business apps.  One or the other is simply better.

> Would you be happy with, say, 10 really good ones? :-)
> 
> > >... and Niklaus Wirth is vindicated. For example,
> > > something like 
> > > 
> > > from Some_Package use "+", "-", "*", Some_Function;
> > > 
> > > ...
> > > Some_Package.Some_Other_Function(Some_Function(A + B * C));
> > 
> > I think this idea has some merit, but I tend to think that most of the
> > decisions should be on the other end.  That is, the person who chose the
> > names for Some_Function and Some_Other_Function is in a better position
> > to choose whether they should be used with "Some_Package." notation.
> 
> I disagree, at least a bit. I think the package designer can tell me he
> will allow me to see, but after that I (the client) may decide that I 
> don't want to see everything. 

Fine, but my point was that *if* you choose to see it, the package
designer is in a better position to choose the name by which you see it
(X vs Package_Name.X).

> > But for operators, I still insist that they should *never* be used with
> > dot notation, so if they're used at all, operator notation should be
> > used.  (Mike Yoder posted an obscure counter-example to my "never"
> > claim, some months ago.  Still...)
> 
> That's fine. I'd force you to use some renaming then, or to import a
> prefix function as an operator. As long as the syntax is lightweight
> enough, I don't think that's a problem.

For operators, IMHO, the only syntax that is lightweight enough is none
at all.

> > > > I agree that it's an annoying restriction.  The reason, I guess, is that
> > > > if you allowed someone to define an operator "$" or "&^%$$##", you would
> > > > have to worry about the syntax.  What is the precedence of these
> > > > operators?  I think Cecil has a nice solution to the problem.
> > > 
> > > What's the Cecil solution?
> > 
> > The problem with most languages that allow (more-or-less) arbitrary
> > operator symbols is that they view precedence as a relationship between
> > any pair of operators.  You get to define the precedence "level" of, say
> > $*&(^, and then it relates to the normal + and so forth as specified.
> > But that's error prone.
> > 
> > The cool thing about Cecil is that you define precedence among related
> > operators.  If two operators are unrelated, you have to parenthesize.
> > This seems much less error prone to me.
> 
> But it still seems error prone.

I don't see why.  Please explain.

>... Another possibility is fixed precedence
> and associativity, and always force parenthesization. That's what Haskell 
> does with it's alphanumeric infixes, like 
> 
> 	11 `plus` 13
> 
> > >... The OCaml solution is to have precedence and
> > > associativity inherited from the first character of the operator, so 
> > > +. and +/ are like +.
> > 
> > Sounds error prone.  If +/ is unrelated to +, then
> > 
> >     X +/ Y + Z
> > 
> > should require parentheses.
> 
> I guess you didn't read ahead :-). No overloading in OCaml, that's a type
> error.

I did read ahead.  I guess I just didn't understand.  Can't I define
"+/" and "+" operators such that the above makes sense (i.e., type
checks)?  I suppose I should go and read the OCaml manual.

> > Please explain to me why pattern matching is so wonderful.  I know about
> > ML and the like, and pattern matching seems kind of nice, but why do ML
> > advocates seem to think it's so much more than just "nice".  Why is it
> > so much more wonderful than an 'if' statement?
> > 
> > And is your answer specific to OCaml, or does it apply equally to ML?
> 
> My answer applies equally to SML, Erlang, Haskell, Clean, ...
> 
> Do you know SML?

Yes.

>... Pattern matching is so much more wonderful than "if" or
> "case" because the same kind of construction that takes many lines of 
> code in such a language is far fewer lines in a language with pattern
> matching *and* very readable (IMO of course :). An example perhaps? 
> This is using short names (E for Empty, R for Red, B for Black, T for
> Tree,...)

OK, thanks.

But one advantage of Ada's case statement is the full coverage
checking.  This is a huge advantage, in my opinion.  I'd be happier
about pattern matching if it did full coverage checking.

> Well, assignment and equality are "special", so I'm relatively comfortable
> with a range of choices. I certainly wouldn't mind the Wirthian
> approach. In this case it seems like you could use it to get limited
> (in the Ada sense) views. But I certainly would prefer 
> 
> from Some_Package import "*";
> 
> to just letting infix operators be automatically used. Difference of
> opinion here I guess. 

Shrug.  I suppose I could live with that.

- Bob

Re: newbie can't get exceptions to work!

[Christoph Grein]

   package INT_STACK  is new GEN_STACK(ELM => INTEGER, LEN => 10);
   package INT2_STACK is new GEN_STACK(ELM => INTEGER, LEN =>  5);

With these two instantiations, you get two exceptions STACK_ERROR:
  INT_STACK.STACK_ERROR and INT2_STACK.STACK_ERROR.

So write:

  ...
exception
  when INT_STACK.STACK_ERROR | INT2_STACK.STACK_ERROR =>
    Handle_them;  -- note that you do not need a begin end block here.
end;