Re: Euphoria vs The Other Guys --- and RTFM

new topic     » goto parent     » topic index » view thread      » older message » newer message
SDPringle said...

... Strings are easily implemented as a UDT.

Not quite. UDT have some restrictions. They are only used during assignments or explicit if UDT(x) tests. We can't tailor other operations to deal with UDTs, nor can we arbitrarily have existing library functions know what to do with a UDT when they encounter one. That, of course, also applies to built in types too.

SDPringle said...

If added as a builtin type, you would only need to modify the parser part.

Actually, it turns out to be a lot more complicated than that. A new built-in type has semantic implications that would undoubtedly affect nearly every aspect of the existing language operations.

SDPringle said...

... working with a string is the same as working with a sequence of integers, or a sequence of anythings.

Again, only if you are talking about sequence operations, but even then we would need to add some extra semantics to some operations. For example, adding an atom to a String type should do what, exactly? Issue a runtime error, maybe? Then there's the whole complication of how to output String data. If the string is going to a console device, we would probably need to convert it to UTF8. But what about out to a file? Or output to a windowed applications - UTF16 or ASCII? Now consider functions like upper() etc, these need special handling for unicode strings.


Forked into: Integrating string types into EUPHORIA handling

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu