Re: what I meant about hungarian notation

[Bart Lateur]

On Tue, 08 May 2001 20:21:10 -0500, David L. Nicol wrote:

>What if, instead of cramming everything into "scalar" to the point
>where it loses its value as "a data type that magically converts
>between numeric and string, as needed," we undo the Great Perl5
>Dilution and undecorate references.

Undecorated if for function calls and methods. And buolt-ins, of course.

>So what I am suggesting is, Scalar as catch-all for unclassifiables
>that are neither strings nor numbers may have been a historic stopgap
>measure in perl 5 which was seen to be unworkable given the profusion of
>object types which became available in perl 6.
>
>An object of type "abstracted reference to a chair" is _NOT_ an object of
>type "numeric or string that magicly switches between as needed"

So what you're really saying is that references aren't really scalars,
but their own type. Thus they need their own prefix.

But we've sort of run out of possible prefixes.

-- 
Bart.

Re: what I meant about hungarian notation

[Bart Lateur]

I really need to spell-check better.

>Undecorated if for function calls and methods. And buolt-ins, of course.

Undecorated is for function calls and methods. And built-ins, of course.

-- 
Bart.

Re: PDD: Conventions and Guidelines for Perl Source Code

[Dave Mitchell]

> I see nothing about namespacing, e.g. Perl_


All entities should be prefixed with the name of the subsystem they appear
in, eg C, C. They should be further prefixed
with the word 'perl' if they have external visibility or linkage,


eg

perlpmc_foo()
struct perlio_bar
typedef struct perlio_bar Perlio_bar
#define PERLPMC_readonly_TEST ...

ie essentially we are making the subsystem name more verbose. This kind of
matches the way things are currently done in PerlIO.

Re: PDD: Conventions and Guidelines for Perl Source Code

[Larry Wall]

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:

: | my personal pet peeve: death to dSP and friends !!
: 
: Macros must never define or implicity use auto variables unless it
: is essential for extensibility. In this case, defining macros should
: be prefixed with C, and macros which use said variables should
: be prefixed with C, eg
: 
:   #define DEFVAR_save_stack   struct Stack *oldsp = sp;
:   #define VAR_restore_stack   sp = oldsp;
: 
: This then at least provides some warning to the programmer that things
: are being done behind his/her/its back.

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.

The whole point of dSP and friends was to make it easier to switch to
inline threaded code if we felt like it, in which case all bets are off
as to which variables are auto.

: =head2 Extensibility
: 
: 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.)

: 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.  I guess the real problem here is that we aren't saying what
*kinds* of assumptions are bad.  One of the assumptions we need to
avoid is that abstractions in the compiler are necessarily reflected in
complications at runtime.  Using the example given, if you need more
than 32 flags, and you've abstracted your flags with macros, then it's
pretty simple to redirect some of the flags to a different flag word
without introducing a level of indirection at run-time.

Sorry, I know this point is actually balanced out later in the document,
but it hit a hot button.

: 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.

Larry

Re: PDD: Conventions and Guidelines for Perl Source Code

[Jarkko Hietaniemi]

> : 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.  I guess the real problem here is that we aren't saying what

To make a preëmptive strike on this we need to have a general property
system API in the language itself.  Hey, wait...

> *kinds* of assumptions are bad.  One of the assumptions we need to
> avoid is that abstractions in the compiler are necessarily reflected in
> complications at runtime.  Using the example given, if you need more
> than 32 flags, and you've abstracted your flags with macros, then it's

Macrofication gives us source level comfort but I think the point here
was more in the area binary compatibility.  Both nice things.

> pretty simple to redirect some of the flags to a different flag word
> without introducing a level of indirection at run-time.
> 
> Sorry, I know this point is actually balanced out later in the document,
> but it hit a hot button.

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: PDD: Conventions and Guidelines for Perl Source Code

[Dave Mitchell]

Larry Wall <[EMAIL PROTECTED]> wrote:
> Dave Mitchell writes:
> : | my personal pet peeve: death to dSP and friends !!
...
> 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.
> 
> The whole point of dSP and friends was to make it easier to switch to
> inline threaded code if we felt like it, in which case all bets are off
> as to which variables are auto.

My main objection to dSP et al is that it represents the innermost circle
of the hell that is Perl 5 macros. Stuff like this is totally bemusing to
the newcomer:

  dPOPPOPnnrl;
  if (right == 0.0) 

I was just trying think of ways of altering people that Something Funny
is Going On Here. Oh well, I surrender...

> : 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.

My thinking behind "if fails on one, avoid on all" was that if it failed
on at least one, then it may well fail on others that you dont have access
to - either now or in the future, and thus perhaps isnt as good an optimisation
as you figured. The other way would to be only enable for those architectures
that experience a speedup.  

Re: PDD: Conventions and Guidelines for Perl Source Code

[Larry Wall]

Larry Wall writes:
: 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:

That's funny, my examples disappeared, leaving only a colon.  Here:

mumble (natter, gromish) {
...
}

I then went on to point out that if there are multiple lines in the
front matter, I like to line up the first bracket as well:

mumble (natter, gromish,
natter, gromish,
natter, gromish,
natter, gromish)
{
...
}

Larry

Re: PDD: Conventions and Guidelines for Perl Source Code

[Larry Wall]

Dave Mitchell writes:
: My thinking behind "if fails on one, avoid on all" was that if it failed
: on at least one, then it may well fail on others that you dont have access
: to - either now or in the future, and thus perhaps isnt as good an optimisation
: as you figured. The other way would to be only enable for those architectures
: that experience a speedup.  

