[Q] Concat strings of "arbitrary" length?

[y***@z505.com]

: > Another way is to drop the operator idea all together ( it is
: > no fun away ).
: > Init( s );
: > Concat( s, mary );
: > Concat( s, sally );
: > Concat( s, sue );
: But, then you could do it in assembler! You don't mean this
: seriously, do you?
Yup. I am serious. I don't think concatenating strings deserves
an operator. I am not at all bothered by a few or even a dozen
lines of procedure calls to build a single string or text and
this type of problem does not occur often enough to warrant
having a language specific operator.

Back in 1995 this string debate was going on, and they still haven't solved it 20 years later...

Oh wow what an old post I am replying to... It's just extremely interesting that this string problem existed back in 1995, and in 2015 the same problem.

"I am not at all bothered by a few or even a dozen lines of procedure calls"

Haha... this kid must be joking...

SomeProc(Concat('test', other),Concat('somestring', other), Concat(a,b));

Compared to:

SomeProc('test'+other, 'somestring'+other, a+b);

You shortened it from Concatenate to Concat, so why not take it one step further and turn Concat into "+"...

You use "VAR" instead of "VARIABLE"... isn't "VARIABLE" more readable so why not use it instead of VAR? Hypocrisy of the oberon language? Against C terseness but then goes ahead and shortens PLUS to + and VARIABLE to VAR, and CONCATENATE to CONCAT (why not CAT?)

"PROCEDURE" should be "PROC"?

POINTER TO ARRAY OF CHAR is such a silly verbose long form.. compared to:

STRING

When I look at oberon code and see ARRAY 1024 OF CHAR and POINTER TO ARRAY OF CHAR I really wonder if this is becoming COBOL or something worse.

Why not just use PLUS instead of "+" and EQUAL instead of "="

1 PLUS 1 PLUS 1 EQUALS 3

Why use numbers...

ONE PLUS ONE PLUS ONE EQUALS THREE

Isn't that more readable?

CONST should be CONSTANT ... If concerned about readability. So why VAR and CONST shortforms? but not PROC for Procedure? strange

Shortforms like a+b+"test" make code less buggy and easier to read since with Concat()Concat()Concat(Concat()) you end up with a Lisp like brackets everywhere... Nail clippings mixed in with your oat meal.

Math came up with shortforms for a reason. To not become cobol. But even worse, cobol would probably be against POINTER TO SOME THING whereas oberon encourages it all over the place. Isn't there a mathematical symbol for pointer ^

Regards,
Z505 Software
Cobol Sucks
Let's not turn languages into verbose ENGLISH Longforms

[August Karlstrom]

Post by y***@z505.com
When I look at oberon code and see ARRAY 1024 OF CHAR and POINTER TO
ARRAY OF CHAR I really wonder if this is becoming COBOL or something
worse.

In Oberon-07/15 you can only declare pointers to records, so the keyword
POINTER typically only occurs in type declarations where I don't think
the "verbose" syntax affects readability in a negative way.

Post by y***@z505.com
If concerned about readability. So why VAR and CONST shortforms? but
not PROC for Procedure? strange

I have been thinking about this too. Does anyone know why the
nine-letter keyword PROCEDURE is not abbreviated when the eight-letter
word CONSTANT is abbreviated to
CONST? It all seems a bit random to me when it comes to which keywords
are abbreviated and which ones are not. Is it all about the ALGOL heritage?



-- August

[August Karlstrom]

Post by August Karlstrom

Post by y***@z505.com
When I look at oberon code and see ARRAY 1024 OF CHAR and POINTER TO
ARRAY OF CHAR I really wonder if this is becoming COBOL or something
worse.

In Oberon-07/15 you can only declare pointers to records, so the keyword
POINTER typically only occurs in type declarations where I don't think
the "verbose" syntax affects readability in a negative way.

Post by y***@z505.com
If concerned about readability. So why VAR and CONST shortforms? but
not PROC for Procedure? strange

