Procedure returning string of arbitrary length

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


August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra

On 2011-08-28 17:24, August Karlstrom wrote:
> 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

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra

"August Karlstrom" <fusionfile@gmail.com> wrote in message
news:j3drmi$m87$1@dont-email.me...
> On 2011-08-28 17:24, August Karlstrom wrote:
>> 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.

On 2011-08-29 10:27, Chris Burrows wrote:
> 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

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra

"August Karlstrom" <fusionfile@gmail.com> wrote in message
news:j3lua5$5pp$1@dont-email.me...
>
> 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

On 2011-09-01 14:25, Chris Burrows wrote:
> 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.

> 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."

http://www.inf.ethz.ch/personal/wirt...n/Oberon07.pdf


August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra