Re: Design question re: function parameters

On 07/03/17 17:59, Sean McAfee wrote: > […] If I want to freely accept both numbers and strings in the manner > of > Perl 5, it looks like I must type all of my function arguments as > Cool, or omit the types altogether. […] Don't forget you can use a coercive type in parameter lists: sub po

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Dave Whipp wrote: I actually agree that your explicit definition (a simple/efficient implementation in terms of other operators) is better for prelude than my "declarative" form (which isn't really declarative, because Perl6 isn't a declarative language). My only disagreement was with your ear

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Darren Duncan wrote: I don't quite follow you. Are you saying your version of sqrt is an implicit declaration; maybe I don't understand how that differs from an explicit definition in this case? In any event, right at this moment I can't think of an answer to your question. Go ahead with wh

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Dave Whipp wrote: Darren Duncan wrote: Dave Whipp wrote: sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) { (0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 } } So do you really mean "as declarative a manner as possible"? Or would you consider this example to go beyond "possib

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Darren Duncan wrote: Dave Whipp wrote: sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) { (0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 } } So do you really mean "as declarative a manner as possible"? Or would you consider this example to go beyond "possible"? I would decl

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Dave Whipp wrote: I do agree that a prelude.pm should be written atas higher level as possible, but I would not that Perl6 is not a "declarative" language. Using the most powerful operators available (I'd like to see more of them) is about the best you can do: as soon at you start using codebl

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Darren Duncan wrote: 1. What we *should* be doing with the Prelude, like with STD.pm, is write under the assumption that the implementation is also written in Perl 6. We should write the Prelude in as declarative a manner as possible, saying *what* we want to happen rather than how, such as

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

The Prelude could be helpful for training. I've been trying to work out a logical path into Perl 6 for quite some time, not least because it's been a moving target. If there's a set of definitions that a computer can follow, humans should be able to move along that path too. -- Email and sh

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

On Thu, Jan 15, 2009 at 8:31 PM, Jon Lang wrote: > Forgive my ignorance, but what is a Prelude? > > -- > Jonathan "Dataweaver" Lang > The stuff you load (and execute) to bootstrap the language into utility on each invocation. Usually it's written in terms of the language you're trying to bootst

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Following some responses I've seen, I'll try to clarify my proposal. Basically its like this. A significant subset of Perl 6 native features, eg types and operators, native meaning they are declared and described in the Perl 6 Synopsis documents, have been implemented under Pugs by being writ

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

On Thu, Jan 15, 2009 at 8:59 PM, Jon Lang wrote: > OK, then. If I'm understanding this correctly, the problem being > raised has to do with deciding which language features to treat as > primitives and which ones to bootstrap from those primitives. The > difficulty is that different compilers p

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

On Thu, Jan 15, 2009 at 6:45 PM, Jonathan Scott Duff wrote: > On Thu, Jan 15, 2009 at 8:31 PM, Jon Lang wrote: >> >> Forgive my ignorance, but what is a Prelude? >> >> -- >> Jonathan "Dataweaver" Lang > > The stuff you load (and execute) to bootstrap the language into utility on > each invocation

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Jon Lang wrote: Forgive my ignorance, but what is a Prelude? The Prelude is a file written in Perl 6 that defines some Perl 6 built-ins. See http://perlcabal.org/svn/pugs/view/src/perl6/Prelude.pm for what AFAIK is the newest version. -- Darren Duncan

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Forgive my ignorance, but what is a Prelude? -- Jonathan "Dataweaver" Lang

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

Geoffrey Broadwell wrote: The problem with this method is that there are usually *several* ways to implement each feature in terms of some number of other features. The creators of the shared prelude are then stuck with the problem of deciding which of these to use. If their choices do not matc

Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)

On Thu, 2009-01-15 at 16:03 -0800, Darren Duncan wrote: > Patrick R. Michaud wrote (on p6c): > > On Thu, Jan 15, 2009 at 08:53:33AM +0100, Moritz Lenz wrote: > >> Another thing to keep in mind is that once we start to have a Perl 6 > >> prelude, we might decide to be nice neighbors and share it wit

Re: Design of the "code" classes

Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote: I think what the discussion is missing that there Regexes are also Callable (I think so, at least). Yes, you are right. S05 says that a named regex is an object of type Method actually. They are just another syntax for writing Rules.

Re: Design of the "code" classes

John M. Dlugosz wrote: > I wrote up a summary and some notes and posted at > . I think what the discussion is missing that there Regexes are also Callable (I think so, at least). Also I'm not sure that Routine actually isa Block, because a Block can be