Makes sense.

Larry

Re: PDD: Conventions and Guidelines for Perl Source Code

[Dan Sugalski]

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

Re: what I meant about hungarian notation

[Bart Lateur]

On Wed, 9 May 2001 11:06:45 -0400, Bryan C. Warnock wrote:

>>At that
>> point, Hungarian notation fell apart for me. Its strict use adds (IMO) as
>> much confusion as MicroSoft's redefinition of C, with thousands of
>> typedefs representing basic types ("LPSTR" and "HWND" come to mind as the
>> most common).
>
>Not mention the hoop-jumping required to keep variable names in sync with 
>code changes.  (signed-ness, short->int->long, etc)

Which reminds me... One of the fundamental functions in the Windows API
is SendMessage. Here, one can give two parameters. They're call wParam
and lParam. Yes, originally, wParam was a word (16 bit), and lParam was
a long (32 bit).

But under the Win32 API, every kind of integer was turned into a long,
but the names wParam and lParam still stuck, despite the fact that both
are now 32 bit integers.

-- 
Bart.

RE: what I meant about hungarian notation

[David Grove]

> 
> > sane indentation by making it part of the language, Perl is a
> > language that enforces a dialect of hungarian notation by making
> > its variable decorations an intrinsic part of the language.
>
> But $, @, and % indicate data organization, not type...

Actually they do show "type", though not in a traditional sense.
Organization <-> type is semantic oddery, but they do keep our heds straight
about what's in the variable.

> > What if, instead of cramming everything into "scalar" to the point
> > where it loses its value as "a data type that magically converts
> > between numeric and string, as needed," we undo the Great Perl5
> > Dilution and undecorate references.
>
> Continuing this further, why keep *any* notation at all? Why are vars with
> string or numeric data more worthy of $?

What do you suggest? m_sc_I? (An object member variable that's a scalar
named I.) Bah!

> 
> > We are at the point where there are so many variable types that the
> > dollar sign on their names has become a hollow formality.
>
> Again, I'm confused. All I expect from something with a $ is that it's a
> single value, not necessarily a string or a number. And what if I want to
> treat a string-ifiable object as an untyped value? Is my var then "$
> worthy"?

If all types are references, $ does appear to lose some of its historical
distinction. On the other hand, @foo[1] as a replacement for $foo->[1] does
have some linguistic merit, so I've been listening to it with interest.

My primary concern in this area is the introduction of forced verbosity.

p

Re: what I meant about hungarian notation

[Simon Cozens]

On Wed, May 09, 2001 at 04:02:43PM +0200, Bart Lateur wrote:
> What he is proposing is that Perl6 would have a kind of variable that
> doesn't have a prefix. That isn't perlish IMO.

open OUT, ">foo" or die $!;
print OUT "Rubbish!\n";
close OUT;
OUT = STDERR; # Works in 5.7.1, I think.

(Incidentally, I believe prefices should stay.)

-- 
 I detest people who get in their cars before turning off the 
alarm, fiddle around a bit, and then turn it off
 maybe they're afraid someone might steal the car in the short time 
before they turn off the alarm and actually get in
 it's a race condition, you know

Re: Tying & Overloading

[Michael G Schwern]

On Wed, May 09, 2001 at 02:05:48PM -0700, Austin Hastings wrote:
> Will it be possible to define "pointer classes", a la C++, in a
> relatively "smooth" manner?
> 
> That is, an object R has methods of its own as well as methods
> belonging to the "referred to" object?

Sounds you're looking for automatic delegation.  There's an RFC
dealing with this...  http://dev.perl.org/rfc/193.pod
and a Perl5 module planned, Class::Delegation.

-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
An official "I want James Earl Jones' cock up my ass" t-shirt.
http://www.goats/com/archive/010303.html

RE: Apoc2 - concerns ::::: new mascot?

[David Grove]

I've often thought about trademarking a Shiny Ball (Perl) and an
oyster/clam/mussel shell "with association to the Perl language". The first
thought is to give a demonstration on how rude holding this type of symbol
is. But, I'd have licensed it to the community openly after an initial snit.
I didn't do it because it would have taken $600 to prove a point.


