Re: Eu improvements (part 4)
Robert Craig wrote:
>
> Karl Bochert wrote:
> > -- Please pay no attention to how SS is implemented --
> > That is the problem of the implementor
> > An SS is a structure whose elements are accessed by name. only.
>
> For me, structures are just fine, actually desirable,
> when their effect on the simplicity of the language
> and libraries is ignored, and when implementation issues are ignored.
> Please read what I said back in 2001...
>
> <a
> href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=6&toMonth=8&toYear=6&postedBy=rds&keywords=structures+bloat">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=6&toMonth=8&toYear=6&postedBy=rds&keywords=structures+bloat</a>
>
> Maybe Matt or yourself, since one or both of you seem to have
> implemented structures, can explain where I'm wrong about either the
> implementation costs, or the loss of language and library simplicity.
>
> I don't need to be sold on the value of structures as an isolated
> language design concept. I need persuading in these other two areas.
Rob, I fully agree with you about the effect upon the backend if a new
primitive datatype were added. Which is why my version of structures
is just an extension of the existing types.
I'm not proposing anything that could be automatically handed off to a
C routine, although I've thought about how to create some classes to
help with this process, so that a simple method call could update the
memory structure or read from it, so C-structure help comes from a
library.
As I mentioned in another post, these are just sequences with some extra
tools.
Matt
|
Not Categorized, Please Help
|
|
