Re: overloading the variable declaration process
On Sun, Feb 05, 2006 at 07:26:09PM -0800, Darren Duncan wrote:
: Part way through writing this, I had a brief chat on #perl6 with
: stevan (and apparently the meta-model is still quite in flux) and he
: said my question was related to Larry's class but undef idea, and
: that Larry should talk more about the subject.
Aside from the fact that it's not a class, and not necessarily undef,
class but undef is a good name for it. :-)
I've been calling them prototype objects lately for lack of a
better word. To me, the Real Class is the object instance hiding
behind .meta. But when you say bare Foo you actually naming a
generic object of the type ^Foo, which I see currently as shorthand
for Foo.meta, and which any object that does Foo can get at if it
needs metadata, including the Foo object itself. In short,
Foo.does('Foo')
This is mostly motivated by linguistics rather than computer science,
insofar as types/classes/roles in natural language are normally
represented by generic objects rather than meta objects. When I
ask in English:
Can a dog bark?
that's equivalent to asking in Perl 6:
Dog.can('bark')
The Dog there is in the same type category as $dog, and specifically
is *not* in the same type category as the class that is managing
the logic behind the scenes. As a user, I'm thinking about doggy
objects, not classy objects. It's the very same kind of linguistic
reasoning that gives us given rather than switch, and when rather
than case. People want to think about their problem's objects,
not the language implementor's representations of those objects.
Now in the case of .can, we do eventually end up asking the metaobject
whether this objects supports the .bark method, but the point is that
the user doesn't have to keep track of how many metas there are.
Or looking at it the other way, any object can stand in for all its
meta objects. This is how we think (I think).
Psycholinguistially, every dog object in your brain is really a
kind of partially instantiated object that is slowly being filled in
with knowledge about the real world counterpart to your mental model.
Your mental model is never perfect.
The trend in the world today is away from monolithic computers that
either know everything or nothing, and toward programs that have
to work with imperfect knowledge that is generated or downloaded on
the fly. So I think the modeling view of reality is the sweet spot
for the future, and languages that have to know everything before
they think they know anything are doomed to fail. Well, not fail,
but have restricted ecological niches, such as rocket science.
(And maybe not even there, as machines get more autonomous.)
So the basic answer to you question is, I think, yes. If Dog chooses
to always return true for .defined, then (in Haskell terms) it's more
like a Just type than a Maybe type. Perl 6's objects like to be Maybe
types by default, but you can override it. (I'm using the Haskell
terms loosely here, of course.) But the very concept of definedness
is getting mushy in Perl 6. What we need is more concepts of the
form Is this *sufficiently* defined for what I want to do with it?
That's why I proposed defined according to a particular role as
one way to ask that sort of question.
Hope this helps.
Larry
Re: Is S05 correct?
On Mon, Feb 06, 2006 at 07:26:44AM +1100, Andrew Savige wrote: : --- Larry Wall wrote: : Yes, that's a typo. : : Which reminds me, I noticed some Synopsis typos as follows. Fixed, thanks! Larry
Re: overloading the variable declaration process
At 3:02 PM +0800 2/6/06, Audrey Tang wrote: On 2/6/06, Darren Duncan [EMAIL PROTECTED] wrote: Speaking briefly, I would like it if Perl 6 provided a way for a class (or role, or meta-class, etc) to declare that all variables declared to be of that type are automatically/implicitly set to a particular value at declaration time, so that they are not undefined if the programmer using them doesn't explicitly set a value. If so, your use case can be satisfied by declaring that ::NumType (the class object) numifies to 0, and ::StrType stringifies to , via the coerceas form. That could be fine for some situations, but I was looking for a more generic solution for: my FooType $foo; # acts like we said .= new() $foo.do_action(); Essentially, that $foo is like or is a fully instantiated object on which you can call arbitrary FooType object methods as if someone set it with new(), but where in fact the user never did this. The coercing solution won't work if the types of use are not coersions to simple data types like strings or numbers. Thank you. -- Darren Duncan
Re: Macros?
On Sun, Feb 05, 2006 at 02:32:08AM +0100, Brad Bowman wrote:
:
: Hi,
:
: I've read and reread the macro explanation but I'm still not entirely
: clear on number of things. The questions and thoughts below are based
: on my (mis)understanding.
:
: On 03/02/06 02:05, Larry Wall wrote:
: Macros are functions or operators that are called by the compiler as
: soon as their arguments are parsed (if not sooner). The syntactic
: effect of a macro declaration or importation is always lexically
: scoped, even if the name of the macro is visible elsewhere.
:
: And presumably they can be lexically unimported, or whatever the verb is
: for what no does.
Presumably. At least its grammatical effect must be unimportable, even
if the name isn't. Which we could do, since we've divorced the grammatical
effect from name visibility. Nevertheless, the easiest thing might just
be to hide the name, or rather the lexical alias of the name, if the
existence of the lexical alias is what controls the lexical scoping of
the grammatical effect.
: As with
: ordinary operators, macros may be classified by their grammatical
: category. For a given grammatical category, a default parsing rule or
: set of rules is used, but those rules that have not yet been used
: by the time the macro keyword or token is seen can be replaced by
: use of is parsed trait. (This means, for instance, that an infix
: operator can change the parse rules for its right operand but not
: its left operand.)
:
: In the absence of a signature to the contrary, a macro is called as
: if it were a method on the current match object returned from the
: grammar rule being reduced; that is, all the current parse information
: is available by treating Cself as if it were a C$/ object.
:
: Is this a :keepall match object?
: Or is the Perl6 grammar conserving by default?
: (The Syntax trees [...] are reversible suggests so)
: Or is this one of the signature to the contrary possibilities?
It feels to me like something that wants to be controlled by a very
large context, such as which debugger/IDE you're working under, if any.
Maybe that's one of those signature to the contrary things. I dunno.
: [Conjecture: alternate representations may be available if arguments
: are declared with particular AST types.]
:
: Macros may return either a string to be reparsed, or a syntax tree
: that needs no further parsing. The textual form is handy, but the
: syntax tree form is generally preferred because it allows the parser
: and debugger to give better error messages. Textual substitution
: on the other hand tends to yield error messages that are opaque to
: the user. Syntax trees are also better in general because they are
: reversible, so things like syntax highlighters can get back to the
: original language and know which parts of the derived program come
: from which parts of the user's view of the program.
:
: In aid of returning syntax tree, Perl provides a quasiquoting
: mechanism using the keyword CODE, followed by a block intended to
: represent an AST:
:
: return CODE { say $a };
:
: I guess the string form is Ceval CODE { $str }
Seems like that would bind variables differently, unless we took steps
for it not too. I was thinking that string macros would have no binding
to the macro's definition's lexical scope. But then I'm not sure what
that could desugar to.
: If CODE may enclose arbitrary source text of whatever DSL poeple invent,
: alternate braces would probably be useful. Either q()-like, HERE-doc
: or pod's C nesting style.
Any CODE-like macro could choose its own delimiter policy. Arguably we
could go with q:code or some such instead, and I considered this,
but it seemed to me that if you're parsing something that the user
is thinking of primarily as generic Perl code, it ought to look more
like a code block and less like a string.
: [Conjecture: Other keywords are possible if we have more than one
: AST type.]
:
: Ocaml and camlp4 are probably a good source of ideas for quasiquoting.
: I've only perused the documentation, has one actually used Ocaml here?
Not this one.
: See: http://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial004.html
In my copious free time... :-)
: Rather than misrepresenting Ocaml with my sketchy understanding,
: I'll just mention some possibly interesting features:
:
: Specific expander rules from the grammar can be used, :rulename ...
Our rules are all just subs in disguise, so I'm sure we could do something
similar, modulo syntactic sugar.
: They have a C - AST expander. I can imagine a SQL - AST expander
: would find some use in Perl. I don't think the same AST type is used but
: that's just a guess.
At this point I'm not so interested in specific mappings, but I'm sure
everyone will have their favorites.
: Two of the ps in p4 stand for pretty-printer,
Re: overloading the variable declaration process
On 2/6/06, Larry Wall [EMAIL PROTECTED] wrote:
This is mostly motivated by linguistics rather than computer science,
insofar as types/classes/roles in natural language are normally
represented by generic objects rather than meta objects. When I
ask in English:
Can a dog bark?
that's equivalent to asking in Perl 6:
Dog.can('bark')
That sentence is ambiguous. You can interpret it as:
Can some dog bark?
Or as:
Can every dog bark?
I think you meant the latter, however the sentence is leaning toward
the former. Can dogs bark? would be less ambiguous in that respect.
And while I'm starting to see the linguistic rationale behind this
decision, I still can't find anything concrete that this buys us.
Call me an American, but I like instant gratification.
Luke
RE: Is S05 correct?
-Original Message- From: Larry Wall [mailto:[EMAIL PROTECTED] Sent: Monday, February 06, 2006 3:03 PM To: perl6-language@perl.org Subject: Re: Is S05 correct? On Mon, Feb 06, 2006 at 07:26:44AM +1100, Andrew Savige wrote: : --- Larry Wall wrote: : Yes, that's a typo. : : Which reminds me, I noticed some Synopsis typos as follows. Fixed, thanks! This may be a stupid question, but where can I view the fixed Synopsis? When I go to http://dev.perl.org/perl6/doc/design/syn/S05.html, I see that the modification date is November 16, 2005. Is this the most up-to-date version? Joe Gottman
Re: Is S05 correct?
On Mon, Feb 06, 2006 at 08:29:54PM -0500, Joe Gottman wrote: This may be a stupid question, but where can I view the fixed Synopsis? When I go to http://dev.perl.org/perl6/doc/design/syn/S05.html, I see that the modification date is November 16, 2005. Is this the most up-to-date version? Essentially, yes. There have been a few corrections since Nov 16 to some typographical errors (for which none of the committers felt was worth updating the modification date), but nothing substantial has changed in S05 since then. Pm
Re: overloading the variable declaration process
Larry~
On 2/6/06, Larry Wall [EMAIL PROTECTED] wrote:
This is mostly motivated by linguistics rather than computer science,
insofar as types/classes/roles in natural language are normally
represented by generic objects rather than meta objects. When I
ask in English:
Can a dog bark?
that's equivalent to asking in Perl 6:
Dog.can('bark')
Or you might think of it more as a question like Can the ideal of a
dog bark? the answer to which is of course No, it doesn't exist..
Perhaps, I am just too firmly rooted in old paradigms but I think it
is very important not to conflate the representation of a thing with
the thing.
http://en.wikipedia.org/wiki/Image:MagrittePipe.jpg
Matt
--
Computer Science is merely the post-Turing Decline of Formal Systems Theory.
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Is S05 correct?
On Mon, Feb 06, 2006 at 08:29:54PM -0500, Joe Gottman wrote: This may be a stupid question, but where can I view the fixed Synopsis? I don't think it's a stupid question at all. Larry could have meant it's fixed in my working copy when he said fixed! and there would be no possibility for you to view the fixed version until he commits his changes. When I go to http://dev.perl.org/perl6/doc/design/syn/S05.html, I see that the modification date is November 16, 2005. Is this the most up-to- date version? I believe the html representations of these documents are generated directly from the pod source in the subversion repository. Though I don't know the particulars of how this happens. For S05, if you look at http://svn.perl.org/perl6/doc/trunk/design/syn/S05.pod you'll see the most up-to-date version. But, as pmichaud says, it doesn't differ substantially from what you've already seen. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
