* newbie can't get exceptions to work! @ 2001-04-05 3:19 Jeff Shipman 2001-04-05 4:25 ` Ed Falis ` (2 more replies) 0 siblings, 3 replies; 87+ messages in thread From: Jeff Shipman @ 2001-04-05 3:19 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-05 3:19 newbie can't get exceptions to work! Jeff Shipman @ 2001-04-05 4:25 ` Ed Falis 2001-04-05 11:00 ` martin.m.dowie 2001-04-05 4:34 ` Jeff Shipman 2001-04-05 4:59 ` Wilhelm Spickermann 2 siblings, 1 reply; 87+ messages in thread From: Ed Falis @ 2001-04-05 4:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-05 4:25 ` Ed Falis @ 2001-04-05 11:00 ` martin.m.dowie 2001-04-05 14:21 ` Ted Dennison 0 siblings, 1 reply; 87+ messages in thread From: martin.m.dowie @ 2001-04-05 11:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-05 11:00 ` martin.m.dowie @ 2001-04-05 14:21 ` Ted Dennison 2001-04-05 17:50 ` Fraser Wilson 0 siblings, 1 reply; 87+ messages in thread From: Ted Dennison @ 2001-04-05 14:21 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-05 14:21 ` Ted Dennison @ 2001-04-05 17:50 ` Fraser Wilson 0 siblings, 0 replies; 87+ messages in thread From: Fraser Wilson @ 2001-04-05 17:50 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-05 3:19 newbie can't get exceptions to work! Jeff Shipman 2001-04-05 4:25 ` Ed Falis @ 2001-04-05 4:34 ` Jeff Shipman 2001-04-05 4:59 ` Wilhelm Spickermann 2 siblings, 0 replies; 87+ messages in thread From: Jeff Shipman @ 2001-04-05 4:34 UTC (permalink / raw) > -- 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* RE: newbie can't get exceptions to work! 2001-04-05 3:19 newbie can't get exceptions to work! Jeff Shipman 2001-04-05 4:25 ` Ed Falis 2001-04-05 4:34 ` Jeff Shipman @ 2001-04-05 4:59 ` Wilhelm Spickermann 2001-04-05 14:14 ` Ted Dennison 2 siblings, 1 reply; 87+ messages in thread From: Wilhelm Spickermann @ 2001-04-05 4:59 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: RE: newbie can't get exceptions to work! 2001-04-05 4:59 ` Wilhelm Spickermann @ 2001-04-05 14:14 ` Ted Dennison 2001-04-05 16:37 ` Wilhelm Spickermann 2001-04-06 13:09 ` Marc A. Criley 0 siblings, 2 replies; 87+ messages in thread From: Ted Dennison @ 2001-04-05 14:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: RE: newbie can't get exceptions to work! 2001-04-05 14:14 ` Ted Dennison @ 2001-04-05 16:37 ` Wilhelm Spickermann 2001-04-06 13:09 ` Marc A. Criley 1 sibling, 0 replies; 87+ messages in thread From: Wilhelm Spickermann @ 2001-04-05 16:37 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-05 14:14 ` Ted Dennison 2001-04-05 16:37 ` Wilhelm Spickermann @ 2001-04-06 13:09 ` Marc A. Criley 2001-04-06 15:04 ` Ted Dennison 2001-04-06 16:43 ` Robert A Duff 1 sibling, 2 replies; 87+ messages in thread From: Marc A. Criley @ 2001-04-06 13:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 13:09 ` Marc A. Criley @ 2001-04-06 15:04 ` Ted Dennison 2001-04-06 16:43 ` Robert A Duff 1 sibling, 0 replies; 87+ messages in thread From: Ted Dennison @ 2001-04-06 15:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 13:09 ` Marc A. Criley 2001-04-06 15:04 ` Ted Dennison @ 2001-04-06 16:43 ` Robert A Duff 2001-04-06 17:39 ` Ted Dennison 2001-04-06 20:11 ` Brian Rogoff 1 sibling, 2 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-06 16:43 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 16:43 ` Robert A Duff @ 2001-04-06 17:39 ` Ted Dennison 2001-04-06 21:50 ` Robert A Duff 2001-04-06 20:11 ` Brian Rogoff 1 sibling, 1 reply; 87+ messages in thread From: Ted Dennison @ 2001-04-06 17:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 17:39 ` Ted Dennison @ 2001-04-06 21:50 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-06 21:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 16:43 ` Robert A Duff 2001-04-06 17:39 ` Ted Dennison @ 2001-04-06 20:11 ` Brian Rogoff 2001-04-06 22:20 ` Robert A Duff 1 sibling, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-06 20:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 20:11 ` Brian Rogoff @ 2001-04-06 22:20 ` Robert A Duff 2001-04-06 23:04 ` Brian Rogoff 0 siblings, 1 reply; 87+ messages in thread From: Robert A Duff @ 2001-04-06 22:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 22:20 ` Robert A Duff @ 2001-04-06 23:04 ` Brian Rogoff 2001-04-07 5:48 ` Jeffrey Carter ` (2 more replies) 0 siblings, 3 replies; 87+ messages in thread From: Brian Rogoff @ 2001-04-06 23:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 23:04 ` Brian Rogoff @ 2001-04-07 5:48 ` Jeffrey Carter 2001-04-10 1:29 ` Robert A Duff 2001-04-07 19:30 ` Robert A Duff 2001-04-10 1:26 ` Robert A Duff 2 siblings, 1 reply; 87+ messages in thread From: Jeffrey Carter @ 2001-04-07 5:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-07 5:48 ` Jeffrey Carter @ 2001-04-10 1:29 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-10 1:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 23:04 ` Brian Rogoff 2001-04-07 5:48 ` Jeffrey Carter @ 2001-04-07 19:30 ` Robert A Duff 2001-04-07 21:17 ` Brian Rogoff 2001-04-10 1:26 ` Robert A Duff 2 siblings, 1 reply; 87+ messages in thread From: Robert A Duff @ 2001-04-07 19:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-07 19:30 ` Robert A Duff @ 2001-04-07 21:17 ` Brian Rogoff 2001-04-07 21:25 ` Ayende Rahien 2001-04-10 1:41 ` Robert A Duff 0 siblings, 2 replies; 87+ messages in thread From: Brian Rogoff @ 2001-04-07 21:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-07 21:17 ` Brian Rogoff @ 2001-04-07 21:25 ` Ayende Rahien 2001-04-07 22:57 ` David Starner 2001-04-08 2:12 ` Larry Hazel 2001-04-10 1:41 ` Robert A Duff 1 sibling, 2 replies; 87+ messages in thread From: Ayende Rahien @ 2001-04-07 21:25 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-07 21:25 ` Ayende Rahien @ 2001-04-07 22:57 ` David Starner 2001-04-08 12:10 ` Ayende Rahien 2001-04-08 2:12 ` Larry Hazel 1 sibling, 1 reply; 87+ messages in thread From: David Starner @ 2001-04-07 22:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-07 22:57 ` David Starner @ 2001-04-08 12:10 ` Ayende Rahien 0 siblings, 0 replies; 87+ messages in thread From: Ayende Rahien @ 2001-04-08 12:10 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-07 21:25 ` Ayende Rahien 2001-04-07 22:57 ` David Starner @ 2001-04-08 2:12 ` Larry Hazel 2001-04-08 12:12 ` Ayende Rahien 2001-04-08 22:18 ` Brian Rogoff 1 sibling, 2 replies; 87+ messages in thread From: Larry Hazel @ 2001-04-08 2:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-08 2:12 ` Larry Hazel @ 2001-04-08 12:12 ` Ayende Rahien 2001-04-09 16:20 ` Larry Hazel 2001-04-08 22:18 ` Brian Rogoff 1 sibling, 1 reply; 87+ messages in thread From: Ayende Rahien @ 2001-04-08 12:12 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-08 12:12 ` Ayende Rahien @ 2001-04-09 16:20 ` Larry Hazel 2001-04-10 2:38 ` Ayende Rahien 0 siblings, 1 reply; 87+ messages in thread From: Larry Hazel @ 2001-04-09 16:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 16:20 ` Larry Hazel @ 2001-04-10 2:38 ` Ayende Rahien 2001-04-10 3:25 ` James Rogers 0 siblings, 1 reply; 87+ messages in thread From: Ayende Rahien @ 2001-04-10 2:38 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 2:38 ` Ayende Rahien @ 2001-04-10 3:25 ` James Rogers 0 siblings, 0 replies; 87+ messages in thread From: James Rogers @ 2001-04-10 3:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-08 2:12 ` Larry Hazel 2001-04-08 12:12 ` Ayende Rahien @ 2001-04-08 22:18 ` Brian Rogoff 2001-04-09 15:14 ` Ted Dennison 1 sibling, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-08 22:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-08 22:18 ` Brian Rogoff @ 2001-04-09 15:14 ` Ted Dennison 2001-04-09 17:23 ` Brian Rogoff 0 siblings, 1 reply; 87+ messages in thread From: Ted Dennison @ 2001-04-09 15:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 15:14 ` Ted Dennison @ 2001-04-09 17:23 ` Brian Rogoff 2001-04-09 18:23 ` Laurent Guerby ` (2 more replies) 0 siblings, 3 replies; 87+ messages in thread From: Brian Rogoff @ 2001-04-09 17:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 17:23 ` Brian Rogoff @ 2001-04-09 18:23 ` Laurent Guerby 2001-04-09 19:15 ` Brian Rogoff 2001-04-10 2:12 ` Robert A Duff 2001-04-09 20:49 ` newbie can't get exceptions to work! Ted Dennison 2001-04-13 16:12 ` Matthew Woodcraft 2 siblings, 2 replies; 87+ messages in thread From: Laurent Guerby @ 2001-04-09 18:23 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 18:23 ` Laurent Guerby @ 2001-04-09 19:15 ` Brian Rogoff 2001-04-10 18:21 ` Laurent Guerby 2001-04-10 2:12 ` Robert A Duff 1 sibling, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-09 19:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 19:15 ` Brian Rogoff @ 2001-04-10 18:21 ` Laurent Guerby 2001-04-10 19:44 ` Brian Rogoff 2001-04-11 13:24 ` Ayende Rahien 0 siblings, 2 replies; 87+ messages in thread From: Laurent Guerby @ 2001-04-10 18:21 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 18:21 ` Laurent Guerby @ 2001-04-10 19:44 ` Brian Rogoff 2001-04-11 18:03 ` Laurent Guerby 2001-04-11 13:24 ` Ayende Rahien 1 sibling, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-10 19:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 19:44 ` Brian Rogoff @ 2001-04-11 18:03 ` Laurent Guerby 2001-04-11 18:33 ` Samuel T. Harris ` (2 more replies) 0 siblings, 3 replies; 87+ messages in thread From: Laurent Guerby @ 2001-04-11 18:03 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 18:03 ` Laurent Guerby @ 2001-04-11 18:33 ` Samuel T. Harris 2001-04-14 0:06 ` Robert A Duff 2001-04-12 1:42 ` Mike Silva 2001-04-12 2:38 ` Brian Rogoff 2 siblings, 1 reply; 87+ messages in thread From: Samuel T. Harris @ 2001-04-11 18:33 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 18:33 ` Samuel T. Harris @ 2001-04-14 0:06 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-14 0:06 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 18:03 ` Laurent Guerby 2001-04-11 18:33 ` Samuel T. Harris @ 2001-04-12 1:42 ` Mike Silva 2001-04-12 2:38 ` Brian Rogoff 2 siblings, 0 replies; 87+ messages in thread From: Mike Silva @ 2001-04-12 1:42 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 18:03 ` Laurent Guerby 2001-04-11 18:33 ` Samuel T. Harris 2001-04-12 1:42 ` Mike Silva @ 2001-04-12 2:38 ` Brian Rogoff 2001-04-12 23:23 ` Laurent Guerby 2 siblings, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-12 2:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-12 2:38 ` Brian Rogoff @ 2001-04-12 23:23 ` Laurent Guerby 2001-04-13 2:44 ` Brian Rogoff 0 siblings, 1 reply; 87+ messages in thread From: Laurent Guerby @ 2001-04-12 23:23 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-12 23:23 ` Laurent Guerby @ 2001-04-13 2:44 ` Brian Rogoff 0 siblings, 0 replies; 87+ messages in thread From: Brian Rogoff @ 2001-04-13 2:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 18:21 ` Laurent Guerby 2001-04-10 19:44 ` Brian Rogoff @ 2001-04-11 13:24 ` Ayende Rahien 2001-04-11 13:14 ` Mats Karlssohn 1 sibling, 1 reply; 87+ messages in thread From: Ayende Rahien @ 2001-04-11 13:24 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 13:24 ` Ayende Rahien @ 2001-04-11 13:14 ` Mats Karlssohn 2001-04-11 15:08 ` Ayende Rahien 2001-04-11 21:42 ` Fraser Wilson 0 siblings, 2 replies; 87+ messages in thread From: Mats Karlssohn @ 2001-04-11 13:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 13:14 ` Mats Karlssohn @ 2001-04-11 15:08 ` Ayende Rahien 2001-04-11 21:42 ` Fraser Wilson 1 sibling, 0 replies; 87+ messages in thread From: Ayende Rahien @ 2001-04-11 15:08 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 13:14 ` Mats Karlssohn 2001-04-11 15:08 ` Ayende Rahien @ 2001-04-11 21:42 ` Fraser Wilson 2001-04-12 23:55 ` Robert A Duff 1 sibling, 1 reply; 87+ messages in thread From: Fraser Wilson @ 2001-04-11 21:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 21:42 ` Fraser Wilson @ 2001-04-12 23:55 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-12 23:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 18:23 ` Laurent Guerby 2001-04-09 19:15 ` Brian Rogoff @ 2001-04-10 2:12 ` Robert A Duff 2001-04-10 3:47 ` Brian Rogoff 2001-04-10 13:40 ` Ada keywords (was: Re: newbie can't get exceptions to work!) Marin David Condic 1 sibling, 2 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-10 2:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 2:12 ` Robert A Duff @ 2001-04-10 3:47 ` Brian Rogoff 2001-04-10 13:40 ` Ada keywords (was: Re: newbie can't get exceptions to work!) Marin David Condic 1 sibling, 0 replies; 87+ messages in thread From: Brian Rogoff @ 2001-04-10 3:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Ada keywords (was: Re: newbie can't get exceptions to work!) 2001-04-10 2:12 ` Robert A Duff 2001-04-10 3:47 ` Brian Rogoff @ 2001-04-10 13:40 ` Marin David Condic 2001-04-10 14:26 ` Jean-Pierre Rosen 1 sibling, 1 reply; 87+ messages in thread From: Marin David Condic @ 2001-04-10 13:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: Ada keywords (was: Re: newbie can't get exceptions to work!) 2001-04-10 13:40 ` Ada keywords (was: Re: newbie can't get exceptions to work!) Marin David Condic @ 2001-04-10 14:26 ` Jean-Pierre Rosen 0 siblings, 0 replies; 87+ messages in thread From: Jean-Pierre Rosen @ 2001-04-10 14:26 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 17:23 ` Brian Rogoff 2001-04-09 18:23 ` Laurent Guerby @ 2001-04-09 20:49 ` Ted Dennison 2001-04-09 21:44 ` Brian Rogoff 2001-04-10 6:59 ` Mats Karlssohn 2001-04-13 16:12 ` Matthew Woodcraft 2 siblings, 2 replies; 87+ messages in thread From: Ted Dennison @ 2001-04-09 20:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 20:49 ` newbie can't get exceptions to work! Ted Dennison @ 2001-04-09 21:44 ` Brian Rogoff 2001-04-09 21:59 ` Ted Dennison 2001-04-10 6:59 ` Mats Karlssohn 1 sibling, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-09 21:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 21:44 ` Brian Rogoff @ 2001-04-09 21:59 ` Ted Dennison 2001-04-10 2:54 ` Ayende Rahien 0 siblings, 1 reply; 87+ messages in thread From: Ted Dennison @ 2001-04-09 21:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 21:59 ` Ted Dennison @ 2001-04-10 2:54 ` Ayende Rahien 2001-04-10 14:00 ` Ted Dennison 2001-04-10 17:44 ` Fraser Wilson 0 siblings, 2 replies; 87+ messages in thread From: Ayende Rahien @ 2001-04-10 2:54 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 2:54 ` Ayende Rahien @ 2001-04-10 14:00 ` Ted Dennison 2001-04-10 17:44 ` Fraser Wilson 1 sibling, 0 replies; 87+ messages in thread From: Ted Dennison @ 2001-04-10 14:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 2:54 ` Ayende Rahien 2001-04-10 14:00 ` Ted Dennison @ 2001-04-10 17:44 ` Fraser Wilson 1 sibling, 0 replies; 87+ messages in thread From: Fraser Wilson @ 2001-04-10 17:44 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 20:49 ` newbie can't get exceptions to work! Ted Dennison 2001-04-09 21:44 ` Brian Rogoff @ 2001-04-10 6:59 ` Mats Karlssohn 2001-04-10 14:18 ` Ted Dennison 1 sibling, 1 reply; 87+ messages in thread From: Mats Karlssohn @ 2001-04-10 6:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 6:59 ` Mats Karlssohn @ 2001-04-10 14:18 ` Ted Dennison 2001-04-10 16:27 ` Mark Biggar 2001-04-11 11:49 ` Mats Karlssohn 0 siblings, 2 replies; 87+ messages in thread From: Ted Dennison @ 2001-04-10 14:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 14:18 ` Ted Dennison @ 2001-04-10 16:27 ` Mark Biggar 2001-04-11 11:55 ` Mats Karlssohn 2001-04-11 11:49 ` Mats Karlssohn 1 sibling, 1 reply; 87+ messages in thread From: Mark Biggar @ 2001-04-10 16:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 16:27 ` Mark Biggar @ 2001-04-11 11:55 ` Mats Karlssohn 2001-04-11 14:34 ` Samuel T. Harris 0 siblings, 1 reply; 87+ messages in thread From: Mats Karlssohn @ 2001-04-11 11:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 11:55 ` Mats Karlssohn @ 2001-04-11 14:34 ` Samuel T. Harris 2001-04-11 15:50 ` Pat Rogers 2001-04-12 6:27 ` Mats Karlssohn 0 siblings, 2 replies; 87+ messages in thread From: Samuel T. Harris @ 2001-04-11 14:34 UTC (permalink / raw) 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!" ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 14:34 ` Samuel T. Harris @ 2001-04-11 15:50 ` Pat Rogers 2001-04-12 6:27 ` Mats Karlssohn 1 sibling, 0 replies; 87+ messages in thread From: Pat Rogers @ 2001-04-11 15:50 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 14:34 ` Samuel T. Harris 2001-04-11 15:50 ` Pat Rogers @ 2001-04-12 6:27 ` Mats Karlssohn 1 sibling, 0 replies; 87+ messages in thread From: Mats Karlssohn @ 2001-04-12 6:27 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 14:18 ` Ted Dennison 2001-04-10 16:27 ` Mark Biggar @ 2001-04-11 11:49 ` Mats Karlssohn 2001-04-11 15:38 ` Robert A Duff 1 sibling, 1 reply; 87+ messages in thread From: Mats Karlssohn @ 2001-04-11 11:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 11:49 ` Mats Karlssohn @ 2001-04-11 15:38 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-11 15:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-09 17:23 ` Brian Rogoff 2001-04-09 18:23 ` Laurent Guerby 2001-04-09 20:49 ` newbie can't get exceptions to work! Ted Dennison @ 2001-04-13 16:12 ` Matthew Woodcraft 2 siblings, 0 replies; 87+ messages in thread From: Matthew Woodcraft @ 2001-04-13 16:12 UTC (permalink / raw) 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- ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-07 21:17 ` Brian Rogoff 2001-04-07 21:25 ` Ayende Rahien @ 2001-04-10 1:41 ` Robert A Duff 2001-04-10 3:03 ` James Rogers 2001-04-10 4:26 ` Brian Rogoff 1 sibling, 2 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-10 1:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 1:41 ` Robert A Duff @ 2001-04-10 3:03 ` James Rogers 2001-04-10 3:58 ` Brian Rogoff 2001-04-10 4:26 ` Brian Rogoff 1 sibling, 1 reply; 87+ messages in thread From: James Rogers @ 2001-04-10 3:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 3:03 ` James Rogers @ 2001-04-10 3:58 ` Brian Rogoff 2001-04-10 21:48 ` Ted Dennison 0 siblings, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-10 3:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 3:58 ` Brian Rogoff @ 2001-04-10 21:48 ` Ted Dennison 2001-04-11 15:09 ` Ayende Rahien 0 siblings, 1 reply; 87+ messages in thread From: Ted Dennison @ 2001-04-10 21:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 21:48 ` Ted Dennison @ 2001-04-11 15:09 ` Ayende Rahien 2001-04-11 21:57 ` James Rogers 0 siblings, 1 reply; 87+ messages in thread From: Ayende Rahien @ 2001-04-11 15:09 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 15:09 ` Ayende Rahien @ 2001-04-11 21:57 ` James Rogers 2001-04-11 23:13 ` Brian Rogoff 2001-04-12 15:16 ` Ted Dennison 0 siblings, 2 replies; 87+ messages in thread From: James Rogers @ 2001-04-11 21:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 21:57 ` James Rogers @ 2001-04-11 23:13 ` Brian Rogoff 2001-04-12 6:33 ` Mats Karlssohn 2001-04-12 15:16 ` Ted Dennison 1 sibling, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-11 23:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 23:13 ` Brian Rogoff @ 2001-04-12 6:33 ` Mats Karlssohn 2001-04-12 16:38 ` Brian Rogoff 0 siblings, 1 reply; 87+ messages in thread From: Mats Karlssohn @ 2001-04-12 6:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-12 6:33 ` Mats Karlssohn @ 2001-04-12 16:38 ` Brian Rogoff 2001-04-17 7:04 ` Mats Karlssohn 0 siblings, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-12 16:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-12 16:38 ` Brian Rogoff @ 2001-04-17 7:04 ` Mats Karlssohn 2001-04-17 9:08 ` Jean-Pierre Rosen 0 siblings, 1 reply; 87+ messages in thread From: Mats Karlssohn @ 2001-04-17 7:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-17 7:04 ` Mats Karlssohn @ 2001-04-17 9:08 ` Jean-Pierre Rosen 0 siblings, 0 replies; 87+ messages in thread From: Jean-Pierre Rosen @ 2001-04-17 9:08 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 21:57 ` James Rogers 2001-04-11 23:13 ` Brian Rogoff @ 2001-04-12 15:16 ` Ted Dennison 2001-04-12 21:22 ` James Rogers 1 sibling, 1 reply; 87+ messages in thread From: Ted Dennison @ 2001-04-12 15:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-12 15:16 ` Ted Dennison @ 2001-04-12 21:22 ` James Rogers 0 siblings, 0 replies; 87+ messages in thread From: James Rogers @ 2001-04-12 21:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 1:41 ` Robert A Duff 2001-04-10 3:03 ` James Rogers @ 2001-04-10 4:26 ` Brian Rogoff 2001-04-11 15:30 ` Robert A Duff 1 sibling, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-10 4:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 4:26 ` Brian Rogoff @ 2001-04-11 15:30 ` Robert A Duff 2001-04-11 17:33 ` Brian Rogoff 0 siblings, 1 reply; 87+ messages in thread From: Robert A Duff @ 2001-04-11 15:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-11 15:30 ` Robert A Duff @ 2001-04-11 17:33 ` Brian Rogoff 0 siblings, 0 replies; 87+ messages in thread From: Brian Rogoff @ 2001-04-11 17:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-06 23:04 ` Brian Rogoff 2001-04-07 5:48 ` Jeffrey Carter 2001-04-07 19:30 ` Robert A Duff @ 2001-04-10 1:26 ` Robert A Duff 2001-04-10 2:11 ` Brian Rogoff 2 siblings, 1 reply; 87+ messages in thread From: Robert A Duff @ 2001-04-10 1:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 1:26 ` Robert A Duff @ 2001-04-10 2:11 ` Brian Rogoff 2001-04-14 0:00 ` Robert A Duff 0 siblings, 1 reply; 87+ messages in thread From: Brian Rogoff @ 2001-04-10 2:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: newbie can't get exceptions to work! 2001-04-10 2:11 ` Brian Rogoff @ 2001-04-14 0:00 ` Robert A Duff 0 siblings, 0 replies; 87+ messages in thread From: Robert A Duff @ 2001-04-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
end of thread, other threads:[~2001-04-17 9:08 UTC | newest] Thread overview: 87+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-04-05 3:19 newbie can't get exceptions to work! Jeff Shipman 2001-04-05 4:25 ` Ed Falis 2001-04-05 11:00 ` martin.m.dowie 2001-04-05 14:21 ` Ted Dennison 2001-04-05 17:50 ` Fraser Wilson 2001-04-05 4:34 ` Jeff Shipman 2001-04-05 4:59 ` Wilhelm Spickermann 2001-04-05 14:14 ` Ted Dennison 2001-04-05 16:37 ` Wilhelm Spickermann 2001-04-06 13:09 ` Marc A. Criley 2001-04-06 15:04 ` Ted Dennison 2001-04-06 16:43 ` Robert A Duff 2001-04-06 17:39 ` Ted Dennison 2001-04-06 21:50 ` Robert A Duff 2001-04-06 20:11 ` Brian Rogoff 2001-04-06 22:20 ` Robert A Duff 2001-04-06 23:04 ` Brian Rogoff 2001-04-07 5:48 ` Jeffrey Carter 2001-04-10 1:29 ` Robert A Duff 2001-04-07 19:30 ` Robert A Duff 2001-04-07 21:17 ` Brian Rogoff 2001-04-07 21:25 ` Ayende Rahien 2001-04-07 22:57 ` David Starner 2001-04-08 12:10 ` Ayende Rahien 2001-04-08 2:12 ` Larry Hazel 2001-04-08 12:12 ` Ayende Rahien 2001-04-09 16:20 ` Larry Hazel 2001-04-10 2:38 ` Ayende Rahien 2001-04-10 3:25 ` James Rogers 2001-04-08 22:18 ` Brian Rogoff 2001-04-09 15:14 ` Ted Dennison 2001-04-09 17:23 ` Brian Rogoff 2001-04-09 18:23 ` Laurent Guerby 2001-04-09 19:15 ` Brian Rogoff 2001-04-10 18:21 ` Laurent Guerby 2001-04-10 19:44 ` Brian Rogoff 2001-04-11 18:03 ` Laurent Guerby 2001-04-11 18:33 ` Samuel T. Harris 2001-04-14 0:06 ` Robert A Duff 2001-04-12 1:42 ` Mike Silva 2001-04-12 2:38 ` Brian Rogoff 2001-04-12 23:23 ` Laurent Guerby 2001-04-13 2:44 ` Brian Rogoff 2001-04-11 13:24 ` Ayende Rahien 2001-04-11 13:14 ` Mats Karlssohn 2001-04-11 15:08 ` Ayende Rahien 2001-04-11 21:42 ` Fraser Wilson 2001-04-12 23:55 ` Robert A Duff 2001-04-10 2:12 ` Robert A Duff 2001-04-10 3:47 ` Brian Rogoff 2001-04-10 13:40 ` Ada keywords (was: Re: newbie can't get exceptions to work!) Marin David Condic 2001-04-10 14:26 ` Jean-Pierre Rosen 2001-04-09 20:49 ` newbie can't get exceptions to work! Ted Dennison 2001-04-09 21:44 ` Brian Rogoff 2001-04-09 21:59 ` Ted Dennison 2001-04-10 2:54 ` Ayende Rahien 2001-04-10 14:00 ` Ted Dennison 2001-04-10 17:44 ` Fraser Wilson 2001-04-10 6:59 ` Mats Karlssohn 2001-04-10 14:18 ` Ted Dennison 2001-04-10 16:27 ` Mark Biggar 2001-04-11 11:55 ` Mats Karlssohn 2001-04-11 14:34 ` Samuel T. Harris 2001-04-11 15:50 ` Pat Rogers 2001-04-12 6:27 ` Mats Karlssohn 2001-04-11 11:49 ` Mats Karlssohn 2001-04-11 15:38 ` Robert A Duff 2001-04-13 16:12 ` Matthew Woodcraft 2001-04-10 1:41 ` Robert A Duff 2001-04-10 3:03 ` James Rogers 2001-04-10 3:58 ` Brian Rogoff 2001-04-10 21:48 ` Ted Dennison 2001-04-11 15:09 ` Ayende Rahien 2001-04-11 21:57 ` James Rogers 2001-04-11 23:13 ` Brian Rogoff 2001-04-12 6:33 ` Mats Karlssohn 2001-04-12 16:38 ` Brian Rogoff 2001-04-17 7:04 ` Mats Karlssohn 2001-04-17 9:08 ` Jean-Pierre Rosen 2001-04-12 15:16 ` Ted Dennison 2001-04-12 21:22 ` James Rogers 2001-04-10 4:26 ` Brian Rogoff 2001-04-11 15:30 ` Robert A Duff 2001-04-11 17:33 ` Brian Rogoff 2001-04-10 1:26 ` Robert A Duff 2001-04-10 2:11 ` Brian Rogoff 2001-04-14 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox