At 8:33 AM +0100 1/3/03, Frank Heckenbach wrote:
Grant Jacobs wrote:
[snip]
You want to distinguish known and unknown identifiers in the error messages to make things clearer (?)
unknown identifier `%s'
type name expected, `%s' given
?
Yup. Such a major change, huh ;-) Being pedantic, I'd add 'unknown identifier' after the comma in the second line too:
type name expected, unknown identifier `%s' given
but apart from being a little redundant it makes the line a bit long.
An alternative one-liner might be:
unknown identifier '%s' found in place of type name
Which is a tad longer still... whatever, as long as 'unknown identifier' makes it into there... if it weren't for the length, I kind-of like the last one, FWIW.
[snip]
No, it doesn't. You only have to use the lower ones if you use some declaration from them. And if you do, you generally know that you do. (Well, I'm used to this, so it may appear more natural to me. But I've never had a big problem due to it ...)
I know you can to this; its what I'm using at present and I've used it before too. See my next post (which may be my last on this matter as people really are not "getting it" so I'm thinking of giving up... besides on a pragmatic front modules with 'export all' look like they might do enough to keep me happy for now).
Yes, that's why GPC has `export Foo = all' as an extension (but referring only to the current module's interface, not to re-exporting). With the proposed extension `export Foo = all (Bar, ...)', it would be possible to export all from the current interface and some selected items from imported modules (such as some types used, as in your example) which I'd consider more reasonable than just re-exporting everything.
I'd like to know more about this as it might let me do roughly what I wanted. There are a few other (minor) differences with using a unit approach, but lets just leave that for now...
Once you have a means of obtaining just a specified portion of an interface,
This might be useful. Do you have any ideas for the syntax (in particular for units), other than an `export' clause (for modules)?
I could give you a detailed account of what I am thinking if you *really* want... I'll touch on it in my next post but I'm not likely to post code examples - yet. And I imagine you'll want a code example, naturally enough :-)
the module and unit approaches presented here would be equivalent (AFAICS), just coming from different angles. If you also added an 'export all' of a sub module (which I think you were mentioning the other day), they'd pretty much be exact alternatives. (Export is still in the docs as 'not yet implemented!)
Don't you mean `exports' (which is, AFIAK, for BP compatible "libraries", not to be confused with `export' for EP modules)?
No. This sort of thing does make this kind of discussion confusing :-) I'm talking about modules in that paragraph (a la EP) and hence 'export'. Confused? ;-) (You've already answered part of this above.)
unit FileOps;
interface uses FnameUnit;
function WordCount( var fname: fnames ): integer ;implementation { expected stuff... } end.
[snip]
The latter has its advantages... It'd be nicer if we had the option of only passing on just the things needed by FileOps should we want to, e.g. uses FnameUnit only ( fnames ); (in analogous fashion to how import specifies subsets.)
Doing the restriction on the import would be too ... well, restricting. ;-) You might need other stuff from FnameUnit within FileOps.
In your model not mine! Think two parallel uses as posted elsewhere, etc, etc. I should really have made up some complicated full code example that illustrates all the points, but I'm too lazy ;-) The example above doesn't include everything, so it looks like the existing unit model which is confusing I suppose. To round out the picture a bit more there should be a 'uses FnameUnit' in the implementation section (so the implementation has everything it needs) and ideally the uses in the interface section would only import fnames so that fnames is the only thing propagated. And you don't have the uses in the interface section "crossing the boundary" to the implementation section (which, FWIW, I personally think is a design flaw in "standard" units, but *please* don't start arguing about that!!). Someone posted a code example like this earlier. Read the *gist* of what I am writing more that my code which is just an incomplete skeleton. But this is all getting a bit long in the tooth -- ?
For a similar reason, having a brute force compile-all option appeals to me (do the equivalent of --automake, but simply recompile all units you run into regardless of what status the units have [except that you'll want to detect circular dependencies!]).
You mean `--autobuild'?
Oh. That one slipped past me! Must try it out... thanks. (I have this list of compiler options on paper I thought might be useful: this never made it into it... must have thought I'd never need --autobuild given the definition of --automake. My fault.)
As a general rule, everything after the first error message may or may not be accurate. This will always remain true, since no compiler can guess what you really mean when there is an error.
Like most people, I've been through that particular mill for a long time...! (But I'm still capable of confusing myself over an error message!) We'd all love a compiler that didn't do this, but "that'll be the day..." :-) (Maybe in my own programming language...;-) )
My suggestion: Implement a real AI first, then the rest will be trivial. ;-)
If how this conversation has spiralled off in weird angles is anything to go by, AI would be a walking disaster! :-) (No offense to any AI folks!) Imagine our AI units all busy arguing how things ought to be...!! Users would wonder why their CPUs are so busy but nothing productive seems to be get done... ;-)
Grant