OpenEuphoria

Re: Stupid Newbie-sounding question.

• Posted by "Patrick Barnes" <mistertrik at hotmail.com> Jun 01, 2004
• 561 views

>From: irv mullins <guest at RapidEuphoria.com>
>Subject: Re: Stupid Newbie-sounding question.
> > That's my take on the situation. I can't see any problems with this 
>right
> > now, and Rob, I'd like to hear your thoughts on this.
>
>The real problem is that it isn't all that useful because it only checks on
>assignment.

Actually, I guess it's a thread hijack. I wasn't trying to address the 
string debate in terms of printing... Like I said in the trace thread, I 
don't think it matters that much unless you're tracing.

>Why does Euphoria have different functions for outputting variables,
>depending on their type? If you choose the wrong one, you get a crash.
>Other languages handle this transparently.
>
>For example, if Euphoria actually used its type system, you could
>do this:
>
>a =  1
>b = 3.1415
>c = "Foo bar"
>d = {1,4,7,234}
>
>print(a,b,c,d)

Well, the printf function works properly, for what that's worth.

>All 4 should print the way you expect them to, IOW, 'c' doesn't look
>like a series of strange numbers, and 'd' doesn't try to print as
>a 4-letter word.

Okay, that is fair enough.... This could actually address the types a bit 
though (not var_arg_lists, that is another thing altogether)

Consider: If a variable is "cast" to a generic type:

type char( integer c)
     return (c <= 0) and (c >= 255) --Ignoring unicode matters, this is just 
an example.
end type
type string ( sequence of char s)
     return 1
end type

procedure print_variable( object x )
    if atom(x) then       --Print a number
        print(1,x)
   else if string(x) then --Print a string
        puts(1, x)
   else                       --Print a generic sequence
        print(1,x)
   end if
end procedure

Now, in the implementation of this, there would be some kind of tag on the 
variable (inside the interpreter) that would remain attached to the variable 
even if it was cast to a generic type (object, in this case). After all, the 
data hasn't changed. If any assignment is made to the variable, then there 
must be some checks as to whether the variable should retain its tag. So, no 
matter how complex the type, a type-check on a variable that has been cast 
to generic but not modified is trivial.

>I believe languages such as Lua and Python handle this without any
>problem, and they are untyped languages. Surely a language which forces
>you to declare specific types for a variable should actually make use
>of that information, shouldn't it?

After typing out the example above, I see what you mean... in that with 
default behaviour the above function would mistakenly take a 1-dimensional 
sequence of integers below 255 for a string, and print it. This *could* be 
fixed by creating a new built-in function that would check the tag on the 
variable, and return a 1 if the variable has that tag.

procedure print_variable( object x )
    if atom(x) then       --Print a number
        print(1,x)
   else if variable_tag(x, "string") then --Print a string
        puts(1, x)
   else                       --Print a generic sequence
        print(1,x)
   end if
end procedure

So, the variable_tag function would only check if the object x is already 
validated as a string, and would not attempt to cast from any other type.

>Why does Euphoria have any types at all, if it isn't going to use them to
>make the programmers job easier, and to reduce errors?

Because Rob is only one man, and has the same blinkers (think racehorses) as 
all of us do. Obviously no one person has a perfect paradigm, but by working 
together we can improve things.

MrTrick