Message: 2
Date: Sun, 27 Nov 2005 11:15:51 +0100
From: Raphael Collet <[EMAIL PROTECTED]>
Subject: Re: Oz Newbie: CRLF conversion of redirected stdin
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Raph,

> > Anthony Borla wrote:
> > I'm using the following approach to read in a redirected
> > text file from stdin:
> >
> >     ...{New TextFile init(name:stdin)}...
> >
> >     ...
> >     fun {LoadData FILE DATATBL}
> >         case {FILE getS($)} of false then
> >             DATATBL
> >         elseof DATUM then
> >             {LoadData FILE {Append DATATBL
> >                         [{String.toFloat DATUM}]}}
> >         end
> >     end
> >     ...
>
> Just a side note: your function builds a list of size n in O(n^2)
> complexity!  The following does the same in O(n):
>

Thanks for pointing that out. Admittedly I wasn't comfortable using 'Append'
here, but at this stage, I'm just 'doodling', trying to get a feel for the
various Oz facilities.

Besides, I *was* careful to ensure that a tail recursive call was made, so
at least the optimiser kicks in [AFAIK], and ensures the stack doesn't grow
[small consolation, though, when 'Append' is creating so much garbage ;) !].

>
>    fun {LoadData FILE}
>       case {FILE getS($)}
>       of false then nil
>       [] DATUM then {String.toFloat DATUM}|{LoadData FILE}
>       end
>    end
>

Thank you for the pointer :) ! My knowledge of Oz pattern matching [and its
idioms, in general] is, at this stage, quite minimal.

I actually ordered the CTM book yesterday but was told not to expect
delivery for a few weeks, so I'll be making do with the online
documentation, and otherwise stumbling along through trial and error, until
then.

>
> Regarding your problem, I don't remember to have read
> something similar in the past.  Have you checked the mailing
> list archives?  BTW, you can remove spurious CR in the line
> you read with String.tokens.
>

I appreciate the pointers. However I don't see why there should be a CR
character included in the returned string. On Win32 platforms CRLF is the
line terminator, and, I would expect it [that is, both characters comprising
the the line terminator] to be removed as part of the reading step. It
really doesn't strike me as being 'correct' behaviour to leave it in.

Cheers,

Anthony Borla


_________________________________________________________________________________
mozart-users mailing list                               
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users

Reply via email to