I have been thinking about this too. Does anyone know why the
nine-letter keyword PROCEDURE is not abbreviated when the eight-letter
word CONSTANT is abbreviated to
CONST? It all seems a bit random to me when it comes to which keywords
are abbreviated and which ones are not. Is it all about the ALGOL heritage?

In Oberon-07/15, of the 33 keywords only five are abbreviated:

CONST
DIV
ELSIF
MOD
VAR

The reason for keeping the operators DIV and MOD short is obvious. This
leaves us with CONST, ELSIF and VAR. The reason "else if" is spelled
ELSIF rather than ELSEIF is the idea that the difference between
keywords should be more than just a blank space.

When it comes to VAR my guess is that Wirth thought that VARIABLE would
make procedure parameter lists needlessly long and draw too much
attention. Probably CONSTANT was then abbreviated to CONST to make CONST
and VAR feel more coherent.


-- August

[Unknown]

Post by August Karlstrom

Post by y***@z505.com
When I look at oberon code and see ARRAY 1024 OF CHAR and POINTER TO
ARRAY OF CHAR I really wonder if this is becoming COBOL or something
worse.

In Oberon-07/15 you can only declare pointers to records, so the
keyword POINTER typically only occurs in type declarations where I
don't think the "verbose" syntax affects readability in a negative way.

Post by y***@z505.com
If concerned about readability. So why VAR and CONST shortforms? but
not PROC for Procedure? strange

I have been thinking about this too. Does anyone know why the
nine-letter keyword PROCEDURE is not abbreviated when the eight-letter
word CONSTANT is abbreviated to
CONST? It all seems a bit random to me when it comes to which keywords

.....
Oh please, it's subjective.
It's art, not science.
How do you want to abreviate "BEGIN" & "END"?
Curly-brackets seemed a good choice; but you need them for math notation.

BTW the correct answer to:
[Q] Concat strings of "arbitrary" length?
is EXACTLY: "Text files".

[y***@z505.com]

Post by Unknown
Oh please, it's subjective.
It's art, not science.
How do you want to abreviate "BEGIN" & "END"?
Curly-brackets seemed a good choice; but you need them for math notation.

This is all discussed at the Qomp home page, a research vapor language that doesn't exist yet due to the first copy of Qomp being corrupted on my hard drive after a few weeks worth of effort working on it.

Begin and end are shortened to B and E (lower case though). The disadvantage of this is that you can no longer use a+b+c or a*b*c as variables for math. However in case sensitive language you can use B and E as variables as they are upper case, while the reserved words are "b" and "e". Or instead of a*b*c people would have to resort to using other letters like x,y,z etc.

Then you have { } left to use for relational sets or further expansion later. A dream language of mine is a practical implementation of Date and Darwen's TutorialD (similar to Pascal/R or relational pascal, very infamous and not well known). Another dream of mine is a Relational GoLang or relational oberon, or relational Qomp.

DuroDBMS is a nice project, but fading away into obscurity as no one uses it.

[y***@z505.com]

Post by August Karlstrom
When it comes to VAR my guess is that Wirth thought that VARIABLE would
make procedure parameter lists needlessly long and draw too much
attention. Probably CONSTANT was then abbreviated to CONST to make CONST
and VAR feel more coherent.
-- August

Wow, so now you understand the advantages of turning PROCEDURE into PROC or FUNC. Wait, GoLang already did that.

As for parameter lists being too long. Laughs! That's why ARRAY OF CHAR is hideous in a parameter list, instead of STRING or string.

[y***@z505.com]

Post by August Karlstrom
The reason "else if" is spelled
ELSIF rather than ELSEIF is the idea that the difference between
keywords should be more than just a blank space.

I have no problem with ELSIF

[Unknown]

Post by y***@z505.com

rudolf mittelmann (rm at cast.uni-linz.ac.at) wrote: : whitney at

......

