Why does that work?

Why does that work?

[Laurent]

Hi

Why does It.L.Head or Tail work?

It is of type Iterator defined as:

   type Iterator (L : access List) is
      record
         This :  List_Ptr:= null;
      end record;

If It points to the first node in the List L then It.This.Previous = null
and if It points to the last node in the List L then It.This.Next = null.

The pointers are working only in one direction I think? So if I am the pointer I will never see the head or the tail of the list. Probably a too simple/naive view. 

So how can It "know" something about the Head or Tail of the List? Is that caused by L: access List?

In my test program all the nodes are known at compile time. Didn't have the time to write a test to see what happens if I add one node to the list at runtime. Wouldn't that somehow cause a runtime error or simply not work as intended?

Just a small example:

   procedure Add_To_End (L : access List; Element : in Element_Type) is
      It : Iterator (L);

      begin -- Add_To_End
      
         if It.L.Head = null then -- List L is empty
            It.L.Head := new List_Node'(Element, null, null);
            It.L.Tail := It.L.Head;

         else
            It.L.Tail.Next := new List_Node'(Element, null, It.L.Tail);
            It.L.Tail := It.L.Tail.Next;
         end if;
      end Add_To_End;

Hm the first time I whine about something working and I didn't expect it :)

Thanks

Laurent

Why does that work?

[Laurent]

Ah great again a case of the lights are on but nobody at home. I have posted the wrong example code. In this case L is visible. 

I will post the correct one when I am back home. In this case L is not visible and I get access to head/tail via the iterator.

Laurent

Re: Why does that work?

[David Botton]

> Ah great again a case of the lights are on but nobody at home.

Rude.

Re: Why does that work?

[Simon Wright]

David Botton <david@botton.com> writes:

>> Ah great again a case of the lights are on but nobody at home.
>
> Rude.

I think OP is allowed to be rude about himself!

Re: Why does that work?

[Laurent]

On Wednesday, March 4, 2015 at 6:35:55 PM UTC+1, Simon Wright wrote:
> David Botton writes:
> 
> >> Ah great again a case of the lights are on but nobody at home.
> >
> > Rude.
> 
> I think OP is allowed to be rude about himself!

Right. I am always amazed who different my thinking is when I suffer under a f*cking migraine attack. Even if the pain is gone by swallowing some pills but the logic is still suffering :(

   procedure Remove_Node (It : in Iterator) is
      Temp : List_Ptr := It.This;

   begin -- Remove_Node

      if It.This = null then -- List is empty or no node found
         Ada.Text_IO.Put_Line ("No item to delete");

      elsif It.This.Previous = null then -- case 1: It = First node
         It.L.Head := It.This.Next;
         It.This.Next.Previous:= null;
         Dispose (X => Temp);

      elsif It.This.Next = null then -- case 2: It = Last node
         It.L.Tail := It.This.Previous;
         It.This.Previous.Next := null;
         Dispose (X => Temp);

      else -- case 3: It is an intermediate node
         It.This.Previous.Next := It.This.Next;
         It.This.Next.Previous := It.This.Previous;
         Dispose (X => Temp);
      end if;
   end Remove_Node;

It is this procedure which works differently than I expected.  Because I have no direct access to the list L and its head/tail.

The first one I posted doesn't even need an iterator.

The first solution I figured out was horrible and allowed something stupid like searching in L3 but trying to delete in L2 :

GL_Int.Remove_Node (List=> L3'Access, It => Aux_IO.Search (L => L3'Access, Element => Search_For));

But using the iterator I have a workaround but I don't understand how that is possible.

