Re: Dummy

Re: Dummy

[Gautier]

Simic_10111:

You will read more <<learned>> answers about it in c.l.a but...

> has Ada anything to do with OOP?

Ada95 (the current Ada): yes. ISO standard!

> is Ada conceptually easy and intuitive?

Very subjective question... I would say: it is a model.
Unambiguous, clear names, easy to read, re-read, program.
The precise conception of Ada leads the compilers to point
most errors at compile-time. At beginning it may appear
pedantic to death, but it saves ages of run-time debugging.

> is Ada an imperative language?
Y.

> d'ye have any tutorial (apart Lovelace) or ebook for me to study?

The sites http://www.adahome.com/ and http://www.adapower.com/ 
lead huge Web resources in Ada...
Some links from home page...
HTH
-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Dummy

[Simic_10111]

Hi I am an italian guy studying Java and interested in Ada.
Some little questions:
has Ada anything to do with OOP?
is Ada conceptually easy and intuitive?
is Ada an imperative language?
d'ye have any tutorial (apart Lovelace) or ebook for me to study?

10x in advance :))

Re: Dummy

[Ehud Lamm]

On Tue, 11 Jan 2000, Simic_10111 wrote:

|has Ada anything to do with OOP?

Yep. Ada has the facilites for industrial strength OO. There are many
source covering this. I myself prefer the Ada95 Rational (see on Adapower)
II.4.

|is Ada conceptually easy and intuitive?

This depends. It is in the eyes of the beholder.
But one thing that makes Ada a favorite is the emphaisze of writing code
that is readable. This makes it easier to learn the language (from
examples etc.) 
Of course, that deep dehind the covers Ada has all the machinary needed
for a full-blown, robust language. But for a programmer, not interested in
these details, the syntax is pretty straight forward (esp. if you are
faimiliar with Pascal etc.)

|is Ada an imperative language?

Yes.

|d'ye have any tutorial (apart Lovelace) or ebook for me to study?

Check www.adapower.com for links.
Also see my site.

I do not know of any useful complete ebook on Ada.


Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Dummy

[Simic_10111]

HI y'all guys, here it is an italian guy, Andrea, who is curious bout
Ada. I am studying Java rite now so the first question hafta be:
is Ada in any way related to OOP?
is Ada meant to be portable? I guess only for the source code, rite?
is Ada conceptually hard to learn? Someone told me it's an imperative
language.
has Ada anything to do with working with memory allocations? That
makes me mad...
Can you suggest a good tutorial or e-book?

Thanks in advance :))

Re: Dummy

[Gautier]

> Java casts are always perfectly safe. Casts between object types are
> akin to C++'s dynamic_cast<T>, in that they are type-checked at runtime
                                                  ^^^^^^^^^^^^^^^^^^^^^^^
Cultural questions: isn't it a redhibitory source of slowndowns ?! Is there
a mean to make such type checking at compile time in Java ?...

> and will fail if the cast is not valid.


-- 
Gautier

_____\\________________\_______\
http://members.xoom.com/gdemont/

Re: Dummy

[Larry Kilgallen]

In article <t7d7qe2xab.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> writes:
> Charles Hixson <charleshixsn@earthlink.net> writes:
>> Java is more Object Oriented than Ada is, but less type safe.
>> (Those casts are a really bad idea that is carried forwards from C.)
> 
> Java casts are always perfectly safe. Casts between object types are
> akin to C++'s dynamic_cast<T>, in that they are type-checked at runtime
> and will fail if the cast is not valid.

To me "perfectly safe" does not allow "fail at runtime".

Presumably "Spark for Java" would disallow this.

Re: Dummy

[Larry Kilgallen]

In article <t7zoti1cd7.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> writes:
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
>> To me "perfectly safe" does not allow "fail at runtime".
> 
> Nonsense. Ada has very similar situations. For example, suppose you
> have a dispatching function with more than one parameter of the
> controlling type. Ada will conduct a runtime check to make sure that
> all the controlling parameters have the same derived type when the
> call is made.

My comment was about the term "perfectly safe".
Your response was about the capabilities of Ada.
Am I missing the post of a third person who characterized Ada
as "perfectly safe" ?

Certainly Ada is not "perfectly safe", or Spark would not exist.
(I am not claiming that Spark is "perfectly safe".)

> "Perfectly safe" means that either the operation succeeds, or you
> are informed that the operation failed.

I have not read that as a formal definition in Ada books,
nor read it in this newsgroup.  I took it as ordinary use
of English.

Larry Kilgallen

Re: Dummy