[perl #56274] [PATCH] Re: design problem with :outer

Fixed by jonathan++ and chromatic++ as of r28795. Thanks! Pm

Re: design problem with :outer

On Wed, Jun 25, 2008 at 09:45:23AM -0400, Jeff Horwitz wrote: > On Wed, 25 Jun 2008, Klaas-Jan Stol wrote: > > >maybe I overlooked something, but wouldn't specifying the full outer > >subname > >(including its namespace) help? > > > >like so: > > > >.namespace ['B'] > >.sub 'inner' :outer(['A';'o

Re: design problem with :outer

On Wed, 25 Jun 2008, Klaas-Jan Stol wrote: maybe I overlooked something, but wouldn't specifying the full outer subname (including its namespace) help? like so: .namespace ['B'] .sub 'inner' :outer(['A';'outer']) ... .end instead of the proposed :lexid property. just a thought. maybe there's

Re: design problem with :outer

maybe I overlooked something, but wouldn't specifying the full outer subname (including its namespace) help? like so: .namespace ['B'] .sub 'inner' :outer(['A';'outer']) ... .end instead of the proposed :lexid property. just a thought. maybe there's something i'm overlooking or missing, but to

Re: [perl #56282] Re: [PATCH] Re: design problem with :outer

Based on discussion earlier today in #parrotsketch, here's the detailed specification for resolving outer subs using :lexid . If someone wants to fold this into pdd20 somehow (on or about line 233), that would be especially helpful. Every Parrot subroutine that serves as a lexical outer

Re: [perl #56274] [PATCH] Re: design problem with :outer

On Tue, Jun 24, 2008 at 03:43:34PM -0700, Mehmet Yavuz Selim Soyturk via RT wrote: > There is another problem with :outer. It does not let you create inner > functions dynamically. For example, I couldn't use it to compile next > ECMAScript code: > > function outer() { > var i = 0; >

Re: [perl #56274] [PATCH] Re: design problem with :outer

There is another problem with :outer. It does not let you create inner functions dynamically. For example, I couldn't use it to compile next ECMAScript code: function outer() { var i = 0; return eval("function() { return i++; }"); } Is it not possible to have an opcode tha

[perl #56274] [PATCH] Re: design problem with :outer

# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #56274] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56274 > On Mon, Jun 23, 2008 at 06:27:31PM -0500, Patrick R. Michaud wrote: > There appear

[perl #56282] Re: [PATCH] Re: design problem with :outer

# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #56282] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56282 > On Mon, Jun 23, 2008 at 09:33:43PM -0500, Patrick R. Michaud wrote: > On Mon, Jun

[perl #56284] Re: [PATCH] Re: design problem with :outer

# New Ticket Created by chromatic # Please include the string: [perl #56284] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56284 > On Monday 23 June 2008 21:56:54 Patrick R. Michaud wrote: > Alas, the patch doesn't seem t

[perl #56278] [PATCH] Re: design problem with :outer

# New Ticket Created by Bob Rogers # Please include the string: [perl #56278] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56278 > From: "Patrick R. Michaud" <[EMAIL PROTECTED]> Date: Mon, 23 Jun 2008 21:33:43 -0500

Re: [PATCH] Re: design problem with :outer

On Monday 23 June 2008 21:56:54 Patrick R. Michaud wrote: > Alas, the patch doesn't seem to hold when loading things from > precompiled bytecode -- e.g., running perl6.pbc versus perl6.pir. > > So, the patch I submitted appears to be incomplete, and > now I need to figure out how :outer is resolve

Re: [PATCH] Re: design problem with :outer

On Mon, Jun 23, 2008 at 09:33:43PM -0500, Patrick R. Michaud wrote: > On Mon, Jun 23, 2008 at 06:27:31PM -0500, Patrick R. Michaud wrote: > > There appears to be a fundamental design problem in Parrot's > > current implementation of :outer. The short summary is that > > :outer("sub_name") doesn't

[PATCH] Re: design problem with :outer

On Mon, Jun 23, 2008 at 06:27:31PM -0500, Patrick R. Michaud wrote: > There appears to be a fundamental design problem in Parrot's > current implementation of :outer. The short summary is that > :outer("sub_name") doesn't provide sufficient specificity > to accurately resolve an outer sub. > [...]

Re: Design Team Issues: Numeric Types

Mike wrote: > > >: (B) Need to know the root of the numeric types > > If it isn't obvious to everyone else, the main (only?) reason to care > about this is when checking/specifying context/args. Assume num means > a double-precision float. > > Simply put: (a) if you pass an to a function def

Re: Design Team Issues: Numeric Types

On Monday, November 18, 2002, at 04:54 PM, Larry Wall wrote: : (B) Need to know the root of the numeric types : : Option 1: : numeric (mostly abstract base class) : - num : - int : : Option 2: : : num (floating point 'num' is the base class) : -

Re: Design Team Issues: Numeric Types

On Mon, Nov 18, 2002 at 11:22:00AM -0800, Michael Lazzaro wrote: : Here are some issues we need the design team to decide. I shall presume that I can speak for the design team. :-) : (A) How shall C-like primitive types be specified, e.g. for binding : to/from C library routines, etc? : : Op

Re: Design Team Issues: Numeric Types

On Monday, November 18, 2002, at 01:33 PM, Dave Whipp wrote: my int $a is range(1000..1255) is unchecked; # auto-infer 8bit Just to clarify: I think of the latter (C) for efficient packing into arrays (e.g. a 5-bit range can be packed efficiently, even though there is no 5-bit c-type): b

Re: Design Team Issues: Numeric Types

"Michael Lazzaro" <[EMAIL PROTECTED]> wrote > (A) How shall C-like primitive types be specified, e.g. for binding > to/from C library routines, etc? > >Option 1: specify as property > > my numeric $a is ctype("unsigned long int"); # standard C type > my numeric $b is ctype("my_int32"

Re: Design, opps- govt foul up

John van V writes: > FTC = FCC (= FDA = DEA = FBI = DOJ = DOA = CIA = Ma_FIA = ...) This is so far away from being of use to the perl6-internals list, I'm surprised to see it here. Let's get back to design. Dan? Nat

Re: Design, opps- govt foul up

FTC = FCC (= FDA = DEA = FBI = DOJ = DOA = CIA = Ma_FIA = ...)

Re: Design

> Wow! You're good! Thanks, can I quote you ?? > However, the "marriage" part of your prediction is > already *mostly* true... future Python... same vein as Lisp > -- only the people who really grok Lisp can see it. > I totally disagree with your last point though. Thats ok, > Perl has staye

Re: Design

John van V wrote: > I have been predicting for a year now that perl6 will spawn another > language which will be a marriage of perl/python/scheme/sh, hopefully > enabling a billion or so humans in defiance of AOL and Microsoft. Wow! You're good! Most people were caught by surprise with the Perl

Re: Design

One more random credo I just made up: By the time you add the seventeeth argument/member/field/function to your function/struct/class/API you should start seriously suspecting that maybe your API needs a rethink. (For the first three, rethinking at five elements

Re: Design

>once you've lost it, [ simplicity, that is ] it's never >coming back How true, I'm not holding my breath for CGI.pm divesment. Simplicity to me as an integrator/admin means having set of binaries that can be recompiled, or preferably configed, into diverse implementations with uniform result

Re: Design

At 03:13 PM 11/2/00 -0700, Nathan Torkington wrote: >Dan, Jarkko, etc. How about we try to identify the big units we'll be >working on? I have a list I've been fiddling with, and an overall design framework. I've been offline for most of the week (IP connection down--if mail to me bounced, do

Re: Design

2000-11-02-17:30:56 Nathan Torkington: > Here are the things to order, in my order: > > Robustness > Portability > Maintainability > Testability > Reusability > Speed > Simplicity > Size A couple of negligible wibbles to toss in: would it make sense to separate "Simplicity" into

Re: Design

Ken Fox writes: > Nathan Torkington wrote: > > Robustness > > Portability > > Maintainability > > Testability > > Reusability > > Speed > > Simplicity > > Size > > Hey, whoa. Aren't we pre-maturely optimizing the development > process? Not in deciding priorities. These are facto

Re: Design

Nathan Torkington wrote: > Robustness > Portability > Maintainability > Testability > Reusability > Speed > Simplicity > Size Hey, whoa. Aren't we pre-maturely optimizing the development process? IMHO we're still in the day dreaming "what if" mode of development. (We don't even ha

Re: Design

> Another angle is to collect a set of mantras, design principles > if you will, something like: > > Avoid copying. > Avoid premature optimization. > Be extensible. > Be orthogonal. Orthogonal be. > Be portable. > Be scalable. Quite right. This is the standa

Re: Design

I'll just fork a few copies of myself and I'm ready to start... Another angle is to collect a set of mantras, design principles if you will, something like: Avoid copying. Avoid premature optimization. Be extensible. Be orthogonal. Orthogonal be. Be porta

Re: Design by Contract for perl internals

Michael G Schwern <[EMAIL PROTECTED]> writes: > >I wouldn't mind an optional OO contract system in the core of Perl, >but this may be a case of "why do it in core when a module will work?" I _think_ the proposal was to have design-by-contract in the perl core in the sense that contract is checked

Re: Design by Contract for perl internals

Michael wrote: > I wouldn't mind an optional OO contract system in the core of Perl, > but this may be a case of "why do it in core when a module will work?" > Since OO contracts are typically turned off in production code any > performance gains from adding it to the core wouldn't ma

Re: Design by Contract for perl internals

On Thu, Aug 17, 2000 at 01:28:29PM -0400, Chaim Frenkel wrote: > I posted this to -qa and -internal, since I was suggesting this > for the internal development of perl. Not for the user visible > pieces. My mistake. For the internals, sounds like it couldn't hurt. Though I have no idea how put

Re: Design by Contract for perl internals

I posted this to -qa and -internal, since I was suggesting this for the internal development of perl. Not for the user visible pieces. If we will be going through an intermediate language, then that language should/could/will/might support such specifications. Then under appropriate prodding will

Re: Design by Contract for perl internals

On Thu, Aug 17, 2000 at 07:03:13AM -0400, Michael G Schwern wrote: > I wouldn't mind an optional OO contract system in the core of Perl, > but this may be a case of "why do it in core when a module will work?" Isn't this rather a language issue? > Since OO contracts are typically turned off in

Re: Design by Contract for perl internals

On Sun, Aug 13, 2000 at 07:16:41PM -0400, Chaim Frenkel wrote: > What do you think of creating a mechanism for attaching pre-, post-, > invariant conditions to the internals? I'd like to point out that two modules already do this. Class::Contract which was just unleashed by Damian Conway, and inv