David T. Grove
Blue Square Group
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> -Original Message-
> From: Bart Lateur [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 10:51 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Apoc2 -  concerns : new mascot?
>
>
> On Wed, 9 May 2001 10:24:26 -0400, David Grove wrote:
>
> >I remember someone (whether at O'Reilly or
> >not I don't remember) saying that, even if it looks like a horse
> but has a
> >hump, it's not allowed. Or was that an alpaca with a llama...
> >
> >The RFC pleads for a community spirit from ORA. Barring that, it
> seeks a new
> >symbol for the community entirely.
>
> Several perl ports, and at least one book, use a "shiny ball" as a
> symbol.
>
>   
>
> Scroll down to the heading "Book Nickname (?)".
>
> It took me a bit of thinking before I realized what this "shiny ball"
> represents. Odd.
>
> --
>   Bart.
>

Re: what I meant about hungarian notation

[Larry Wall]

I'd just like to point out that it's already becoming fairly easy
to establish a bare alias for a scalar variable even in Perl 5:

my $foo;
my sub foo : lvalue { $foo }

This sort of thing will only get easier in Perl 6, when people can pull
in their own grammatical rules to enable them to say

my foo;

to mean the above, or something like it.  So people who hate funny
characters can define as many bare names as they like.  They'll just
have to figure out how to interpolate them, and they'll have to use
explicit method calls to establish some of the context that Perl can
currently guess from the funny characters.  And they'll likely be
reviled by the people who prefer the culture of $ and @.  There may be
wars fought, and the standard Perl libraries may be subject to ethnic
cleansing.  Culture wars arise spontaneously, but that should not deter
us from enabling people to build new cultures.  Perhaps some of those
new cultures will be slightly less hostile to other cultures, knowing
their multicultural roots.  If Perl culture has no other effect on the
world, I hope it shows how a culture can be aware of both its own
strengths and its own limitations.

I happen to like $ and @.  They're not going away in standard Perl as
long as I have anything to do with it.  Nevertheless, my vision for Perl
is that it enable people to do what *they* want, not what I want.

Larry

Re: what I meant about hungarian notation

[Simon Cozens]

On Wed, May 09, 2001 at 09:58:44AM -0700, Larry Wall wrote:
> I'd just like to point out that it's already becoming fairly easy
> to establish a bare alias for a scalar variable even in Perl 5:
> 
> my $foo;
> my sub foo : lvalue { $foo }

I tried working on a "pythonish" module built around

sub AUTOLOAD : lvalue { $$AUTOLOAD }

Didn't finish it, but got close enough.

-- 
Britain has football hooligans, Germany has neo-Nazis, and France has farmers. 
-The Times

Re: what I meant about hungarian notation

[Larry Wall]

David Grove writes:
: Probably rehashing (no pun intended) a lost cause, but this sounds logical
: to me, if you're referring to something similar to PHP's Array['text']
: notation. I.e.,
: 
: $array[1]
: $hash{'one'}
: 
: becoming
: 
: @group['one']

Currently, @ and [] are a promise that you don't intend to use string
indexing on this variable.  The optimizer can make good use of this
information.  For non-tied arrays of compact intrinsic types, this
is going to be a major performance win in Perl 6.

Larry

Re: what I meant about hungarian notation

[Matt Youell]

> > But $, @, and % indicate data organization, not type...
>
> Actually they do show "type", though not in a traditional sense.
> Organization <-> type is semantic oddery, but they do keep our heds
straight
> about what's in the variable.

Sure. But my point was that Perl's use of $ isn't Hungarian notation.
Otherwise (as has already been noted), we'd need line noise for each data
type. This is the crisis that David N sees... I'm questioning whether there
is such a crisis.

> > Continuing this further, why keep *any* notation at all? Why are vars
with
> > string or numeric data more worthy of $?
>
> What do you suggest? m_sc_I? (An object member variable that's a scalar
> named I.) Bah!

Actually, you can do that now. I've seen $m_I. Of course, that was from a
C++ guy that was just learning Perl.

I abhor Hungarian notation. It's the dark side of Lazy. And chances are that
if you actually *need* it, your code needs some serious factoring, IMHO.

> My primary concern in this area is the introduction of forced verbosity.

Typing is good for you. It builds strong bodies 8 ways.

- Matt

RE: what I meant about hungarian notation

[David Grove]

> -Original Message-
> From: John Porter [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 11:51 AM
> To: [EMAIL PROTECTED]
> Subject: Re: what I meant about hungarian notation
>
>
> David Grove wrote:
> > $ is a singularity, @ is a multiplicity, and % is a
> multiplicity of pairs
> > with likely offspring as a result. ;-)
>
> Actually, % is also simply a multiplicity, differentiated only
> by the semantics of its indexing.
>
> Which is why I argued, some time back, in favor of conflating
> arrays and hashes.

Probably rehashing (no pun intended) a lost cause, but this sounds logical
to me, if you're referring to something similar to PHP's Array['text']
notation. I.e.,

$array[1]
$hash{'one'}

becoming

@group['one']

or something similar in Perl 6. Heretofore the issue may have been the
indexing done by hashes, but since these will become actual objects in Perl
6, *how* they are indexed could be a simple flag (sorted | numeric, sorted |
string, fast | string, etc.)

The result would be two types of variables: single and multiple.

But I imagine that this has been gone over many times.

p

Re: what I meant about hungarian notation

[David L. Nicol]

Bart Lateur wrote:
> 
> So what you're saying is that references aren't really scalars,
> but their own type. Thus they need their own prefix.
> 
> But we've sort of run out of possible prefixes.

that is my interpretation of the p4->p5 decision to make references
fit within the scalar type; which itself echoes the nots&bolts
availability of memory addresses as integer types.  Which cause[s|d]
so much confusion when porting 32-bit code to 64-bit architecture

If perl6 variable decorations switch from Part-Of-The-Name
to type casts, pretending that a reference is a string continues
to make the same amount of sense as pretending that a pointer to
a structure is an integer.  It works, but it's troublesome.



-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
  all your base are belong to us, Will Robinson

RE: what I meant about hungarian notation

[David Grove]

> >An object of type "abstracted reference to a chair" is _NOT_ an object of
> >type "numeric or string that magicly switches between as needed"
>
> So what you're really saying is that references aren't really scalars,
> but their own type. Thus they need their own prefix.
>
> But we've sort of run out of possible prefixes.

I've thought about that too. However, it's a misapplication of perlishness.
$ is a singularity, @ is a multiplicity, and % is a multiplicity of pairs
with likely offspring as a result. ;-)

In that thought pattern, the words "string", "number", and "reference" don't
even exist.

p

Re: what I meant about hungarian notation

[Bryan C . Warnock]

On Wednesday 09 May 2001 10:44, David Grove wrote:
> I used to request hungarian notation from programmers who worked for me,
> until I saw the actual compliance with that request culminate in a local
> variable named l_st_uliI. Of course, that's an "static unsigned int i"
> used as a simple iterator in local scope. Of course, written more
> appropriately, this would have just been "static unsigned int i". At that
> point, Hungarian notation fell apart for me. Its strict use adds (IMO) as
> much confusion as MicroSoft's redefinition of C, with thousands of
> typedefs representing basic types ("LPSTR" and "HWND" come to mind as the
> most common).

Not mention the hoop-jumping required to keep variable names in sync with 
code changes.  (signed-ness, short->int->long, etc)


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Apoc2 - concerns ::::: new mascot?

[John L. Allen]

On Wed, 9 May 2001, Simon Cozens wrote:

> Beginning Perl was going to use a blown-up microscope slide of a grain
> of sand - the beginnings of a pearl. Of course, nobody would have got
> it, so we went with a cat instead, which is even more oblique.

Hmmm, I suppose a blown-up grain of sand could also be used on the cover 
of a book about advanced perl internals, because a grain of sand is 
what's "at the core" of a pearl.

John.

RE: Apoc2 - concerns ::::: new mascot?

[David Grove]

/me ponders the use of a cat in that context... Furball?



David T. Grove
Blue Square Group
[EMAIL PROTECTED]
[EMAIL PROTECTED]
 

> -Original Message-
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 10:55 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Apoc2 -  concerns : new mascot?
> 
> 
> On Wed, May 09, 2001 at 04:50:51PM +0200, Bart Lateur wrote:
> > Several perl ports, and at least one book, use a "shiny ball" as a
> > symbol.
> > It took me a bit of thinking before I realized what this "shiny ball"
> > represents. Odd.
> 
> Beginning Perl was going to use a blown-up microscope slide of a grain
> of sand - the beginnings of a pearl. Of course, nobody would have got
> it, so we went with a cat instead, which is even more oblique.
> 
> -- 
> You're never alone with a news spool.
> 

Re: Apoc2 - concerns ::::: new mascot?

[Simon Cozens]

On Wed, May 09, 2001 at 04:50:51PM +0200, Bart Lateur wrote:
> Several perl ports, and at least one book, use a "shiny ball" as a
> symbol.
> It took me a bit of thinking before I realized what this "shiny ball"
> represents. Odd.

Beginning Perl was going to use a blown-up microscope slide of a grain
of sand - the beginnings of a pearl. Of course, nobody would have got
it, so we went with a cat instead, which is even more oblique.

-- 
You're never alone with a news spool.

Re[3]: Apoc2 - concerns ::::: new mascot?

[A. C. Yardley]

A. C. Yardley writes:

> taken off list.  (I don't mean to arrogant the decisional authority

Erh, make that  arrogate ...

/acy

RE: Apoc2 - concerns ::::: new mascot?

[David Grove]

"Core Perl" is probably trademarked to Sun Microsystems. ;-)


David T. Grove
Blue Square Group
[EMAIL PROTECTED]
[EMAIL PROTECTED]
 

> -Original Message-
> From: John L. Allen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 09, 2001 1:29 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Apoc2 -  concerns : new mascot?
> 
> 
> 
> 
> On Wed, 9 May 2001, Simon Cozens wrote:
> 
> > Beginning Perl was going to use a blown-up microscope slide of a grain
> > of sand - the beginnings of a pearl. Of course, nobody would have got
> > it, so we went with a cat instead, which is even more oblique.
> 
> Hmmm, I suppose a blown-up grain of sand could also be used on the cover 
> of a book about advanced perl internals, because a grain of sand is 
> what's "at the core" of a pearl.
> 
> John.
> 

Re: what I meant about hungarian notation

[John Porter]

Simon Cozens wrote:
> A scalar's a thing. 

Just as the index into a multiplicity is a thing.

-- 
John Porter

RE: Re[2]: Apoc2 - concerns ::::: new mascot?

[David Grove]

> As my Con Law professor was fond of saying, "Horse hooey!"*

Camel cookies.

;-)

