Mail #8142

Zurück zur Archiv-Hauptseite

Vorige Mail   Nächste Mail   Unformatiert/Volle Header
Übersicht  10 Tage   Betreff   Datum   Thread   Autor  

Von: Grant Jacobs
Betreff: Weird type/identifier conflicts
Datum: 2.3.2003, 13:56:26

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

Vorige Mail   Nächste Mail   Unformatiert/Volle Header
Übersicht  10 Tage   Betreff   Datum   Thread   Autor  

Antworten auf diese Mail

Antwort auf

Zurück zur Archiv-Hauptseite

Hinweis: Diese Seite enthält Informationen, die nicht vom Betreiber dieser Website, sondern von den Autoren der archivierten Mails stammen. Der Betreiber dieser Website ist nicht für den Inhalt dieser Informationen verantwortlich. Die weitere Verwendung dieser Informationen bedarf des Einverständnisses des jeweiligen Autors.

Sofern WWW-Adressen (URLs) in den archivierten Mails als Hyperlinks hervorgehoben werden, so geschieht dies ausschließlich zur Annehmlichkeit für den Leser. Der Inhalt der auf diese Weise angelinkten Webseiten spiegelt nicht notwendigerweise die Meinung des Betreibers dieser Webseite oder der Autoren der archivierten Mails wider. Der Betreiber dieser Webseite ist nicht für den Inhalt solcher Webseiten verantwortlich. Diese Seiten sind ausdrücklich nicht als Teil des Inhalts dieser Seite zu betrachten, sondern lediglich als Referenzen.

Diese Seite wurde erzeugt von Crystal 0.999 (Linux 2.4.27/i686).