[Hyman Rosen]

Charles Hixson <charleshixsn@earthlink.net> writes:
> Java is more Object Oriented than Ada is, but less type safe.
> (Those casts are a really bad idea that is carried forwards from C.)

Java casts are always perfectly safe. Casts between object types are
akin to C++'s dynamic_cast<T>, in that they are type-checked at runtime
and will fail if the cast is not valid.

Re: Dummy

[Hyman Rosen]

Gautier <gautier.demontmollin@maths.unine.ch> writes:
> > Java casts are always perfectly safe. Casts between object types are
> > akin to C++'s dynamic_cast<T>, in that they are type-checked at runtime
>                                                   ^^^^^^^^^^^^^^^^^^^^^^^
> Cultural questions: isn't it a redhibitory source of slowndowns ?! Is there
> a mean to make such type checking at compile time in Java ?...

What's "redhibitory"? Anyway, the compiler can elide a runtime check if
it can prove that the cast would always succeed.

Re: Dummy

[Hyman Rosen]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> To me "perfectly safe" does not allow "fail at runtime".

Nonsense. Ada has very similar situations. For example, suppose you
have a dispatching function with more than one parameter of the
controlling type. Ada will conduct a runtime check to make sure that
all the controlling parameters have the same derived type when the
call is made.

"Perfectly safe" means that either the operation succeeds, or you
are informed that the operation failed.

Re: Dummy

[Tucker Taft]

Hyman Rosen wrote:
> 
> Charles Hixson <charleshixsn@earthlink.net> writes:
> > Java is more Object Oriented than Ada is, but less type safe.
> > (Those casts are a really bad idea that is carried forwards from C.)
> 
> Java casts are always perfectly safe. Casts between object types are
> akin to C++'s dynamic_cast<T>, in that they are type-checked at runtime
> and will fail if the cast is not valid.

Java and Ada are approximately equal in "safety" when it comes to 
"object-oriented" types.  (Ada allows the distinction between "specific"
and "class-wide" which Java does not support, and the corresponding
option of static versus dynamic binding of calls on primitive operations.
This might be considered more "type safe" in some people's view.
Finally, Ada has local/stack-resident composite objects; all composite
objects in Java are allocated out of the heap -- there is no compile-time
way to ensure their lifetime is limited to a single function invocation.)  

Ada has much more type safety than Java when looking at numeric or
enumeration types.  Ada's arrays are also more strongly typed,
because only the declared index type may be used for indexing,
whereas in Java, any integral type may index any array.

Ada also allows compile-time distinctions between access (reference) 
types, each with potentially its own heap.  In Java, all objects
are dynamically allocated out of a single garbage-collected heap.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Dummy

[Robert A Duff]

Tucker Taft <stt@averstar.com> writes:

> Java and Ada are approximately equal in "safety" when it comes to 
> "object-oriented" types.

An important difference is that when you have some sort of container,
Java doesn't keep track (at compile time) of the types of the contained
objects.  In Ada, a generic can do that quite nicely.

- Bob

Re: Dummy

[Robert A Duff]

Florian Weimer <someone@deneb.cygnus.argh.org> writes:

> Does this mean that that the finalization of local variables is
> non-deterministic in Java?  Ugh.

Yes.  Finalization happens in Java whenever the garbage collector gets
around to noticing that it's needed.

For a generational GC (which I assume is a legal implementation of Java
GC), that could be quite a long time.

- Bob

Re: Dummy

[Florian Weimer]

Tucker Taft <stt@averstar.com> writes:

> Finally, Ada has local/stack-resident composite objects; all composite
> objects in Java are allocated out of the heap -- there is no compile-time
> way to ensure their lifetime is limited to a single function invocation.)  

Does this mean that that the finalization of local variables is
non-deterministic in Java?  Ugh.

Re: Dummy

[Marin D. Condic]

JRoss wrote:
> 
> This brings up a good point.  Where is the "Ada for Dummies" book?
> Perhaps, it is just too oxymoron for such a title?  Perhaps it would
> be just the ticket for Ada fashionableness.
> 
The title should be: "Ada for smart people because all the dummies are
using C++" ;-)

Bard Crawford is working on something like this and has mentioned it in
this forum. You probably want to watch for developments from his effort.
It looks good.

MDC
-- 
=============================================================
Marin David Condic   - Quadrus Corporation -   1.800.555.3393
1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233
http://www.quadruscorp.com/
m c o n d i c @ q u a d r u s c o r p . c o m

Visit my web site at:  http://www.mcondic.com/