> These types of issues are not nearly so clear cut as many company's
> would have people believe.  E.g., O'Reilly is book publisher that
> engages in the business of publishing and selling books for a
> profit.  They specifically are not a computer software company
> (well, they, of course, do or have developed some software
> for profit, but this fact does not reach to this example) nor do
> they possess a proprietary interest in Perl.

I'm afraid you don't know much about O'Reilly. O'Reilly does have both
proprietary interest in Perl products and financial interest in
compan(y|ies) who produce Perl software. (How many of the several current
valid Win32 Perl's do you see on the ORA website?) The argument could quite
well extend there to software.

> I suspect whomever made the above assertion was actually saying
> the *company* would consider it a violation and, therefore, seek

I'm not sure what the allusion was (horse or alpaca), but I do believe that
it was Edie I who was alluding. Ask her (but wear protective gear).

> **  The above said, please note, imo, this is decidely off-topic to
> this list, and I'd suggest any further discussion on the matter be
> taken off list.  (I don't mean to arrogant the decisional authority
> of this list to myself; but only to be sensitive to the topic of the
> list and the expectations of list members.)

I asked about the meta group, but haven't heard anything yet. It really
belongs there. When possible, if there remains interest in the thread, I'll
redirect it there myself.

Re: Strings vs Numbers (Re: Tying & Overloading)

[nick]

Bart Lateur <[EMAIL PROTECTED]> writes:
>On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:
>
>>How do you concatenate together a list of variables that's longer than one
>>line without using super-long lines?  Going to the shell syntax of:
>>
>>PATH=/some/long:/bunch/of:/stuff
>>PATH="${PATH}:/more/stuff"
>>
>>would really be a shame.
>
>A backslash at the end of a line?
>
>Kidding!

Obviously you meant a '+' in column 6 of the continuation line ;-)

