Re: [Scheme-reports] fresh empty strings

[Ray Dillinger <bear@x>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/24/2012 07:41 PM, Per Bothner wrote:

> Of course - but if you don't have an implementation in mind when you 
> design the API then you're just blowing hot air.  

I agree.  In fact, I think that the designers of the API
should consider *several* possible implementations, not
just one.


> Also any notes
> in the specification about performance expectations would be based on
> possible implementations that the API writer(s) have considered.

Do requirements about performance expectations belong in the
language standard?

I can think of compelling reasons to use trees to represent
(very large) strings, for example; when n is very large,
O(1) rather than O(n) copy and O(log n) rather than O(n)
length-changing mutations or copy-with-modification are
very compelling, as are segment-interning and its accompanying
shared storage space for multiple huge strings with small
differences.  But we don't want to put that into the
standard, because then nobody could use a very simple
array implementation for better performance on short
strings.

I can also think of compelling reasons to use an array
implementation for (short) strings, because, for example,
O(1) index lookup time or point-mutation time can also
be very compelling under some different circumstances.
But we don't want to put those things into the standard
because then nobody could make huge strings with decent
performance characteristics using trees.

Finally, most implementations are going to be on
platforms that already have one of several diverse but
reasonably performant native string implementations, and
interoperability with other code on the same platform
will be greatly facilitated by using the same internal
string representation.  Requiring performance characteristics
that are unmet by, say, the Java string class and the C++
null-terminated UTF string (which have mutually exclusive
performance characteristics in some cases) may be
putting an unreasonable burden on implementors and
causing interoperability problems on their platforms
by requiring them to use a different internal string
representation than everything else on the platform.

So, I think we need to have the standard just talk about
the semantics of an API, and then trust implementors to
have good taste in implementing it in a way that's
appropriate for their platform, their users, and their
targeted applications and domains.

				Bear
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPIFAoAAoJEAOzWkqOibfNjhEIALmcnQj14xoxxP/4TOM/NbIS
+0/D13yHO4RcB/q6ZVFaGlpfBHHeeE92ZWA91ChMO76rzQiNaP/vwQQVDp5cD/Za
92gK+MRlFI+tKMdkVjaJFDksCPcDE2JjESosgKJHHwW4YCIs3xb0jH6L9eG06c5h
bbTlvu5cZihswIIVjsVTtVGZSoECeR0YwwMbNeDRek2CaPx+uXsmy0O2COE4xkrp
OAiIOZsNMoYUcUrT+pPaOSNQTGnQSN54KVk9CuSe4T2h4AwXIADp1SrJnfRrU42j
favssBtj586mCvrqsG0ofvAmd3wSjGx5Uz8sUCteSVRN9JrzLQC8os+lUKJ6MIA=
=scj8
-----END PGP SIGNATURE-----

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports