Normalized syntax for LinkedList assignment commands

[Blue]

I find the existing syntax/process for adding elements to linked lists quite surprising.
It's not in keeping with the rest of the PureBasic commands.

Most PB commands adhere to a regular syntax:

Code: Select all

CommandName (paramA, paramB, ...)

as in

Code: Select all

 --> SetGadgetText(#Gadget, Text$)
 --> ToolBarToolTip(#ToolBar, ButtonID, Text$) 
 --> AddDate(Date, Field, Value)

Once you know the syntax of one command, you know it for them all.
It makes working with the language easy: you may forget the exact wording of a command, but you never have to struggle with the syntax: it's always the same... or almost !

When it comes to Linked Lists, unexpectedly, things diverge.
Where you expect...

Code: Select all

 --> AddElement(Queue(), value)
 --> InsertElement(Queue(), value)

in keeping with the usual, regular, PB way,
you discover a 2-step process:

Code: Select all

AddElement(Queue())  ; create the element in memory
   Queue() = value  ; give it a vakue

InsertElement(Queue())
   Queue() = value

I find this syntax counter-intuitive.
It would be great if the syntax of those 2 commands was normalized in the usual PB way.


As well, i'd like to point out an omission in the Help file index:
the NewList command does not appear in the list of available commands under the LinkedList section.

[Kale]

I Agree

[freak]

And what type does the value have ? What about structured lists ?

[Kaeru Gaman]

indeed.

you would need a structured dummy element to pre-store the values and pass it byRef, i.e. a pointer to it in AddElement.
in my exes is this highly counterproductive.

where should be the advantage of this:

Code: Select all

Define Dummy.Struct
Dummy\Name       = "Washington"
Dummy\FirstName  = "Leroy Fiztgerald"
Dummy\Addr       = "Park Ave 23"
Dummy\Town       = "Beverly Hills"
Dummy\ZIP        = "90210"
Dummy\Phone      = "1-800-555-0123"
Dummy\Account    = "235679234"
AddElement( Customers(), @Dummy )

compared to this:

Code: Select all

AddElement( Customers() )
Customers()\Name       = "Washington"
Customers()\FirstName  = "Leroy Fiztgerald"
Customers()\Addr       = "Park Ave 23"
Customers()\Town       = "Beverly Hills"
Customers()\ZIP        = "90210"
Customers()\Phone      = "1-800-555-0123"
Customers()\Account    = "235679234"

[Joakim Christiansen]

And what type does the value have ? What about structured lists ?

1+

[Kale]

And what type does the value have ? What about structured lists ?

Point well taken, argument withdrawn.

[Blue]

And what type does the value have ? What about structured lists ?

At present, you write (snippet from your breadth-first search with a queue)

Code: Select all

NewList Queue.s() 
AddElement(Queue()) 
Queue() = "C:"

to declare a linked kist of string elements, don't you?

If the syntax was

Code: Select all

NewList Queue.s() 
AddElement(Queue(), "C:"

wouldn't that be exactly the same? The type declaration wouldn't change, but the assignment to a new element would be written in the familiar PB fashion. Where we have 2 steps (create the memory structure followed by an assignment), we'd have only one.

I don't know the underlying plumbing of PB, so maybe i'm skipping too lightly (and very innocently) over important considerations here.
But from my point of view, a user's point of view, the suggested form appears as a just a different way of writing the same thing. And I'd much prefer that one to the present one.

Of course, from your point of view, the Master Plumber's POV, the whole suggestion to combine the current 2 steps into one may appear totally unrealistic because of things that i don't even suspect.

So, my simple answer to your original question, would be, for the time being, "Humm... I don't really know."

If you think such a change is mission impossible, so be it. Too bad.
But i definitely find the current construction strange and un-PB like !

[Blue]

indeed.

you would need a structured dummy element to pre-store the values and pass it byRef, i.e. a pointer to it in AddElement.
in my exes is this highly counterproductive.
[...]

Very good demonstration of why my suggestion wouldn't make sense in many cases.

As i mention in my answer to Freak, just above, i don't know all the ins & outs of using linked lists. I was of course thinking of elements as single discrete values of basic types.
With your example, I can see why things are done the way they are presently.

Thanks, Kaeru Gaman.

[Kaeru Gaman]

you're welcome.

... in my eyes, using structures elements is the essential use of LList.
I coded in PB and used LLists for two years or so, before I realized it is even possible to assign simetype elements to a LList.
I had never tested it, because it just was of no use at all for me.

when I have single type elements, I need at least some kind of reference that makes up an order, so I use an Array to have an Index...

[Fred]

You can indeed do a procedure if you want one call access all accross your program.

[Blue]

You can indeed do a procedure if you want one call access all accross your program.

Good point, indeed, or a macro.
Thanks for the input

However this was not so much about something i wanted, in a practical way, as much as something i perceived as being at odds with the rest of the language.

Kaeru Gaman's example opened my eyes. I never thought of Linked Lists in that way. Now, of course, it's all so very obvious !!! Pfttt...

May i suggest that Kaeru Gaman's example, or something very similar, be added to the Help file's examples. That would better demonstrate some practical use of Linked Lists.