Post by y***@z505.com
"PROCEDURE" should be "PROC"?
STRING
When I look at oberon code and see ARRAY 1024 OF CHAR and POINTER TO
ARRAY OF CHAR I really wonder if this is becoming COBOL or something
worse.
Let's not turn languages into verbose ENGLISH Longforms

You are solving the wrong problem.
For football-players or pianists who play by over-learned reflex
forth or APL terseness is best.
But for designers & thinkers, who don't want to be manual key-punchers,
selecting the ad-hoc syntax off a menu is most productive.

Of course Micro$loth's long-file-name-descriptions are easier to
understand than *nix's Abvtns; and in that sense much better;
except that line-overflow makes them impossible to manage, for me.
IMO this problem doesn't apply to COBOL / Oberon.

[Richard]

Post by Unknown
Of course Micro$loth's long-file-name-descriptions are easier to
understand than *nix's Abvtns; and in that sense much better; except
that line-overflow makes them impossible to manage, for me. IMO this
problem doesn't apply to COBOL / Oberon.

It seems that many programmers still mentally remain in the age of punch
cards and text terminals--using fixed-width fonts and arbitrary
(historical) line-length limitations.

IMO in our time of proportional fonts and high-resolution 16:9 screens
there is no justification for abbreviations anymore.

Richard

[Pascal J. Bourguignon]

Post by Richard

Post by Unknown
Of course Micro$loth's long-file-name-descriptions are easier to
understand than *nix's Abvtns; and in that sense much better; except
that line-overflow makes them impossible to manage, for me. IMO this
problem doesn't apply to COBOL / Oberon.

It seems that many programmers still mentally remain in the age of punch
cards and text terminals--using fixed-width fonts and arbitrary
(historical) line-length limitations.
IMO in our time of proportional fonts and high-resolution 16:9 screens
there is no justification for abbreviations anymore.

Agreed on abbreviation (after all, now I'm a lisp programmer, we don't
abbreviate in lisp), and on the arbitary line-length limits.

On the other hand, and even though I've had exposure to proportional
fonts as early as in 1985 with LightSpeed Pascal (which I have to admit,
was perfectly usable with a proportional font, but that's pascal), with
all the other programming languages I find it much easier to read when
using a non-proportional font.

Even in lisp, which has properties similar to pascal with respect to
indentation and text lines, there are still often occurences where you
want to align columns in the code.

Compare reading:

(setf width (point-x (aref current i))
height (point-y (aref current j))
profondeur (point-z (aref current k)))

with:

(setf width (point-x (aref current i))
height (point-y (aref current j))
profondeur (point-z (aref current k)))

The later, with a non-proportional font aligns columns containing the
same thing, and therefore allows you to see at once, what changes from
one line to another, and what's the same. Without column alignment, or
even worse, with proportional font, it becomes much harder to see what
changes from one line to another. It's ok when you're reading English,
but not when you're reading structured code.

Of course, in maths you would have a notation such as:

( width ) (x) (i)
(setf ( height ) (point-(y) (aref current (j)))
( profondeur ) (z) (k)

which would allow you to use proportional fonts. But notice how to make
sense this mathematical notation uses alignment and columns, that must
be respected when rendering the formula.

There are also more esoteric cases where you definitely want to use a
non-proportional font to make sense of the code, but I won't enter into
those details now. (For extreme cases, just have a look at some entries
of the obfuscated C contest).

[Richard]

Post by Pascal J. Bourguignon
On the other hand, and even though I've had exposure to proportional
fonts as early as in 1985 with LightSpeed Pascal (which I have to admit,

Oh, the memories! And to think that at this time the MS-DOS users were
proud of Turbo Pascal... :)

Post by Pascal J. Bourguignon
(setf width (point-x (aref current i))
height (point-y (aref current j))
profondeur (point-z (aref current k)))
(setf width (point-x (aref current i))
height (point-y (aref current j))
profondeur (point-z (aref current k)))

Actually, the second version is a lot less readable than the first one
for me, because I am using a proportional font in my newsreader too.

And just as you can't rely on people to read your articles with a
fixed-width font, you can't rely on everybody to read your source code
with a fixed-width font.

I think, the best solution for this dilemma would be that everybody use
elasitic tabstops:

http://nickgravgaard.com/elastic-tabstops/

But I am not holding my breath. :)

Richard

[n***@gmail.com]

Post by Pascal J. Bourguignon

Post by Richard

Post by Unknown
Of course Micro$loth's long-file-name-descriptions are easier to
understand than *nix's Abvtns; and in that sense much better; except
that line-overflow makes them impossible to manage, for me. IMO this
problem doesn't apply to COBOL / Oberon.

It seems that many programmers still mentally remain in the age of punch
cards and text terminals--using fixed-width fonts and arbitrary
(historical) line-length limitations.
IMO in our time of proportional fonts and high-resolution 16:9 screens
there is no justification for abbreviations anymore.

Let me do a real-live test *HERE*.
Let's find where those forth-files are:
System.Execute F1 orth ==
omitting any mention of it here, henceforth.)
-is Wider search for icons (worth the extra time)
EditTools.OpenUnix /mnt/DebDVD1bak/p11v/leoActiveMenu/DelRepeats/ObnAlgorth
/mnt/hdc11/OLPC/Forth/Color4th/TstLatex/Functor.tex
...
Let's assume I want to move:
/mnt/DebDVD1bak/p11v/leoActiveMenu/DelRepeats/ObnAlgorth
to the directory of:
/mnt/hdc11/OLPC/Forth/Color4th/TstLatex/Functor.tex
which has a 6-deep-path.

