Re: Please rename 'but' to 'has'.
Everyone I've ever talked to about it agrees that defining things to be a
negative is just a bad idea. Consider:
if (gronk) do_this();
else do_that();
versus
if (not_gronk) do_that();
else do_this();
It is one of the standard refactoring tricks to replace the second one
with the first. The word has is in the positive, whereas but is a
negative, but it assigns a positive, even more confusing.
The word now would be much nicer to indicate a change if you made it
orthogonal to the has. So, use it as follows.
To assign a compile time property:
$a is now red;
To test a compile time property:
if ($a is red) {...}
To assign a runtime property:
$a now has green;
Who cares if the order is reversed. Make it work both ways.
To test a runtime property:
if ($a has green) {...}
Me wrote:
I agree 'but' seems a tad odd, and I like the elegance of your
suggestion at first sight. However...
First, but is just strange. I have a thing and I want to tell you it
is
red, so I say 'but'. Huh?
banana but red;
foo but false;
According to Larry, run time properties will most often be used
to contradict a built-in or compile time property. If he is right
about the dominant case being a contradiction, 'but' works
better for me than anything else I can think of, including 'now'
(explained below).
Please rename 'but' to 'has'.
Larry, Please don't use 'but' to associate runtime properties to things. Please call it 'has'. First, but is just strange. I have a thing and I want to tell you it is red, so I say 'but'. Huh? Using 'has' makes a nice parallel with 'is' for compile time properties: What you are is determinted at compile time, what you have is determined at run time. Daniel
Re: Social Reform
Excuse me, my mistake. David Grove wrote: If you have not been following this thread, then maybe that is the reason for the confused-sounding nature of your email. I would say Simon was the one ignoring an issue and attacking a person, not Vijay. I think Vijay was the one pointing out that this person (Me) was contributing to the discussion and that a personal attack from Simon was inappropriate (If I may paraphrase you Vijay. Correct me if I'm wrong.) You read it wrong, Daniel. I was comforting Vijay, not scolding him. p
Re: Multi-dimensional arrays and relational db data
Sam Tregar wrote: Perl 6 will allow you to mutate your syntax at runtime any way you want. At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Daniel
Re: Multi-dimensional arrays and relational db data
Me wrote: I don't think it's reasonable to say I propose you change something that hasn't yet been defined. Rather, it is precisely because you haven't yet defined the MD array syntax that I thought it worth at least considering how it parallels db data BEFORE you define it. Considering how something will be used is often a good idea. What syntax do you propose as being SQL-friendly? This is a sure way to find out if your syntax looks strange for other purposes as well. Daniel
Re: Multi-dimensional arrays and relational db data
Simon Cozens wrote: scream This is the kind of thing that can be dealt with perfectly satisfactorily with external modules; ergo, it does NOT need to be in the core. Ergo, it probably *does* *not* *need* *discussing* *here*. Much of the discussion on this list seems to concern what will be the syntax for expressing common semantics, such as array references or properties, to name a few recent ones. This thread seems to be another one such: what will be the default syntax for multidimensional arrays and how will that syntax hamper or encourage mapping it to SQL semantics. You're (that's to say, the person at self-reference.com who is not prepared to reveal their real name) exhibiting a common trait amongst perl6-language people, and that's to concentrate on a specific application *of* the language, and then from there making the bizarre leap of logic to believing that it needs to be *in* the language. I think his point was simply that you should keep this example in mind as you design the language. While one may build a general tool or product, people invariably fall on their face if they don't keep in mind the use or customer of the tool or product as they build it. This is hugely bogus and leads very quickly to second system effect, as the RFC process has shown us. Don't do it. Focus on the bigger picture instead. Good language design starts when you stop thinking I want this and this and this and start thinking how can we solve all these problems in one generalized way? Examples of successful people in the field of theoretical work point to the conclusion that the only way to achieve good abstractions is to 1 - start with lots of examples, work them out, and then 2 - try to find what they had in common and thereby generalize from them. Halmos' answer to how to learn mathematics: examples. Feynman's answer to how to do physics: examples. More than any other language I've ever seen, Perl seems to be designed by making sure that the most common 2 000 things someone has ever needed a computer to do real quick are expressible in the least amount of typing. While this leads to the funny car of programming languages, its a pretty useful funny car. Screaming at people however, is not terribly funny. But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here. Right? Somehow this comment seems to apply to all of us on this list, including you. How dare we to think for ourselves! Don't you need a license for that? /scream
Re: suggested properties of operator results
Dave Storrs wrote: 2) This feature would be very prone to abuse (makes it easier to obfuscate code), Whoa! Never thought I'd hear that! And computed function calls/adding things to the namespace at runtime/rearranging the inheritance tree at runtime aren't very prone to abuse !? :-) but that isn't a reason to disqualify something either. Clearly hasn't been so far anyway. Why stop now? :-) Chris's proposed feature seems much less prone to abuse than many others. I myself have wanted this feature, but never thought to ask for it. Thanks Chris. Not clear on how it should be actually implemented though. Daniel
Re: Multi-dimensional arrays and relational db data
Dan Sugalski wrote: At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote: On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote: At *runtime*? You won't need computed gotos or eval anymore. You just have one block of generic-looking code and you change what the syntax means before it executes. Three routines in one! Before? Bah, woosy. *AS* it executes. Hah! Wimp. After it executes, retroactively. I was trying to remain well-defined. I'm sure its possible if you can modifiy it *as* it executes, and certainly possible if you can modify it *after* it executes, to define semantics that have *no* value at all. For example, the going back in time and preventing your grandparents from having sex situation. Daniel
Re: Social Reform
If you have not been following this thread, then maybe that is the reason for the confused-sounding nature of your email. I would say Simon was the one ignoring an issue and attacking a person, not Vijay. I think Vijay was the one pointing out that this person (Me) was contributing to the discussion and that a personal attack from Simon was inappropriate (If I may paraphrase you Vijay. Correct me if I'm wrong.) Me, it would help if you would use a name, even if its not your real one. Daniel David Grove wrote: Previously, on St. Elsewhere... Simon(e) writes... But of course, I'm sure you already know what makes good language design, because otherwise you wouldn't be mouthing off in here... Why is it that Me is *mouthing off*, but you're not? Why is that? What makes you so *special*? The fact you wrote a Perl book?! A book with more typographical errors than it has pages? *Zut!* Actually, Simon's not that bad. We don't always get along, and sometimes disgree less than quietly, but he generally makes sense. I HAVE NOT followed this thread, so I'm only talking in generalities. When trouble strikes, the type you're talking about, within a Perl forum, it has been my experience that it has the appearance of ignoring an issue and attacking a person regardless of what that person said. The more true the person's statements, the more aggressively people, specifically referring to Jan Dubois and Tom Christiansen in my own personal experience, attack the person with complete and utter nonsense, usually personal, usually untrue, apparently in order to avoid having to answer to anything or anyone. I have seen these attacks come in such a way as to specifically shut a person up by provoking him to wrath, then pointing out that he is impossible to have a discussion with... and quiet resumes with the issues still in place. This was a huge problem in the Perl 5 Porters, and it has recently begun coming into the Perl 6 groups. This is why I've been distancing myself from this group, including your previous call to arms. We will achieve social reform only by refusing to conduct ourselves in this manner, and without social reform, Perl 6 may as well not exist for all the good it does us as a community. Sure, it gives some overbrained geeks a chance to play around with language design for a while, but that's about it. And, frankly, I think Simon's been a bit nicer since his book came out. I'm just happy that it's red and doesn't have a trademarked animal on the front. ;-) Me may be s/wrong/clueless/... but I don't think any one of you has actually understood what he/she is talking about. Me is at least one level of abstraction higher than all of the rebuttals that have been fired back in this thread. HOWEVER, (again, not reading OR caring about this thread), my first reponse to me since his initial barrage a couple of months ago was that he had no good intention. He(?) has since changed his attitude somewhat, but that initial impression may be getting in the way for him. Right or wrong, Me or *you* for that matter...has the same right to post to this list...Otherwise, it should be a private list, perhaps: Unfortunately, if we keep going in the way we're going, this will eventually be a semi-private list the same what that P5P became one in order to keep from having to take responsibility for their own actions or lack thereof. This coin has two sides, Vijay. Larry Wall, Damian and the Acolytes of Doom debating Perl6 This particular acolyte (the writer of this email - I would say 'me' but that would make no sense in this context) just calls 'em as he sees 'em, nothing to hide, no book rights or contracts to protect, no financial reason to speak any way other than truth as best I know it. Just how much $foo can dance on the head of a dot operator Is that you really want? Why can't we (cough...) just get along? Think about it (for a change...). I read somewhere about the different stages of an online group. I believe it was referring to IRC channels or newsgroups, but this applies here as well. It describes that at first there is a lot of public interest because people discuss without being told to shut up. They address problems, and discuss things openly. In a later stage (there are several stages, but I forget what they all are), ego, conceit, and bad attitude creep in. You can see such attitudes on the P5P, EFNet #linux, and a few other places where people have gotten stuck in this trap. The final stage, which I believe that EFNet #perl has begun to achieve to some degree, and which we must strive to achieve, is an equilibrium. (Actually it forks three ways: a) equilibrium, b) dispersal to obliviion, or c) just plain stuck at the middle stage.) That middle stage is unfortunate, but it must come in order to advance beyond it, according to my reading. I'm not concerned about this or that butthead for the time
Re: Embrace polymorphic builtins, for they are cool.
So, you want method overloading, I take it? It is a very nice feature and I've used it often in another language. Well, you basically can't have it unless you have type checking of the arguments. And the more strong the type checking, the less dangerous and the more effective the method overloading, since the method signatures get more specific. Others on this list say that strong typing cramps their style and restricts their free-form-dom while writing code. I posit that restrictions can lead to *more* freedom, not less, since there is more you can rely on. Consider the beauty of a fast and complex Irish ceili dance and how one clumsy beginner can easily break someone else's ankle, and you see that the very strict rules of that dance are necessary for the freedom to dance it without getting hurt. No rules lead to high school kids lean against one another and grope in the dark, which is only euphemistically called dance. Programming is not so dissimilar. I think you have brought up another example where the lack of strong enforcement of rules reduces freedom by preventing a nice feature. Daniel David L. Nicol wrote: Coming to Perl 5 from a C++ background, I was greatly disappointed, Multiple dispatch based on argument type, gentlemen. C++ has it, and C++ programmers miss it when writing in other languages. Few other languages dare to include argument types into the symbolic identifiers for their code entry points. In the land of More Than One Way, it is surprising that this important way -- the mechanism behind, for example, the double-angle-bracket C++ streams library output syntax -- early-binding multiple dispatch based on known argument type -- is missing. -- David Nicol 816.235.1187 Signature closed for repaving
Re: Multi-dimensional arrays and relational db data
I think you could only delay function calls automatically like this if you could ensure that they are truely functional. That is, their output must depend only on the arugments given and must have no mutation side-effects. It seems to me that this is hard to guarantee in Perl, even for the compiler. David L. Nicol wrote: [EMAIL PROTECTED] wrote: You may wish to read this thread about lazy arrays and object persistence to get an idea of what you're getting into. http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/ Taking lazy as far as we can, has anyone been thinking about a compilation mode in which all expensive accesses get deferred until there is a decision to be made? I know some functional languages (and Algol 68?) do this, when they can -- just stack up Things To Do until an output or a decision is required, then figure out just what is needed to generate or make the output/decision. How would this work in perl? We'd have to stop relying on side effects and well defined short-circuiting, for one -- or would we?
Re: Properties and stricture
This is similar to the solution they use in Java. You have an interface, which is compile time checked. Then, when you load a class at runtime, you check at load time that it satisfies the interface. You either get an exception right then, or you're fine. Daniel Michael G Schwern wrote: Ok, I've realized a few things. 1) There's two sorts of type-checking going on here. Compile-time and run-time. 2) Run-time type checking is fairly easy and imposes few limitations. In fact, you can even do it now through ad hockery. 3) Compile-time type checking is a bit harder. Any module/class which wishes to be compile-time checked must not have its *signature* altered at run-time. By signature I mean the methods, functions, global variables and inheritence tree of a strict class must be defined at compile time. All the external stuff. The internals can change at any time. This means you can still AUTOLOAD, so long as the function signature is defined beforehand. But you can't use AUTOLOAD to define brand new methods of the strict class. eval STRING still works, just so long as it doesn't modify a strict class. It can call methods of a strict class, and this is all checked at the eval's compile-time. Dynamic method calls ($obj-$method()) works, it will be run-time checked. Subroutine refs, same thing. Symbol table manipulation will work as long as your mucking about doesn't alter the strict class's signature. ie. you can shove a code ref onto the symbol table as long as a stub for that method was defined at compile time. Automatic method generation will work, but only for those known at compile-time. Which is fine. So mod_perl, Apache::Registry, AutoLoader, Class::Accessor, Exporter, Template Toolkit can all still work, with a bit of reworking. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One My feet hurt... with destiny! http://sluggy.com/d/010204.html
Re: Properties and stricture
I would like to suggest that this is one of the major advantages that Java has over Perl. Getting things to work quickly in Perl is great. I like that very much about Perl. But in the end, I'm most concerned that my code is correct. Having the compiler check everything it can possibly check for me is really a requirement for that. You shouldn't find out at run time that you fell out of some part of a complicated data structure. This is one of the major problems with LISP (besides other things, like being hard to read.) With Java, if you build a huge complex data structure, at *compile* time you know that none of your complex manipulations of it fall out, you didn't get confused and ask for the foo member of a bar when only gronk's have a foo. Compile time type checking of method signatures is really helpful as well. It got to the point in Java that I would sometimes check in my code without even testing it I was so sure it was correct. I can't imagine ever saying that about Perl. I would like to be able to use Perl for serious large-scale industrial-strength object-oriented projects, but the lack of strong compile-time type checking really prevents it, unfortunately. Larry, if you're out there, I would say this is *the* major thing you could fix in Perl 6, if I may be so bold. Maybe you could allow people to progressively turn on more and more checking, so you could develop things in the Perl we have now, but after you were done turning on all the checking, it would be as strict as Java. In fact, make it better than Java, why not? Daniel P.S. I'm really not interested in any flames about Java, LISP, etc. Comparative criticisms across languages are a major way to get ideas for new improvements, which is the point of this list, as far as I can tell. [EMAIL PROTECTED] wrote: On Mon, Jun 04, 2001 at 06:49:28PM -0500, Me wrote: Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? Should there be a strict mode that warns if a method name matches a built in property name? Could have one that requires all inheritance and variable declarations occur at compile-time, but that will only effect your current scope. Won't help against classes you inherit from doing run-time things. And then there's autoloading... There's also the problem of knowing at compile time what class/type $foo is. Don't know what's going on with that just yet, do we? So I'd say no, Perl can't know at compile-time if your method is declared or not. Only in certain restricted cases, such as if you don't inherit from anything, or if *all* your parent classes are declared strictly.
Re: Properties and stricture
I can't imagine any way in which one can consider Perl typing to be strong.
When you know the type of a variable, you are supposed to have confidence that
when you see a statement
a - lexically locally (without looking around elsewhere) and
b - at compile time
you know exactly what the statement means.
1 - A scalar that has been assigned a string value reacts differently than a
scalar that has been assigned a numerical value to operations like (bitwise
and) and ++ (autoincrement). Even worse, a scalar can be a reference to an array
or a hash or an object and this is only checked at runtime.
2 - You can't make a user defined type, like classes in Java, that are compile
time checked.
There are many other examples.
Daniel
John Porter wrote:
Perl has strong typing; it just has a different notion of
what a type is. The types in Perl are SCALAR, ARRAY,
HASH, CODE, and a few others. Watch:
% perl -e 'sub foo(\@){} foo %h'
Type of arg 1 to main::foo must be array (not hash deref) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
--
John Porter
Anything essential is invisible to the eyes.
Re: Properties and stricture
Michael G Schwern wrote:
On Tue, Jun 05, 2001 at 08:24:31AM -0700, Daniel S. Wilkerson wrote:
But in the end, I'm most concerned that my code is correct. Having
the compiler check everything it can possibly check for me is really
a requirement for that. Compile time type checking of method
signatures is really helpful as well.
What you count as Java's greatest strength, I count as Java's greatest
weakness. You have to remove *alot* of language features to get down
to the point where its predictable at compile time.
You only remove these features if you turn on the strict-type-checking
mode, as someone else and I suggested.
Having compile time checking is just asking that the sentences in your
program make sense at a certain basic level before you run it. I cannot
imagine running an enterprise critical application where this has not been
checked. You are just hopeing with your fingers crossed behind your back
that every combination of things that will occur during runtime was found
during testing.
Here is a major point: Compile time checking is
a - syntactic, and
b - local.
You really can finish checking everything, if the type information is there.
In runtime checking, there are non-local dynamic things that can happen. You
can't possibly check them all. Some subtle bug in one part of your program
messes up some datastructure, which only fails when some other completely
unrelated thing is run a day later in some other part of your program. For a
sufficently large program, you can never check all of these combinations.
No subroutine refs. No dynamic inheritance. No autoloading. No
dynamic method calls. No symbol table manipulation. No eval. No
automatic method generation. (That's off the top of my head).
You don't loose all of these. Java has interfaces, and then any class, even
loaded at compile time, that satisfies an interface is allowed to be used in
its place. This is as good as subroutine refs (and in general object refs)
that are checked at compile time, but where the implementation shows up at
run time.
Dynamic inheritance, is that messing with the inheritance tree at runtime?
I've never found a need for that. I think a lot of these features are just
bad habits that people may use but they don't realize that they don't really
need (like computd gotos). I've never used that, if I'm understanding you.
Java allows you to load classes at runtime. The interface / implementation
matching is checked then. No, you can't do many of the tricks that you can
in Perl, like having autoload implement methods for you that don't really
exist lexically, etc. Again, this would only not be allowed in
strict-type-checking. So, you give it up only if you want to.
Not sure what a dynamic method call is. Virtual method calls, perhaps? Java
has these.
Symbol table manipulation is for me another computed goto something I don't
think I'll ever want. Again, you only give it up in the special mode.
No eval of strings, you mean. eval of blocks is fine: eval {}; if ($@) {
etc.}. Eval of strings seems like a very local thing that I would rarely
want to eval large chunks of code in. Perhaps it could throw a type
checking failed exception that you could catch outside the eval.
Automatic method generation. Again, never found the need, and you only give
it up if you want to.
Every class in the hierarchy has to be defined and loaded completely
at compile time (well, at least their method signatures) and defined
strictly. If there's a class which isn't strictly defined anywhere in
your hierarchy, no go.
Yes, that's the point.
Also, since you're doing so much more work at compile time, any
strictly typed code will probably have to be pre-compiled or else be
sluggish to startup (this is just a guess).
Again, for large applications, one expects them to be pre-compiled.
An optional strict typing system would be nice, but I just want you to
be aware how difficult it will be to do right, and what you give up by
using it. This isn't just a let's toss this in sort of feature.
Yes, its not easy to do right, and it is very helpful. Certainly worth it in
my opinion.
It got to the point in Java that I would sometimes check in my code
without even testing it I was so sure it was correct. I can't
imagine ever saying that about Perl.
I can't imagine ever saying that about any language! Type checking is
nice, but its just one class of error-checking. Doesn't do squat for
basic logic errors, for example.
No, it does. Just as people have more accidents when talking on their cell
phones while driving, even if the cell phone is mounted on the dashboard and
their hands are free, the more you have distracting your attention, the more
likely you are to make other mistakes. Human attention is the ultimate
precious resource.
By relieving the brain of all unnecessary work, a good notation sets it free
to concentrate on more advanced problems
Re: Properties and stricture
I would like to see some sort of use really_strict pragma which would disable at compile time the kinds of things you mentioned: Yes, the point is to make this possible, not required. I thought Perl was supposed to make hard things possible. This is easy in Java and its not even possible in Perl. No subroutine refs. No dynamic inheritance. No autoloading. No dynamic method calls. No symbol table manipulation. No eval. No automatic method generation. (That's off the top of my head). Of those, only subroutine refs and automatic method generation look like must-haves for major projects, which are willing to surrender some of the cute stuff in return for stability. Subroutine refs are fine. Again, Java does them with interfaces. Someone please tell me what automatic method generation is exactly. Daniel
Re: Properties and stricture
If you call a method in Java, you can see right there which method you are calling. You can then lexically follow the inheritance tree and find out exactly what code really is called, what its signature is, and what it returns. Nothing dynamic is involved. One might ask for other featues, but I consider looking at the code and 1 - knowing what other code it is going to call, or 2 - whether that class really has that member or not, etc. at compile time to be a minimum reqirement of any typing I would call strong. Daniel John Porter wrote: Daniel S. Wilkerson wrote: I can't imagine any way in which one can consider Perl typing to be strong. When you know the type of a variable, you are supposed to have confidence that when you see a statement a - lexically locally (without looking around elsewhere) and b - at compile time you know exactly what the statement means. No, that is not strong typing. That is static typing. -- John Porter
Re: Properties and stricture
Thank you, that's what I thought it might be. This can be done at compile time with a two-stage compilation. The first one writes the code that the second compiles. Then the checking can be done during the second stage. Daniel Michael G Schwern wrote: On Tue, Jun 05, 2001 at 01:42:38PM -0700, Daniel S. Wilkerson wrote: Someone please tell me what automatic method generation is exactly. Its the generation of large numbers of similar methods which would otherwise be really tedious to write out by hand, such as accessor methods. Without this, object-oriented programming would be hand-cramping tedium (or an elaborate exercise in editor macros). Its also very useful for generating complete sub-classes on the fly. Class::Accessor and Class::MethodMaker are two modules which I can think of off the top of my head that do this in Perl. Class::DBI absolutely depends on it. Java trips rather badly on this technique. For some elaboration... http://www.pobox.com/~schwern/papers/Why_I_Am_Not_A_Java_Programmer/why.pod in particular the section entitled No dynamic method generation For a really elaborate elaboration... http://www.pobox.com/~schwern/papers/Closures_and_Accessors/Closures_and_Automated_Accessors.txt -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm not actually Kevin Lenzo, but I play him on TV.
Re: Properties and stricture
John Porter wrote: Daniel S. Wilkerson wrote: It is doubtful we shall have compilers that can tell you for example, that you used the wrong algorithm. Right. I think that's what Schwern was getting at, when he said Type checking is nice, but its just one class of error-checking. The Halting Problem demonstrates that you can never automatically check for all bugs, since you can't even check if a program will halt or not. But, so what? The more bugs you find automatically, the better. And it may explain why programs written in Perl -- dynamic, weakly-typed though it be -- are at least no more buggy than programs written in low-level languages. It would be interesting for someone to measure that, however I doubt that it is so. Its true that any language can be abused. But in certain languages, when you really try to tighten things down and bullet proof your code, you just can't. But I think we've strayed into the topic of advocacy. This is a language design form, and Perl explicitly draws features from other languages. All the books brag about that in the introduction. Therefore, I'm suggesting drawing a feature from one more language. So, I think we are right on the mark in this discussion. Daniel
Re: Exegesis2 and the is keyword
Please forgive the naiveté of this question. 1 - If Perl6 is going to have multiple back-ends, rather like the cross-compilation feature of gcc, Perl6 won't be a specific virtual machine or back-end. (As Perl5 is now, and, say, Java has as a fundamental part of its design.) 2 - If Perl6 is going to have multiple front-ends, rather like ... nothing I can think of at the moment, then Perl6 won't be a syntax, something you can show to people. (Abit it may have a preferred embodiment in the similar-to-Perl5-syntax that I see people posting here.) Therefore, if it isn't a back-end and it isn't a front-end, what is it?! Perl6 seems to be a nothing sandwich. Not that this is bad, Zen is this way. Can someone say what it is? Daniel Wilkerson
Re: properties
Damian Conway wrote:
You may also be wondering what happens if a variable and the value it
contains both have a property of the same name. The answer is that we
always get back the variable's property in preference to the value's:
my $var is Purpose(var demo) = 1 is Purpose(val demo);
print $var.Purpose; # prints var demo, not val demo
To be sure of getting the value's property instead, we simply Ievaluate
the variable first:
print (+$var).Purpose; # prints val demo, not var demo
I would like to respectfully point out that the above-proposed semantics is a kind
of maintainence-action-at-a-distance. Suppose I first write a program where $var
has no properties, but at some point the value has the property Purpose, which I
refer to as $var.Purpose . Then, much later, the variable $var is changed (at the
top of the program) to have the property Purpose. $var.Purpose now means something
completely different, namely the variable's property, not the value's. Now, since
I didn't know that when I wrote it the first time, and since my program worked and
now doesn't, this is a long-range dependency bug, or
maintainence-action-at-a-distance. This could easily happen if the value comes
from one program, and $var is in another, written and maintained by two different
people (Unless I mis-understand how properties propagate along with values into and
out of function calls. Do they?)
Lets suppose that I program defensively and I want to always guarantee that I'm
always getting the value's property and not the variable's. Then I will always
write (+$var).Purpose. First, I think it can be argued that this is much uglier
than the $var-{value} syntax that we used to use (under more restricted
circumstances). Second, properties of a variable can be thought of as part of its
type. Most programming languages get along fine never allowing a type to change
while values change often. Such a similar syntax for such different meaning seems
odd.
Thus, I would like to suggest a more simple solution: use different syntax for the
different semantics. Perhaps . for value properties and has for variable
properties. This syntax would also allow the verb has to have a *declarative*
meaning, rather than attempting to change it to an *imperative* as I hear people
doing. That is, $var has Purpose would have an ==-like meaning, not an
=-like meaning. Perhaps the reader will recall that in English, let have is an
imperative, whereas has is a declarative.
Epilogue: I notice that it was rather a bit of effort to write the above paragraphs
and keep my English straight as to whether I was talking about the properties of
the variable $var or of the value of $var. I submit that the fact that it is
difficult to talk clearly about this should be a red flag. Mixing program and data
as we are (also called level-crossing) is very powerful, but making it so
difficult to syntactically disambiguate between them is a recipe for debugging
pain.
Your constructive comments are welcome.
Daniel Wilkerson