-- 
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/

Re: what I meant about hungarian notation

[Bart Lateur]

On Wed, 9 May 2001 09:47:56 -0400, John Porter wrote:

>> Undecorated if for function calls and methods. And buolt-ins, of course.
>
>No, that's the situation already.  David is proposing a change.
>
>> So what you're really saying is that references aren't really scalars,
>> but their own type. Thus they need their own prefix.
>
>No, that does not follow.

What he is proposing is that Perl6 would have a kind of variable that
doesn't have a prefix. That isn't perlish IMO. We might just as well
drop all prefixes. At least, that'd be consistent.

-- 
Bart.

Re: sandboxing

[Dan Sugalski]

At 07:43 AM 5/8/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: We'd want an alternative opcode running loop for all this, and it could
>: easily enough check times, as could special opcodes. Long-running codes
>: could also check at reasonable breakpoints. (Still in trouble with C
>: extensions, but that's pretty much a guarantee)
>
>It's not necessarily an alternative run loop--we need to do something
>like this anyway for safe signals.  What's alternative is that the
>sandbox gets a periodic mandatory signal telling it to check resource
>limits.

Yeah, but the granularity for safe signals might be too coarse for good 
resource management. Though we might not want to worry about quite that 
level of granularity for sandboxes.

Brings to mind some of the issues with interrupting timers (alarm for 
blocking I/O and such), unfortunately.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Tying & Overloading

[nick]

James Mastros <[EMAIL PROTECTED]> writes:
>From: "Larry Wall" <[EMAIL PROTECTED]>
>Sent: Monday, April 23, 2001 1:10 PM
>Subject: Re: Tying & Overloading
>> Helgason writes:
>> : I _really_ think dot-syntax would make perl prettier as well as make it
>> : more acceptable to the world of javacsharpbasic droids. Which is some
>> : kind of goal, no?
>> Consider it a given that we'll be using . for dereferencing.  (Possibly
>> with -> as a synonym, just for Dan. :-)
>>
>> Larry
>
>I hate yelling without good reason, but this /is/ good reason.  CAN SOMBODY
>PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS?

One reason I have heard is that COM (Common Object Model) documents
incantations to call up external objects in VBish thing.whatnot.attrib
style. Not having to s/\./->/ make it easier on newbies.

-- 
Nick Ing-Simmons
who is looking for a new job see http://www.ni-s.u-net.com/

Re: what I meant about hungarian notation

[David L. Nicol]

David Grove wrote:

...
> This is frightening me too. I really don't like the thought of
> 
> $i = "1.0";
> $i += 0.1 if $INC;
> $i .= " Foo, Inc.";
> 
> (or more specifically a one line version that converts several times for a
> single statement)
> 
> becoming
> 
> my str $i = "1.0";
> if($INC) {
> $i.asFloat += 0.1;
> }
> $i.asString .= " Foo, Inc.";
> 
> We appear to be moving in that direction, trading programmer convenience
> with politically correct verbosity.


that isn't what I suggested.

With references-in-scalars, the p5 status quo, there's no hint at all what
 $R refers to.  It might not be a reference, but it might be a "genuine"
scalar, holidng a number or some text.  You can't deny this is a confusing
state of affairs.  I have no idea if


print $R

is going to give me a reasonable output or some internals-debugging noise.

We even have the C operator to help us with this problem

sub deref($);
sub deref($){ref $_[0] ? deref $$_[0] : $_[0]);
print deref $R;


So why not, since the $ preceding the name of a reference doesn't do
a whole lot, let's deprecate it?


1   @$R
2   @{$R}
3   @{R}
4   @{&R}
5   @{'R'}
6   @R


How much difference does it make, in situations where these
are all defined, 6/3 starts binding to 4 rather than 5?


You know, we have it (undecorated variablkes) already, if we don't mind
always using
curlies around variable names, we can create subroutines to return
references for
each and every variable.


my Dog spot;

could, in p5 terms, be short for something like this:


{
my $obj = new Dog;
sub spot { return $obj }
};


This is the exact same discussion from October 2000. :)

Re: Tying & Overloading

[Austin Hastings]

Will it be possible to define "pointer classes", a la C++, in a
relatively "smooth" manner?

That is, an object R has methods of its own as well as methods
belonging to the "referred to" object?

E_G: print "$R.toString is a reference to $R->toString";

Or some such? The notion of $R.getData.toString is kind of lame...

=Austin


> >> Consider it a given that we'll be using . for dereferencing. 
> (Possibly
> >> with -> as a synonym, just for Dan. :-)
> >>
> >> Larry


=

Austin Hastings
Global Services Consultant
Continuus Software Corporation
[EMAIL PROTECTED]

__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: what I meant about hungarian notation

[John Porter]

David Grove wrote:
> something similar to PHP's Array['text'] notation. 

(I think awk, but whatever...)


my @collection is associative;


> since these will become actual objects in Perl 6,
> *how* they are indexed could be a simple flag 

Or, in fact, any user-defined scheme.


> The result would be two types of variables: single and multiple.

Ah!  :-)

-- 
John Porter

Re: Apoc2 - concerns ::::: new mascot?

[Dan Sugalski]

