At 09:33 AM 5/9/2001 -0700, Larry Wall wrote:
>Dave Mitchell writes:
>: | anyone know precisely what the following means?
>:
>: "K&R" style for indenting control constructs
>
>Strictly speaking, it means you always put the opening bracket on the
>same line as the keyword, and only worry about lining up the closing
>bracket:
I'd very much appreciate it if when we get the C style nailed down someone
could get a modified C-mode for emacs.
>I think that's silly. You misuse a variable that requires an auto, the
>compile dies, that's all. And macros can be very useful for an abstraction
>layer that intended to *hide* the implementation. Hoisting implementation
>details into the name defeats that abstraction.
I really, *really* don't want to hide very much of the implementation
details at the C code level. We do that right now, and it makes for a
twisty maze of macros, all alike. And the resulting C code bears very
little resemblance to what's actually written. (I've seen size increases of
two orders of magnitude--20 characters of source text become 2K or more
after macro expansion)
Some will be necessary, but I want to be really judicious in our usage.
>: If Perl 5 is anything to go by, the lifetime of Perl 6 will be at least
>: seven years. During this period, the source code will undergo many major
>: changes never envisaged by its original authors - cf threads, unicode
>: in perl 5. To this end, your code should make as few assumptions as
>: possible.
>
>Any statement that contains the phrase "as X as possible" is very
>likely one-sided. Balance is usually necessary. The fact of the
>matter is that code that makes as few assumptions as possible runs
>incredibly slow. So it's not possible to make as few assumptions as
>possible. (Well, it is, but we don't want to do that.)
Besides, we don't want to limit assumptions. Rather we want to limit the
scope of things any assumption can be made over. Assumptions are good--they
constrain the cases you need to deal with and, when correct, they let you
take shortcuts you can't otherwise take. We just need to make sure that
assumptions don't leak out to places that are inappropriate.
>: For example, if your struct eventually needs more than
>: 32 flags, can it be gracefully expanded to more than a single word of
>: flags? Bear in mind that there may be code in other people's Perl
>: extensions and code that Perl itself is embedded in, all of which
>: may be using your stuff. Or there may be other distributions of Perl
>: using your code. You may find it rather difficult to persuade all these
>: other programmers to modify their code due to your lack of foresight.
>
>Given this sort of directive, many programmers would go off and invent
>a general property system that is completely general and runs like a
>dog.
Nah, they'll invent a limited special-case property system that runs like a
dog. :)
We do need a good general-purpose property system, and we need to decide
what properties need to be fast and which ones don't.
>: If you do put an optimisation in, time it on as many architectures
>: as you can, and reject it if it slows down on any of them! And remember
>: to document it.
>
>Or disable the optimization on that architecture, to get the benefit of
>it elsewhere, balancing the benefits of the small code fork against
>the benefits of not forking. When in Rome, do as the Romans would do
>if they weren't Roman and just visiting.
I'm expecting we'll have platform-specific code possible on all platforms,
rather than the core plus odd addon we have now. Spots that can potentially
benefit from platform specific bits (like thread ID registers, or async
floating point error assertions, or whatever) should be places where we do
have macros (or function calls, as appropriate) that can be substituted in
at build time.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
