Subj : Re: Any great mystery over fixed-point arithmetic? To : comp.lang.misc,comp.programming From : cr88192 Date : Wed Jun 29 2005 10:16 am "James Harris" wrote in message news:42c063a0$0$2594$da0feed9@news.zen.co.uk... > > "cr88192" wrote in message > news:4c934$42be841e$ca8014d9$10108@saipan.com... > >> [been drinking] > [cheers!] > > >>> One thing to add. There may be a need for data items which are not in >>> themselves structures to still be dealt with as one. Perhaps they make a >>> context or are related in some way. The syntax above would require a >>> horrendous number of parameters. For this reason I am thinking of the >>> parameters as being packaged up into a group. They only that package >>> gets specified in the function call and cuts down the number of >>> parameters that need to go with each call. The big advantage of this is >>> that it removes the need for global variable and, I hope, it keeps the >>> interface to the operation clear and specified in the operation itself. >>> >>> Does that address the API issues (at least when combined with default >>> parameters!)? >>> >> sorry, I don't follow. > > I guess it made more sense when being written! Sorry about that. I was > just thinking of grouping related data under a common name - effectively > naming a tuple - so that the name can be passed around without explicitly > passing each element of the tuple individually. This is only to cut down > on parameters so it's not essential. I'm still playing with the idea > anyway. > yes, ok. note: my last major lang did, and my current one can (in theory, sadly, some needed stuff is not written for this), handle functions in an "argument by name" fashion. of course, c can't do this... > >> in my case I have a plain c api. >> >> annotated fragment of part of a frontend test (setup): >> bsdeNewWorld(); >> bsdeSetWorldAttrFV(BSDE_GRAVITY, VEC3(0, 0, -9.8)); > > Well, I don't know what the functions do but I'll make some assumptions. > Assuming the first call creates a 'world' I'm suggesting making that > explicit so, > > World1 = bsdeNewWorld() > > and then using that in the further calls something like > > bsdeSetWorldAttrFV &(World1) (BSDE_GRAVITY, VEC3(0,0,-9.8)) > > where the & indicates that we expect World1 to be /modified/ by the > function call. The following parameters, BSDE_GRAVITY etc, will be /read/ > by the function and read-only within it. > note, this was c code, and I avoided explicit use of "objects" intentionally. it is an imo gl-style api (fairly opaque, a small number of functions vs. a larger number of functions for different properties). some of my reasoning was that a reliance on internal structures was a bad thing, so I ended up using integer handles for everything. the api wants to hide as much of what is going on is possible. the world more calls a bunch of functions to make stuff, and others for figuring out what is going on... of course, during the implementation, another one of the uglier problems of gl-style api's popped up: in the case of 'FV' and 'DV' functions which can get/assign properties, it is not clear how many values will be accessed/filled, or how big the array is. a possible alteration could be requiring passing the size of the array. this is not so much a fix as it is a kludge. it makes it clear how many values are being moved, at the cost of requiring this to be passed. it may make sense though, in particular, in the case where a variable-sized array is being passed. this alone may be justification. bsdeSetWorldAttrFV(BSDE_GRAVITY, VEC3(0, 0, -9.8), 3); it would also allow simplifying some things within the api, but would be of virtually no use to frontend apps (apart from the variable-sized-array case). variable sized arrays, however, are too rare to justify their own functions, so quite possibly a size will be required. > In summary, anything on the left of an equal sign will be write-only as > far as the function is concerned and may not be read by it. Anything > preceded by an ampersand will be passed to the fuction and modifiable by > it. Anything to the right of the function name but _not_ preceded by an > ampersand will be read-only in the function. We can broadly categorise the > above three calls as, > > bsdeNewWorld returns 1, changes 0, reads 0 > bsdeSetWorldAttrFV returns 0, changes 1, reads 2 > VEC3 returns 1, changes 0, reads 3. > > I really don't know if this is any good. It does at least make the > "interfaces" to the functions clear. And if it looks familiar then that's > fine too! There's no need to make something look unfamiliar for the sake > of it. There's really not much radical thought behind it except that it > should be applied to absolutely every function call!!! I want the calls > that manipulate integers to have the same form as calls that manipulate > vast structures or even calls which manipulate offline files or databases. > ok. for my current language, everything sticks a lot closer to c, namely it uses a similar execution model, ... I had considered output arguments, but had not implemented them for technical reasons. requiring '&' (more in the c style though) could be a sensible approach. of course, then, I don't really need this anyways, I can typically use the approach of returning multiple values via an array. > One final thought. The above model lends itself to describing > communication as well as computation. How so? Well, every function can be > seen as an object to which messages are sent and from which replies are > received. The parameters and the value of any mods (the variables preceded > by & and that can be modified) will be /sent/ to the function. Then any > returns and the updated value of any mods will be /received/ from the > function. We're communicating! And not a Send command or a Receive command > in sight. > that is interesting at least. > How does that help? Well consider that with doing nothing we have already > a model for I/O. Say I want to send something to stdout, I don't code any > command to print, to sprintf, to write, to send etc etc. I just code > > stdout "Hello world\n" > > which, according to the above model sends the string to the function and > expects nothing back. Further if stdin is a stream of characters and I > want to read one I code > > ch = stdin > > Where I am effectively calling stdin with no parameters and expecting one > character in return. Maybe stdin will take a parameter saying how many of > its characters I want to read. If so I then code > > line = stdin 80 > > or some such. I still have a lot of work to do to prove to myself that the > above is workable in the real world. I won't bore you with the details of > that but your comments on the above are welcome. > it could be interesting, if not really my style of language in particular. was then vaguely thinking some of the semantics mismatch between prototype-oo dynamic typed languages and class-instance-oo statically typed languages. the issues don't help me much, only to show me that, likely, these styles will doubtful ever be able to really play well together. .