At 04:06 PM 5/9/2001 +0100, Simon Cozens wrote:
>On Wed, May 09, 2001 at 11:02:52AM -0400, David Grove wrote:
> > oyster/clam/mussel shell "with association to the Perl language". The first
> > thought is to give a demonstration on how rude holding this type of symbol
> > is.
>
>I think all it would demonstrate is how flawed the copyright system is.

Nope. It'd demonstrate how flawed the trademark system is. Copyright flaws 
are completely different..

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: what I meant about hungarian notation

[Graham Barr]

On Wed, May 09, 2001 at 02:04:40PM -0400, John Porter wrote:
> Simon Cozens wrote:
> > A scalar's a thing. 
> 
> Just as the index into a multiplicity is a thing.

Yes, but as Larry pointed out. Knowing if the index is to be treated
as a number or a string has some advantages for optimization

Graham.

Re[2]: Apoc2 - concerns ::::: new mascot?

[A. C. Yardley]

David Grove writes:

> Probably not if it had scales, webbed feet, a hookbill, antennae, a furry
> coontail, and udders. Otherwise, if it looks like a camel at all, it's
> considered a trademark violation. I remember someone (whether at O'Reilly or
> not I don't remember) saying that, even if it looks like a horse but has a
> hump, it's not allowed. Or was that an alpaca with a llama...

As my Con Law professor was fond of saying, "Horse hooey!"*

These types of issues are not nearly so clear cut as many company's
would have people believe.  E.g., O'Reilly is book publisher that
engages in the business of publishing and selling books for a
profit.  They specifically are not a computer software company
(well, they, of course, do or have developed some software
for profit, but this fact does not reach to this example) nor do
they possess a proprietary interest in Perl.  There is a strong
argument that the above assertion (or any cause of action initiated
on the basis of this assertion) reaches too far and, consequently,
would fail.

I suspect whomever made the above assertion was actually saying
the *company* would consider it a violation and, therefore, seek
judicial relief for *the perceived* violation.  A company's
perception of a violation is a far different thing from a court's
decision there was, in fact, a violation.  Again, as I mentioned,
there are strong arguments to the contrary.**

Folks really gotta remember to take legal arguments as what they
are, legal *arguments.*  They decidedly are *not* court
decisions.***

/acy


*  Well, maybe his remark was a bit stronger than, "hooey,"
but ... y'all get the idea.

   Please note, my exclamation is directed at the person who made
the assertion *to* David about how using anything that looks like a
camel would be considered a violation.  It specifically is *not*
addressed at David or his relating of the same.

**  The above said, please note, imo, this is decidely off-topic to
this list, and I'd suggest any further discussion on the matter be
taken off list.  (I don't mean to arrogant the decisional authority
of this list to myself; but only to be sensitive to the topic of the
list and the expectations of list members.)

*** One last remark:  Often, even court decisions are not
dispositive, for any number of reasons.

Re: Apoc2 - concerns ::::: new mascot?

[Simon Cozens]

On Wed, May 09, 2001 at 11:02:52AM -0400, David Grove wrote:
> oyster/clam/mussel shell "with association to the Perl language". The first
> thought is to give a demonstration on how rude holding this type of symbol
> is. 

I think all it would demonstrate is how flawed the copyright system is.
But then, we knew that, right?

-- 
>but I'm one guy working weekends - what the hell is MS's excuse?
"We don't care, we don't have to, we're the phone company."
- Ben Jemmet, Paul Tomblin.

Re: Apoc2 - concerns ::::: new mascot?

[Dave Mitchell]

And there was me thinking the shiny ball must be a camel dropping 

Re: what I meant about hungarian notation

[Eric Roode]

[on David Nicol's thought that maybe references should be treated
differently than other scalar data]
>
>But $, @, and % indicate data organization, not type...
>

Perhaps it's a mistake that Perl treats numbers and strings the
same. Perhaps "$" should be broken out into two prefixes: S for
strings, and | for numbers. Use $ when it's unknown what type
a variable will hold, or for a variable that can hold either type.

Sfoo = 'a string';
|bar = 'a number';
$baz = Sfoo || |bar;

And references are right out.


;-)
 --
 Eric J. Roode[EMAIL PROTECTED]
 Senior Software Engineer, Myxa Corporation

RE: Apoc2 - concerns ::::: new mascot?

[David Grove]

Probably not if it had scales, webbed feet, a hookbill, antennae, a furry
coontail, and udders. Otherwise, if it looks like a camel at all, it's
considered a trademark violation. I remember someone (whether at O'Reilly or
not I don't remember) saying that, even if it looks like a horse but has a
hump, it's not allowed. Or was that an alpaca with a llama...

The RFC pleads for a community spirit from ORA. Barring that, it seeks a new
symbol for the community entirely. A three-humped camel may give a good
visual for Perl 6 as it exists today (fantasy and a bit convoluted), but it
may be a bit difficult to apply to the upcoming completed language. ;-)

BTW, what happened to meta? After a server outage of some length I believe I
was removed, but it appears no longer to exist when I try to subscribe.

David T. Grove
Blue Square Group
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> -Original Message-
> From: RFC850 host name inserted by qmail-smtpd
> [mailto:[EMAIL PROTECTED]]On Behalf Of David L. Nicol
> Sent: Tuesday, May 08, 2001 5:12 PM
> To: Larry Wall; [EMAIL PROTECTED]
> Subject: Re: Apoc2 -  concerns : new mascot?
>
>
> Larry Wall wrote:
> > there seems to be a shortage of three-humped camels.
>
>
> At last! the unencumbered image for the mascot!  Could
> O'Reilly really claim a three-humped camel was an image of
> a camel, with a straight face?
>

