On Aug 28, 11:58 pm, ArarghMail708NOS...@[EMAIL PROTECTED]
wrote:
> On Tue, 28 Aug 2007 22:41:08 -0700, Derek <derek...@[EMAIL PROTECTED]
> wrote:
> >On Aug 26, 3:08 am, ArarghMail708NOS...@[EMAIL PROTECTED]
wrote:
> >> On Sun, 26 Aug 2007 03:26:03 -0400, "Tom Lake" <tl...@[EMAIL PROTECTED]
>
> >> wrote:
>
> >> MAT LET gets interesting. What do you do if:
> >> dim a!(9), b#(9)
> >> mat a!=b#
> >> That's going to have to cause an error, because changing the element
> >> size is pretty much of a no no.
>
> >> Also, if the destination array is static, then the source array must
> >> be the exact same size (although smaller might work)
>
> >I don't think that this was a problem with Dartmouth BASIC because it
> >didn't have the plethora of numeric types that are offered by MS
> >BASIC. You basically just had double precision floating point and that
> >was it. Even so it doesn't make things impossible -- just trickier.
>
> DIM A@[EMAIL PROTECTED]
(9), B#(9)
>
> Well, the real problem is going to be determining if A & B are
> different at runtime. Both have element size of 8 and a element count
> of 10. At compile time, it is no problem.
>
> The big problem would occur with separately compiled routines, where
> you lie about the parameters.
Here's where interpreters have an advantage in the
flexibility of the language. You could potentially
allow program to redimension arrays or change the
variable type contained during a program, if all copy
operations were selected at runtime. JavaScript and
Perl allow this. But some implementations of Basic
also allow a runtime redimensioning.
I've been wondering whether a Basic should allow its
MAT commands:
DIM a(n),b$(n),c(n)
....
MAT b$ = a
MAT c = b$
to do a whole vector of str$() and val() conversions
automatically.
IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M
|
