Procedure returning string of arbitrary length

[August Karlstrom]

In Oberon-07, how would you design the interface of a procedure which
retrieves the value of an HTTP GET parameter?


August

[August Karlstrom]

Post by August Karlstrom
In Oberon-07, how would you design the interface of a procedure which
retrieves the value of an HTTP GET parameter?

The problem here is that in general the caller of the procedure does not
know the length of the string value.


August

[Chris Burrows]

Post by August Karlstrom

Post by August Karlstrom
In Oberon-07, how would you design the interface of a procedure which
retrieves the value of an HTTP GET parameter?

The problem here is that in general the caller of the procedure does not
know the length of the string value.

In general if you don't know the length of the string in advance the
parameter to the procedure would be ARRAY OF CHAR and the caller of the
procedure would need to pass an array with a length that is at least as long
as the maximum length expected including the terminating null character.

Chris.

[August Karlstrom]

Post by Chris Burrows
In general if you don't know the length of the string in advance the
parameter to the procedure would be ARRAY OF CHAR and the caller of the
procedure would need to pass an array with a length that is at least as long
as the maximum length expected including the terminating null character.

Yes, this is a standard approach. The problem is when the result could
be of any length. In C this would not be a problem since the function
would typically return a pointer to a string (which has its own
problems) whereas in Oberon the string has to be copied into the
character array that the caller provides.

I wonder why Wirth left out dynamically allocated arrays in Oberon-07. I
know that the compiler he implemented had a restricted form of dynamic
arrays as an extension but that compiler still do not allow them in
records. I find that I need dynamic arrays quite frequently but maybe
it's a kind of luxury that is not essential in a minimalist language.


August

[Chris Burrows]

Yes, this is a standard approach. The problem is when the result could be
of any length. In C this would not be a problem since the function would
typically return a pointer to a string (which has its own problems)

In C you still have to allocate memory (e.g. using malloc) to store the
string. As you don't know the length then again you would have to allocate
the maximum possible size before copying the characters.

I wonder why Wirth left out dynamically allocated arrays in Oberon-07. I
know that the compiler he implemented had a restricted form of dynamic
arrays as an extension but that compiler still do not allow them in
records. I find that I need dynamic arrays quite frequently but maybe it's
a kind of luxury that is not essential in a minimalist language.

If you consider the possible list of requirements then you may not need to
wonder. What sort of dynamic arrays: Multidimensional? Jagged? Of any data
type? Automatically extensible? Do you need a garbage collector? etc. etc.

If you need these sorts of facilities then Oberon-2 or Component Pascal is
probably a better choice of language for the tasks that you are trying to
achieve - you don't have to restrict yourself to just one language.
Oberon-07 is much better suited to systems with limited resources that would
not be capable of hosting an Oberon-2 or Component Pascal environment,

Regards,
Chris

Astrobe v3.4: ARM Oberon-07 Development System
http://www.astrobe.com

[August Karlstrom]

Post by Chris Burrows
If you consider the possible list of requirements then you may not need to
wonder. What sort of dynamic arrays: Multidimensional? Jagged? Of any data
type? Automatically extensible? Do you need a garbage collector? etc. etc.

Yes to all except automatic extensibility - like dynamic arrays in Java.
I just reread a post from 2008 in this group by thutt which I had
forgotten about where he describes the effort required to implement
dynamic arrays and I realize that it is substantial.

Post by Chris Burrows
If you need these sorts of facilities then Oberon-2 or Component Pascal is
probably a better choice of language for the tasks that you are trying to
achieve - you don't have to restrict yourself to just one language.
Oberon-07 is much better suited to systems with limited resources that would
not be capable of hosting an Oberon-2 or Component Pascal environment,

Possibly, but still Oberon-07 is a general purpose programming language
as the manual says. I also find it to be the most elegant Oberon
version. This is from the paper Differences between Oberon-07 and Oberon:

"Most changes in the language might easily be called features of a
dialect. However, there are a few that merit a stronger distinction,
because they should be considered as permanent, and as corrections of
unsatisfactory properties of the original Oberon. These are the
elimination of the loop statement, function result specification, array
assignments, constant parameters, and read-only import of variables."

www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.pdf


August