RE: what I meant about hungarian notation

[David Grove]

> [...] subject to ethnic
> cleansing.  Culture wars arise spontaneously, but that should not deter
> us from enabling people to build new cultures.  [...]

Does that mean we can nuke Redmond and move on to reality in corporate IS
now?

};P

RE: what I meant about hungarian notation

[David Grove]

> Hungarian notation is any of a variety of standards for organizing
> a computer program by selecting a schema for naming your variables
> so that their type is readily available to someone familiar with
> the notation.

I used to request hungarian notation from programmers who worked for me,
until I saw the actual compliance with that request culminate in a local
variable named l_st_uliI. Of course, that's an "static unsigned int i" used
as a simple iterator in local scope. Of course, written more appropriately,
this would have just been "static unsigned int i". At that point, Hungarian
notation fell apart for me. Its strict use adds (IMO) as much confusion as
MicroSoft's redefinition of C, with thousands of typedefs representing basic
types ("LPSTR" and "HWND" come to mind as the most common).

> Just as Python is a language that enforces the common practice of
> sane indentation by making it part of the language, Perl is a
> language that enforces a dialect of hungarian notation by making
> its variable decorations an intrinsic part of the language.

False analogy, bad example, and semantic foofoo. Python's indentation is a
burden to me. It defies flexibility and places a requirement on verbosity.
The only more annoying language I know of in terms of strict structure is
VB, which places my neat colmnar comments in irregular endings at the end of
a line (can't line anything up). Readability, to me, is the ability to MAKE
it readable, not an arbitrary rule to provide (a pretense of) readability by
forcing me to put my squiggly where I don't want it to go. As for the
Hungarian thing, Perl's $%@& is a far cry from it, though I have seen
$strSomething in new programmers.

> What if, instead of cramming everything into "scalar" to the point
> where it loses its value as "a data type that magically converts
> between numeric and string, as needed," we undo the Great Perl5
> Dilution and undecorate references.

This is frightening me too. I really don't like the thought of

$i = "1.0";
$i += 0.1 if $INC;
$i .= " Foo, Inc.";

(or more specifically a one line version that converts several times for a
single statement)

becoming

my str $i = "1.0";
if($INC) {
$i.asFloat += 0.1;
}
$i.asString .= " Foo, Inc.";

We appear to be moving in that direction, trading programmer convenience
with politically correct verbosity.

>   my dog $spot;   #spot is a dog that looks like a scalar
>   #spot holds neither numeric nor string data
>   #why is spot burdened with the BASIC
>   #string identifier?

$ isn't BASIC. (Actually, ancient BASIC was var$ rather than $var.) It's a
remnant from other UNIX utilities such that

set this = "that";
print $this;

% and @ also have historical context that makes sense.

> So what I am suggesting is, Scalar as catch-all for unclassifiables
> that are neither strings nor numbers may have been a historic stopgap
> measure in perl 5 which was seen to be unworkable given the profusion of
> object types which became available in perl 6.

As long as it roughly resembles the Perl language.

Re: Apoc2 - concerns ::::: new mascot?

[Bart Lateur]

On Wed, 9 May 2001 10:24:26 -0400, David Grove wrote:

>I remember someone (whether at O'Reilly or
>not I don't remember) saying that, even if it looks like a horse but has a
>hump, it's not allowed. Or was that an alpaca with a llama...
>
>The RFC pleads for a community spirit from ORA. Barring that, it seeks a new
>symbol for the community entirely. 

Several perl ports, and at least one book, use a "shiny ball" as a
symbol.



Scroll down to the heading "Book Nickname (?)".

It took me a bit of thinking before I realized what this "shiny ball"
represents. Odd.

-- 
Bart.

Re: what I meant about hungarian notation

[John Porter]

Bart Lateur wrote:
> David L. Nicol wrote:
> >we undo the Great Perl5
> >Dilution and undecorate references.
> 
> Undecorated if for function calls and methods. And buolt-ins, of course.

No, that's the situation already.  David is proposing a change.


> So what you're really saying is that references aren't really scalars,
> but their own type. Thus they need their own prefix.

No, that does not follow.

-- 
John Porter

Re: what I meant about hungarian notation

[Simon Cozens]

On Wed, May 09, 2001 at 11:51:14AM -0400, John Porter wrote:
> Actually, % is also simply a multiplicity, differentiated only
> by the semantics of its indexing.

Bah. You should try teaching this stuff! :) 

A scalar's a thing. An array's a line of things. A hash is a bag of
pairs of things.

All different.

-- 
About the use of language: it is impossible to sharpen a pencil with a blunt
ax.  It is equally vain to try to do it with ten blunt axes instead.
-- Edsger Dijkstra

Re: what I meant about hungarian notation

[Simon Cozens]

On Wed, May 09, 2001 at 02:04:40PM -0400, John Porter wrote:
> Simon Cozens wrote:
> > A scalar's a thing. 
> Just as the index into a multiplicity is a thing.

Indeed, hashes have scalar keys. Did you not realise that I conveyed
the same information in amazingly less confusing terminology?

Again, you oughta teach this stuff. :)

-- 
Jenkinson's Law:
It won't work.

Re: what I meant about hungarian notation

[Dan Sugalski]

At 04:02 PM 5/9/2001 +0200, Bart Lateur wrote:
>What he is proposing is that Perl6 would have a kind of variable that
>doesn't have a prefix. That isn't perlish IMO.