If instead of using abreviations like OLPC, p11v; I used
Micro-Soft-proper-long-names,
then `mv SrcFile DestDir` command would be 200 chars long.

Who was it that opened to topic of unlimited string-lengths?

Post by Pascal J. Bourguignon
(setf width (point-x (aref current i))
height (point-y (aref current j))
profondeur (point-z (aref current k)))
(setf width (point-x (aref current i))
height (point-y (aref current j))
profondeur (point-z (aref current k)))

They look identical *HERE* !!
Do you expect NNTP to send *your* font?

LEO uses proportional font by default.
For sections that need to allign, you just 'wipe & dab'
the relevant section, to get any font/color/size.

You haven't lived till you've used ETHO [from the 90s !].
If you want to see real garbage: a win7 that I had in 2013.

BTW for linux users wily [copied from ETHO by the designers
of unix and then plan9] is much easier, smaller than emacs.

Unless you WANT to be a pianist.

[y***@z505.com]

Post by n***@gmail.com
Unless you WANT to be a pianist.

That's the difference between real programmers and quiche eaters. Real programmers like myself, have played keyboard, drums, and such instruments - and we also enjoy math. Cobol fools and lisp hypocrites, tend to read shakespeare and other garbage, while programmers are more interested in Musical Notation, and poetry. Say goodbye to Shakespeare and COBOL and other verbose drivel. It's not worth your time. Stick with poems and musical notations, thanks very much. And math. Learn it some day.

ONE PLUS ONE DOES NOT EQUAL TWO

However,

1 + 1 = 2

That is the correct form.

[y***@z505.com]

Post by Pascal J. Bourguignon
Agreed on abbreviation (after all, now I'm a lisp programmer, we don't
abbreviate in lisp), and on the arbitary line-length limits.

Well you certainly aren't a very intelligent lisp programmer, because if you had done any research on Lisp you'd see that Paul Graham's lisp is abbreviated to the max. Even regular old lisp, uses what: CAR, CDR?

What's CDR, CD ROM DRIVE?

I think so.

Also, ( ) is an abbreviation for BEGIN and END.

Maybe try, education.

[y***@z505.com]

Post by Richard
IMO in our time of proportional fonts and high-resolution 16:9 screens
there is no justification for abbreviations anymore.
Richard

