From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,635cd9622b25ae59
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!news.glorb.com!newsfeeder.wxs.nl!feeder1.cambrium.nl!feed.tweaknews.nl!proxad.net!newsfeed.arcor.de!news.arcor.de!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: Type safety, C++ and code generation
From: Georg Bauhaus <bauhaus@futureapps.de>
In-Reply-To: <1146227854.112808.257290@g10g2000cwb.googlegroups.com>
References: <e2q6p8$idj$1@sunnews.cern.ch>
	 <1146143954.169807.207080@t31g2000cwb.googlegroups.com>
	 <e2qj9l$edt$1@sunnews.cern.ch>
	 <1146148380.102042.119860@y43g2000cwc.googlegroups.com>
	 <e2qn8t$n13$1@sunnews.cern.ch>
	 <445101bf$0$11061$9b4e6d93@newsread4.arcor-online.net>
	 <e2sark$65f$1@sunnews.cern.ch>
	 <1146226568.9048.7.camel@localhost.localdomain>
	 <1146227854.112808.257290@g10g2000cwb.googlegroups.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: #
Message-ID: <1146243856.17221.5.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.4.1 
Date: Fri, 28 Apr 2006 19:04:17 +0200
NNTP-Posting-Date: 28 Apr 2006 19:03:46 MEST
NNTP-Posting-Host: 1536a569.newsread2.arcor-online.net
X-Trace: 
 DXC=YL`?19[SAf\>K]\3>m]<[UQ5U85hF6f;TjW\KbG]kaMXVA=iV<7g:2UN71C_Yj7TQ^=0F65HQV8iVe8Od<X?jRM[
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:3989
Date: 2006-04-28T19:03:46+02:00
List-Id: <comp.lang.ada>

On Fri, 2006-04-28 at 05:37 -0700, brian.b.mcguinness@lmco.com wrote:
> Georg Bauhaus wrote:
> > How many times does "/" occur in your average computer
> > program?
> 
> That depends on what field you're working in. 

True. Yet, I'd have to speculate that "general purpose" design 
is then influenced strongly by a particular field :)


> One solution to the problem would be to provide a new keyword for
> defining types with no default operations.  Only the operations you
> explicitly defined would be available.

I wonder whether it wouldn't be more flexible to use the
regular language means for defining types with operations,
and no predefined operations. Then provide some core packages
for "numbers with an arithmetical interface".


-- Georg