Sure it is. DEC BASIC let you do that (drop prefixes on variables declared 
with types) and stealing from other languages is very perlish... :)


Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: what I meant about hungarian notation

[Michael G Schwern]

On Tue, May 08, 2001 at 08:21:10PM -0500, David L. Nicol wrote:
> What if, instead of cramming everything into "scalar" to the point
> where it loses its value as "a data type that magically converts
> between numeric and string, as needed," we undo the Great Perl5
> Dilution and undecorate references.

There are two very important reasons why $%@ is more than just YA
Hungarian Notation.  I believe Abigail pointed this out to me some
time ago.

The first, string interpolation.  $ lets Perl be fairly unique in
having a simple way to interpolate variables in strings.  Its a fairly
clear distinction between a bare word and a variable.

With the idea of interpolating method calls in strings on the table,
it now becomes rather important to have that $ on objects.

print "The $animal.name says: $animal.sound\n";

Of course, we could disambiguate by requiring the () as class methods
will...

print "The animal.name() says: animal.sound()\n";

But that leads to the second Very Important Reason.  Distinguishing
between object method and class methods.  In the above example, it is
not clear if you're calling the method 'name' on the class 'animal' or
on the object 'animal'.  

The inevitable clash will happen where a variable name will match that
of a class name and no simple rule can solve it.  Object methods
cannot have precedence over class methods else there becomes no way no
call that class method.

I'm sure some set of special, optional disambiguating syntax (similar
to ${var}) could be dragged in, but it seems like you're just trading
one bit of inconsistency for another.

-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
If you have to shoot, shoot!  Don't talk.
-- Tuco, "The Good, The Bad And The Ugly"

Re: what I meant about hungarian notation

[John Porter]

David Grove wrote:
> $ is a singularity, @ is a multiplicity, and % is a multiplicity of pairs
> with likely offspring as a result. ;-)

Actually, % is also simply a multiplicity, differentiated only
by the semantics of its indexing.

Which is why I argued, some time back, in favor of conflating
arrays and hashes.

-- 
John Porter

Re: PDD: Conventions and Guidelines for Perl Source Code

[Dan Sugalski]

At 09:36 PM 5/9/2001 -0400, Benjamin Sugars wrote:
>On Wed, 9 May 2001, Dan Sugalski wrote:
>
> > At 09:33 AM 5/9/2001 -0700, Larry Wall wrote:
> >
> > >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)
>
>But isn't that the whole point of macros?  Who wants to see the same 2K of
>code at the top of every function?

No, that's not the point of macros. When you find you have 5, or 10, or 20 
levels of substitution, it means you have a real problem somewhere. Macros 
should be simple. Fancy macros, or lots of little nested macros, show a 
lack of thought about the long term. It also contributes really badly to 
comprehending the code, and it gets in the way of stepping through 
intelligibly with a source-level debugger.

More importantly, if you have the same 2K of code at the top of every 
function (or in this case, scattered throughout a bunch of different 
functions) it means you really, *really* ought to be yanking it out into a 
separate function. Perl's main program is rather bigger than it probably 
ought to be because of this. (And yes, compilers can do some better 
optimization because of it, and can abstract things out automagically to 
some extent, but there's nothing to be gained from polluting the I cache 
with what's essentially eight or ten copies of the same code)

It's one of the signs of perl 5's core decay. I don't think it was nearly 
this bad when it started.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: PDD: Conventions and Guidelines for Perl Source Code

[Jarkko Hietaniemi]

> No, that's not the point of macros. When you find you have 5, or 10, or 20 
> levels of substitution, it means you have a real problem somewhere. Macros 
> should be simple. Fancy macros, or lots of little nested macros, show a 
> lack of thought about the long term. It also contributes really badly to 
> comprehending the code, and it gets in the way of stepping through 
> intelligibly with a source-level debugger.

I would say 'getting in the way' is putting a friendly face on it.
Nothing is what it looks like, starting from most of the function
names.

A quick test on pp.c shows that the code expands about twice the size
(this *without* the #include preludes, which includes also the system
headers, which wouldn't be that fair a comparison, but in case someone
wants a figure for that, the factor with those is 3.)

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: PDD: Conventions and Guidelines for Perl Source Code

[Benjamin Sugars]

On Wed, 9 May 2001, Dan Sugalski wrote:

> At 09:33 AM 5/9/2001 -0700, Larry Wall wrote:
> 
> >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)

But isn't that the whole point of macros?  Who wants to see the same 2K of
code at the top of every function?

Cheers,
-Ben

-- 
Benjamin Sugars <[EMAIL PROTECTED]>

RE: what I meant about hungarian notation

[Hillary]

>Does that mean we can nuke Redmond and move on to reality in corporate IS
>now?

That must never happen. It can be stopped. It must be stopped. It will be 
stopped.
(except for the Redmond part, which I suspect might be a bit hard on 
*their* eyes)


Hillary 

"You're nothing if not dramatic."



--

Re: what I meant about hungarian notation

[Hillary]

>I happen to like $ and @.  They're not going away in standard Perl as
>long as I have anything to do with it.  Nevertheless, my vision for Perl
>is that it enable people to do what *they* want, not what I want.
>
>Larry

If only that were true...But it isn't true. It was never true. And you 
knew that
it wasn't true when you said it. Of course, you can sit behind the 
definition
of *they*...After all, who are "they"?

New p6 programmers?
Acolytes of Perl?
ActiveState?
my ORA?
p5p?


Hillary 

"33 builds of perl6 on the wall, 33 builds of perl6..."



--