This is funny. Because Math has been around long before you ever existed and has always used abbreviations and rightly so.

Some of you might want to actually learn math, rather than say, drivel such as shakespeare. Try math some time.

1 + 1 = 2 is an abbreviation, and a nice one, rightly so.

Math? limited by the width of your paper.... I guess they should have increased the size of the paper and written verbose COBOL style back in the day, hey brother?

ONE PLUS ONE EQUALS TWO

Math for retards!

[y***@z505.com]

Post by Unknown

Post by y***@z505.com
When I look at oberon code and see ARRAY 1024 OF CHAR and POINTER TO
ARRAY OF CHAR I really wonder if this is becoming COBOL or something
worse.
Let's not turn languages into verbose ENGLISH Longforms

You are solving the wrong problem.
For football-players or pianists who play by over-learned reflex
forth or APL terseness is best.
But for designers & thinkers, who don't want to be manual key-punchers,
selecting the ad-hoc syntax off a menu is most productive.

You mean mathematicians , i.e. thinkers, who do stupid stuff like this:

one PLUS one EQUALS two

No, actually they are smarter.

1 + 1 = 2

Thanks math! You rock. Cobol blows.

[Unknown]

Post by y***@z505.com

Post by Unknown

Post by y***@z505.com
When I look at oberon code and see ARRAY 1024 OF CHAR and POINTER TO
ARRAY OF CHAR I really wonder if this is becoming COBOL or something
worse.
Let's not turn languages into verbose ENGLISH Longforms

You are solving the wrong problem.
For football-players or pianists who play by over-learned reflex forth
or APL terseness is best.
But for designers & thinkers, who don't want to be manual key-punchers,
selecting the ad-hoc syntax off a menu is most productive.

one PLUS one EQUALS two
No, actually they are smarter.
1 + 1 = 2

Your example confirms exactly my point:
we are familiar with <number1> "+" <number2>,
like a pianist is familiar with music notation.

If you only compute in the area where you are familiar/fluent,
then you don't even want to need to refer to the screen, and
probably work like a pianist. If you work on the boundries of
your unknown, you want to see <your environment> and be able
to recognise much more than you can accurately remember, to be
able to visually select/probe <routes>.

But I think we are seeing different problems?
You want oberon to do:
"Str1 + Str2" := "<indeterminate String1>" + "<indeterminate String2>";
You can build amodule to do that. I'd use it. Thanks.

Post by y***@z505.com
Thanks math! You rock. Cobol blows.

-----------
Let's see if this newsPoster works?
Perhaps <eternalSeptember> emailed an anouncement to my previous adr
which I need to answer?

[y***@z505.com]

Taylor Hutt, sometimes I even have good ideas
Beano now comes in a pill (so I've been told by a user)

What ever happened to Taylor Hutt. At one time I read that he moved over to using C and C++ because it was satisfactory for the jobs he was doing. This post back in 1995 when he was using oberon is long gone...

Taylor Hutt inspired me to write articles about the problems with error codes vs exceptions and I have quoted him a few times... Golang implemented something very much to my dream of proper error handling.

Is Taylor Hutt ever going to use oberon again? Has he tried golang or will he ever come back to Oberon?

[c***@gmail.com]

Post by y***@z505.com
What ever happened to Taylor Hutt.

He is working on the kernel team of Chromium OS at Google.

[y***@z505.com]

Regarding the oberon Strings debate:

Found an oberon programmer who "gets it".. i.e. spinach

https://github.com/vladfolts/oberonjs/wiki/Eberon-Strings

Have to research this. I'm posting it to the list to make it more known
that there are people who know of the string problem and aren't denying
it.

With all these forks of oberon, it's the same problem as standard pascal.
You have about 200 different versions of pascal floating around, because
standard pascal was castrated and circumscribed in its standard form. So
people extend it which fragments the community into hundreds of forks.

Cross posting this, also posted it to Oberon mailing list.

Enjoy your spinach.