"Capitalism without failure is like religion without sin." 
        --  Allan Meltzer, Economist 
=============================================================

Re: Dummy

[Jean-Pierre Rosen]

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


Robert A Duff <bobduff@world.std.com> a �crit dans le message :
wcc66w4rcy5.fsf@world.std.com...
> Florian Weimer <someone@deneb.cygnus.argh.org> writes:
>
> > Does this mean that that the finalization of local variables is
> > non-deterministic in Java?  Ugh.
>
> Yes.  Finalization happens in Java whenever the garbage collector gets
> around to noticing that it's needed.
>
It's even worse. The finalization routine is allowed to resurect the object
(for example, by assigning it to some live variable), however it is
guaranteed that in that case, finalization will *not* be invoked again, when
the object becomes inaccessible for the second time.

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

Re: Dummy

[Hyman Rosen]

Florian Weimer <someone@deneb.cygnus.argh.org> writes:
> Does this mean that that the finalization of local variables is
> non-deterministic in Java?  Ugh.

Local variables aren't local in the usual sense:

class a
{
	interface i
	{
		int get();
		void set(int n);
	}
	i local_ref()
	{
		int local;
		return new i {
			int get() { return local; }
			void set(int n) { local = n; }
		};
	}
	static void main(String[] v)
	{
		i i1 = local_ref();
		i i2 = local_ref();
		i1.set(3);
		i2.set(4);
		System.out.println(i1.get());
		System.out.println(i2.get());
	}
}

Re: Dummy

[Florian Weimer]

Hyman Rosen <hymie@prolifics.com> writes:

> class a
> {
> 	interface i
> 	{
> 		int get();
> 		void set(int n);
> 	}
> 	i local_ref()
> 	{
> 		int local;
> 		return new i {
> 			int get() { return local; }
> 			void set(int n) { local = n; }
> 		};
> 	}
> 	static void main(String[] v)
> 	{
> 		i i1 = local_ref();
> 		i i2 = local_ref();
> 		i1.set(3);
> 		i2.set(4);
> 		System.out.println(i1.get());
> 		System.out.println(i2.get());
> 	}
> }

This prints `3' and `4', doesn't it?  Cool.  I didn't know that Java
supports class closures.  Now Java only needs operator overloading
and some syntactic sugar for dispatching by name and introspection,
and Java will become my favorite scripting language. ;)

Re: Dummy

[Hyman Rosen]

Florian Weimer <someone@deneb.cygnus.argh.org> writes:
> This prints `3' and `4', doesn't it?  Cool.  I didn't know that Java
> supports class closures.  Now Java only needs operator overloading
> and some syntactic sugar for dispatching by name and introspection,
> and Java will become my favorite scripting language. ;)

Actually, I'm wrong about this. I was over-ambitious. The following
similar code does work, though. The trick is that the "closures" are
fake - behind the scenes, Java copies the referenced locals into the
local class, and only lets you do this with "final" variables.

class a
{
	interface i
	{
		int get();
		void set(int n);
	}
	class my_int implements i
	{
		int val;
		public int get() { return val; }
		public void set(int n) { val = n; }
	}
	i local_ref()
	{
		final my_int local = new my_int();
		return new i () {
			public int get() { return local.get(); }
			public void set(int n) { local.set(n); }
		};
	}
	public static void main(String[] v)
	{
		a my_a = new a();
		i i1 = my_a.local_ref();
		i i2 = my_a.local_ref();
		i1.set(3);
		i2.set(4);
		System.out.println(i1.get());
		System.out.println(i2.get());
	}
}

Re: Dummy

[Geoff Bull]

Jean-Pierre Rosen wrote:
> 
> Robert A Duff <bobduff@world.std.com> a �crit dans le message :
> wcc66w4rcy5.fsf@world.std.com...
> > Florian Weimer <someone@deneb.cygnus.argh.org> writes:
> >
> > > Does this mean that that the finalization of local variables is
> > > non-deterministic in Java?  Ugh.
> >
> > Yes.  Finalization happens in Java whenever the garbage collector gets
> > around to noticing that it's needed.
> >
> It's even worse. The finalization routine is allowed to resurect the object
> (for example, by assigning it to some live variable), however it is
> guaranteed that in that case, finalization will *not* be invoked again, when
> the object becomes inaccessible for the second time.

It's even worse, although finalizers in Java are guaranteed to be never
invoked more than once, the are not guaranteed to be invoked at least
once.
This makes finalizers essentially useless for cleaning up resources etc.
It used to be possible to ask the VM to run finalizers at exit, but that
method has been deprecated.