GL_Int.Remove_Node ( It => Aux_IO.Search (L => L3'Access, Element => Search_For));

I thought that the iterator is part of the list but that could be wrong. So the list is part of the iterator. Aka it is not the spaceship which moves but the universe around it? (sry couldn't resist citing the explanation from Futurama((tm))).

So if someone could clarify this.

Thanks

Laurent

Re: Why does that work?

[jan.de.kruyf]

On Wednesday, March 4, 2015 at 8:38:58 PM UTC+2, Laurent wrote:


> Right. I am always amazed who different my thinking is when I suffer under a f*cking migraine attack. Even if the pain is gone by swallowing some pills but the logic is still suffering :(
> 
>    procedure Remove_Node (It : in Iterator) is
>       Temp : List_Ptr := It.This;
> 
>    begin -- Remove_Node
> 
>       if It.This = null then -- List is empty or no node found
>          Ada.Text_IO.Put_Line ("No item to delete");
> 
>       elsif It.This.Previous = null then -- case 1: It = First node
>          It.L.Head := It.This.Next;
>          It.This.Next.Previous:= null;
>          Dispose (X => Temp);
> 
>       elsif It.This.Next = null then -- case 2: It = Last node
>          It.L.Tail := It.This.Previous;
>          It.This.Previous.Next := null;
>          Dispose (X => Temp);
> 
>       else -- case 3: It is an intermediate node
>          It.This.Previous.Next := It.This.Next;
>          It.This.Next.Previous := It.This.Previous;
>          Dispose (X => Temp);
>       end if;
>    end Remove_Node;
> 
> It is this procedure which works differently than I expected.  Because I have no direct access to the list L and its head/tail.
> 
> The first one I posted doesn't even need an iterator.
> 
> The first solution I figured out was horrible and allowed something stupid like searching in L3 but trying to delete in L2 :
> 
> GL_Int.Remove_Node (List=> L3'Access, It => Aux_IO.Search (L => L3'Access, Element => Search_For));
> 
> But using the iterator I have a workaround but I don't understand how that is possible.
> 
> GL_Int.Remove_Node ( It => Aux_IO.Search (L => L3'Access, Element => Search_For));
> 
> I thought that the iterator is part of the list but that could be wrong. So the list is part of the iterator. Aka it is not the spaceship which moves but the universe around it? (sry couldn't resist citing the explanation from Futurama((tm))).
> 
> So if someone could clarify this.
> 
>

play some sweet music while you read this:

http://kto.web.elte.hu/teaching/ada/books/ase.pdf

After you finished the migraine will be gone _and_ you will have the answer to your question.

This version is a bit old, but still it has all you need to know to solve this issue. And it is by a very competent teacher.

May peace be with you.

j.

Re: Why does that work?

[Laurent]

> kto.web.elte.hu/teaching/ada/books/ase.pdf
 
> This version is a bit old, but still it has all you need to know to solve this issue. And it is by a >very competent teacher.


Thanks for the link to this book. Have just overflown it and found a few things which would have answered  some of my earlier questions.  Very condensed but better than reading tenth of pages and not finding what I actually want to know.

The actual question is more curiosity than a problem. 

I would prefer to have an evening course in Ada but unfortunately none is offered in my region. I have the choice between VBA or Java.
Tried the Java one but did't like it. Perhaps if I hadn't already tasted Ada before things would have been different.

Thanks

Laurent

Ada Video Course

[David Botton]

> I would prefer to have an evening course in Ada

That goes back to an early post I made, does any one have a complete course in Video of programming in Ada we could post up? If not perhaps a few of us could team up and do different sections? Any takers?

David Botton

Re: Ada Video Course

[Jacob Sparre Andersen]

David Botton <david@botton.com> writes:

> That goes back to an early post I made, does any one have a complete
> course in Video of programming in Ada we could post up?

There is <http://university.adacore.com/>, but it doesn't work with my
browser, so I can't tell you how good/complete it is.

> If not perhaps a few of us could team up and do different sections?
> Any takers?

I think it is interesting to consider.

But I'm not certain of the value of video recorded lectures.  There is
no more interaction between the lecturer and the students than in a
book, and it is my impression that it takes at least as much work as
writing a decent text for the same content.

What would the benefits be?  How would we give the students the
interaction needed to make it any different from just telling them to
read a good book and solve the exercises in it?

Doing it as a distributed project would also pose challenges of its own.
I'm not certain we all agree how such a course should be structured.

But if we can find a way, then I'm certainly willing to supply a few
lectures.

Greetings,

Jacob
-- 
"I remember being impressed with Ada because you could write
 an infinite loop without a faked up condition. The idea
 being that in Ada the typical infinite loop would normally
 be terminated by detonation."                 -- Larry Wall

Re: Ada Video Course

[G.B.]

On 06.03.15 16:42, Jacob Sparre Andersen wrote:
> But I'm not certain of the value of video recorded lectures.

One added value of a recorded lecture is different input
channels: eyes and ears will notice new aspects in the
communication. Emphasis of words is just one surplus that
a good, knowledgeable presenter will offer. More so
if questions and answers will be part an integral the lecture.

OTOH, courses are a source of income for presenters and,
therefore, enthusiasm may be limited by economic considerations.
Cf. O'Reilly video lectures.

Re: Ada Video Course

[David Botton]

> I think it is interesting to consider.
> 
> But I'm not certain of the value of video recorded lectures.

After other discussions on #ada and more thought about how I teach or others teach, the key to any value in these lectures would not be trying to regurgitate a text.

A collection of insights on areas of programming Ada, techniques, approaches to the language or development in general, etc.

So even if multiple people participated with lectures on the same subject each would add, each would be a unique perspective and likely worth a view even by the experienced developer.

I would do this by asking for some slides, could even be one or two, and a webcam recording. More is possible but everyone has the means to do that.

Here are some examples that pop in to my mind:

1. Why "type" is king in Ada
2. The mystery of the memory pool
3. Tricks to writing high level bindings

Perhaps some experience type recordings:

1. Two is better than one - XP in action
2. Where a debugger comes in handy
3. Patterns and the reality of solving domain issues in design

etc.

> But if we can find a way, then I'm certainly willing to supply a few
> lectures.

I think such a collection would be a clear win win for everyone. Teacher, student, Ada, the field in general, etc.

Nothing replaces first person interaction, this would be enrichment.

David Botton

Re: Why does that work?

[jan.de.kruyf]

On Thursday, March 5, 2015 at 11:16:21 PM UTC+2, Laurent wrote:

> 
> The actual question is more curiosity than a problem. 
> 

Basically the iterator (a record) has a pointer to the list structure, so that is why the list head an tail can be addressed via the iterator.
And the iterator has a pointer to the current list item of course, in order to address the individual items via an iterator.

And the list itself is a linked list with forward (to the next item) and backward (to the previous item) links in each item.
So the item is a record again, and the list is a series of those records linked together via the forward and the backward links.

Please read Moti Ben Ari carefully, he is one of the very few teachers that manages to actually _teach_ in stead of just burbling little knowledge items.

Here you will find source code for some of the examples:

http://www.weizmann.ac.il/sci-tea/benari/books/index.html

look for the second edition of the book. I think its one edition ahead of the pdf, But hopefully they will still be similar.


The sun rose beautifully this morning. The whole world is full of Glory!
Sometimes I stand in awe.

j.

Re: Why does that work?

[Laurent]

I have bought the 2nd edition as ebook yesterday. Funny enough when I read the 2 comments on amazon.de the critics were rather bad and didn't recommend it.

The biggest problem I have with all this stuff is that I best understand abstract problems when they are represented visually. One example was recursion. When I read about it the text didn't make any sense to me. When I then looked at the animation in the wikipedia it answered all my questions within seconds.

Ok I can make a drawing myself but that doesn't mean that it is actuall correct. That's why I'd prefer to talk/listen to some real person. I am quite happy with the help I get on this forum but I have sometimes the impression that my question was/is not interpreted the way I actually meant it to be.

You guys have my greatest respect. Working all day long, having your own problems and then still having the motivation to help some noob with his silly question :)

Many thanks

Laurent

Re: Why does that work?

[G.B.]

On 06.03.15 14:28, Laurent wrote:
> I have bought the 2nd edition as ebook yesterday. Funny enough when I read the 2 comments on amazon.de the critics were rather bad and didn't recommend it.

Specifically, the complaint (also seen in English reviews)
is that the book has close ties with the LRM, frequently
quoting it, making readers wonder why the book then…

Needless to say, its audience is assumed to be prepared,
somewhat experienced, patient, and ready to tackle a number
of different formal concepts. Some reviewers do not recommend
this book to beginners in programming, but rather for use
by those wishing to now do software engineering, in Ada.

Re: Why does that work?

[jan.de.kruyf]

On Friday, March 6, 2015 at 4:07:30 PM UTC+2, G.B. wrote:

> Needless to say, its audience is assumed to be prepared,
> somewhat experienced, patient, and ready to tackle a number
> of different formal concepts. Some reviewers do not recommend
> this book to beginners in programming, but rather for use
> by those wishing to now do software engineering, in Ada.

That is all perhaps true, but he tries to instill the art of reading the LRM,
which has great value.
I also was a bit taken aback by that when I first saw it, but now I have learned to go to the LRM first and not to all the pseudo software engineers that tried to make a quick buck out of some book.

And he _does_ approach the subject methodically with reasonably small increases in learning matter, And it is very much hands on (at least if you bother t follow the examples).

A person that just wants to hack away should do ruby or python or perl or basic or any of them, and feel challenged all day long.

But if you want to do programming the proper way, this is not a bad start.

cheers,
j.