PureBasic Forums - English

And yes, I have seen other requests for these... they would make excellent built-ins.
I hope that these are four things that would really help everyone write simpler code!
(Listed in ascending order of importance)

*** Simplified List Handling ***

Add an element to the K list should not require two statements:
AddElement(K())
K() = "New List element"

Should be allowed by:

append(k()) = "New List Element"

Same for insert...

*** We need a built in split/explode command ***
Sorry, the stringfield command is close but not enough.
We should be able to split any string into an array without
writing a subroutine each time.

And of course we need the inverse command as well:
To combine an array into a string (with or without delimiter)

The php syntax is my favorite, but the name doesn't matter:
f$() = explode(g$,"*") ; take it apart
h$() = implode(f$,"*") ; put it back together


*** Trim vs. Trimm ***

So, in newer languages, trim() gets rid of all common whitespace characters
but in purebasic, it acts in the old 1967 way. Very nostalgic for me!

I have written a function called trimm() that does
this. I think Purebasic should adopt it... then you can have old
BASIC style trim() and let newcomers use the better trimm() statement!

It should remove the following: space, tab, newline, cr and maybe
backspace or any combo of them. That way programmers coming from
modern scripting languages can adapt their code more easily. If we are
to have a huge user base, we should add such updates.

And yes, I know it's harder to do this in multibyte.

*** HEREDOC / TEXT STRINGS ***

There are 2 little issues:

a. It's painful to work with assigning big text.
b. It is painful to hide text strings from casual inspection.

FIRST, we really need support for this syntax:

f$ = "
a really long bunch of text that I want to include
and that has simple CR/LF or just CR at the end, but
you can't see it. However, I'm going to write all
this out and not worry about putting in all the a$+quote
stuff because I just want to write out my text and be done
with it"

instead of

f$ + "some words words words"
f$ + "more words words words"

AND AS WELL (and frequently asked about):

We need the ability to embed text that is somewhat obscured from
the user. It doesn't have to be super duper encryption, but the
raw text shouldn't be seen casually. And yes, I know that for real
security you must roll your own... but I only care to have a little
misdirection.

Therefore I suggest that if we can't have both, Purebasic adds a
tool like:

f$ = embed("monkeys and sheep are roller skating!")
and also
f$ = embed("
I am a long exception to how the compiler normally works
and so my text will be read until the end of the paragraph
and then saved into a buffer where we randomly xor against
the character position (so char xor pos) and now we have
unreadable text in the executable.
")

At compile time, the strings are obfuscated and handled as
normal. However, at run time, when the variable assignment is
being made, the program simply reverse the process and inserts
the decoded string into the variable as plain text!

Everyone wins!

The actual method doesn't matter - but with this it would
require that end users be willing to crack the software instead
of just sniffing around. Sometimes strings reveal things we
dont want the curious user to know.

Thank you!

Bo Marchais wrote:
f$ = "
a really long bunch of text that I want to include
and that has simple CR/LF or just CR at the end, but
you can't see it. However, I'm going to write all
this out and not worry about putting in all the a$+quote
stuff because I just want to write out my text and be done
with it"

instead of

f$ + "some words words words"
f$ + "more words words words"

Not as simple as you want, but actually you can write long strings like this

For things like append(), you can use a macro :
I know it's not the same thing, but put your macro in a pbi and you can use them in all your project

Blendman,
You should see how many i use now!

My only point is that everyone trips over these same small details, and most languages have adopted such simplified syntax.
Rule 1: All programmers are very, very lazy.
Rule 2: Productive programmers are even lazier - they always want the best result with the least effort.
Rule 3: Prebuilt code is the best for trivial things, it saves us from doing 20 steps to accomplish 1 thing.

PS - I really like your project, it's exciting. Your demo shots are cool. Is your name a reference to blender?

Bo Marchais wrote:Add an element to the K list should not require two statements:
AddElement(K())
K() = "New List element"

Should be allowed by:

append(k()) = "New List Element"

This is not generally possible, since in PB there are not only lists of simple variables such as strings, integers etc., but also lists of structures, lists of arrays, lists of lists etc.

Bo Marchais wrote:*** Trim vs. Trimm ***

So, in newer languages, trim() gets rid of all common whitespace characters
but in purebasic, it acts in the old 1967 way. Very nostalgic for me!

I have written a function called trimm() that does
this. I think Purebasic should adopt it... then you can have old
BASIC style trim() and let newcomers use the better trimm() statement!

No, please! Having both a Trim() function and a Trimm() function would be very ugly, it would probably confuse newcomers, and cause unnecessary problems for dyslexic people.

Bo Marchais wrote:It should remove the following: space, tab, newline, cr and maybe
backspace or any combo of them.

Such a function with a fixed set of characters that are to be removed would not be very useful. It's much better to let the PB programmers decide, what the function should remove in a given context. Look at these "TrimAny" functions to see what I mean.

Little John wrote: append(k()) = "New List Element"
This is not generally possible, since in PB there are not only lists of simple variables such as strings, integers etc., but also lists of structures, lists of arrays, lists of lists etc.

I don't understand, why would the element type affect the shorthand syntax?

Little John wrote: No, please! Having both a Trim() function and a Trimm() function would be very ugly, it would probably confuse newcomers, and cause unnecessary problems for dyslexic people.

Such a function with a fixed set of characters that are to be removed would not be very useful. It's much better to let the PB programmers decide, what the function should remove in a given context. Look at these "TrimAny" functions to see what I mean.

I read this. But I am unconvinced.

Having TRIM() do only spaces is a very old BASIC convention. As in Fortran77-vintage BASIC.
It's OK for backwards compatibility. 40 years later, with multiple character encodings, the
question of what constitutes whitespace is more complicated and open to debate.
BUT whitespace always includes TAB, LF, CR and Space.
And sometimes ALL non-printing or control characters...
(but otherwise, it's the same function as trim().)

Maybe a compromise?
They could enhance the current function and add an option or something to trim().
Perhaps like:
v$ = trim(string$[,option])
where you can enter #PB_WHITESPACE, #PB_NONPRINTING or perhaps even a charlist "[()]}{"
passed to the command in a string. That would be quite versatile.

Or take your advice and not call it trim?
They could call it STRIP() and just strip whitespace (see above) instead.
That would solve the beginner issue AND the legacy code issue.
This is a very useful function - and if it could be done in the compiler as a native command it
would be very very popular.

When purebasic has trim(,option)(or strip() ), explode(), implode() and a couple more php-like functions,
an increasing number of PHP developers will start arriving in order to create desktop applications.
I could be wrong, but I don't think so.

So maybe my request is for a new command called STRIP(). You make an excellent point!

Little John wrote:

Bo Marchais wrote:Add an element to the K list should not require two statements:
AddElement(K())
K() = "New List element"

Should be allowed by:

append(k()) = "New List Element"

This is not generally possible, since in PB there are not only lists of simple variables such as strings, integers etc., but also lists of structures, lists of arrays, lists of lists etc.

Bo Marchais wrote:I don't understand, why would the element type affect the shorthand syntax?

Look at the following short example. Here it's not possible to create a new list element and assign all values with only one command:

Ok, I see now that there are cases which would require additional syntax modifications.
I suppose I can handle it in a macro. It's only because I generally avoid strucs when possible.
Thank you!