On Tue, Jul 10, 2001 at 01:02:18AM -0500, David L. Nicol wrote:
> > The real problem isn't [sig digs]. The real problem is how much this
> > complicates the implicit typing rules. I'm going to have to play
> > around a bit and see which way works best.
>
> I hope you're proposing that fatal err
[EMAIL PROTECTED] wrote:
>
> On Fri, Jun 29, 2001 at 09:50:55AM -0400, Dan Sugalski wrote:
> > Besides, there are languages that do this on a per-object basis all the
> > time anyway (aren't there? I think there are) in which case it makes sense
> > to yank it into the core interpreter, as it'll
> > I haven't been tricked into reading MJD's article yet, but might your
> > third option be multiple functions with parameter-type-based dispatch?
> > We can do that with perl 5, but it isn't automatic.
>
> The problem with polymorphic functions is you have to rewrite the
> function N times (wh
Michael G Schwern wrote:
> I'm going to say you need sigils for this:
>
> print "Hello, my name is $name\n";
>
> You're going to say this:
>
> print "Hello, my name is $(name)\n";
I actually prefer
print "Hello, my name is ",name,"\n";
or,
the sigil is simply optio
On Mon, Jul 09, 2001 at 10:37:47PM -0500, David L. Nicol wrote:
> Jeremy Howard wrote:
> \
> > Perl 5 didn't need templates, because there wasn't compile-time typing. But
> > with Perl 6 I want to send my compact array of integers to the same fast
> > sum() function as my compact array of floats,
On Mon, Jul 09, 2001 at 08:54:49PM -0700, Steve Fink wrote:
> User-defined types?
Haven't even thought about them yet.
> > I'm pondering this being okay:
> >
> > my Num$dec = 4.0;
> > my Int$int = $dec; # Num -> Int okay since 4.0 truncates to 4
> >
> do
>
> s%([A-Z]+)([BE])%<${\(($2 eq 'E')?'/':'')}$1>%g
>
> on that and you've almost got XML!
XML
is
much
too
verbose
.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Jarkko Hietaniemi wrote:
...
> This sounds like having also 'basic block' entry/exit opcodes. Hmmm.
>
> BLB = block begin
> BBB = basic block begin
> SE = statement end
> BBE = basic block end
> BLE = block end
>
> sub foo {
> BLB
> BBB
> my ($a, $b) = @_;
> S
On Mon, Jul 09, 2001 at 11:00:45PM -0500, David L. Nicol wrote:
> [EMAIL PROTECTED] wrote:
> Why not drop the sigil on things with declared types?
A VERY SHORT DIGRESSION INTO SIGILS
I'm going to say you need sigils for this:
print "Hello, my name is $name\n";
You're going to say this:
[EMAIL PROTECTED] wrote:
First off, I'm going to pound on one of my deceased horses a bit:
Why not drop the sigil on things with declared types?
Then $foo keeps its status as Perl's Magic Autoconverting Wondertype
and without it, we know we aren't dealing with the PMAW and we
won't make mistake
[EMAIL PROTECTED] wrote:
> Here's me thinking out loud. I'm thinking about how to avoid alot of
> explicit type casting without entering a maze of twisty typecasing
> rules, all different.
>
>
> Imagine we have a typing system where types are allowed to
> automatically cast AS LONG AS NO INFOR
Jeremy Howard wrote:
\
> Perl 5 didn't need templates, because there wasn't compile-time typing. But
> with Perl 6 I want to send my compact array of integers to the same fast
> sum() function as my compact array of floats, and not have to wait while
> perl treats them both as old generic scalars.
Buddha Buck wrote:
> True, agreed, and admitted. So why can't a general purpose programming
> language be designed with XML-based syntax? Why can't a general-purpose
> programming language be augmented with XML for internal documentation purposes?
Maybe the gcc back end could accept this new X
Matt Youell wrote:
>
> >What if you want multiple constructors with redundant code, et cetera --
> >there is flexibility.
>
> You could get that same flexibility from a mandated new(). If you don't want
> to support new, overload it so that it does nothing. Or maybe that could be
> the default b
Here's me thinking out loud. I'm thinking about how to avoid alot of
explicit type casting without entering a maze of twisty typecasing
rules, all different.
Imagine we have a typing system where types are allowed to
automatically cast AS LONG AS NO INFORMATION IS LOST.
So let's start with som
On Mon, 9 Jul 2001, Dan Brian wrote:
> "program XSLT in XML"? What does that mean?
It means roughly what "program Perl in ASCII" means.
> Have you used XSLT? Do you understand what it is and what it does? It
> makes quite a bit of sense for those performing regular conversions
> from a single
At 03:55 PM 07-09-2001 -0400, Adam Turoff wrote:
>On Mon, Jul 09, 2001 at 03:48:27PM -0400, Buddha Buck wrote:
> > Why can't a general-purpose programming language be augmented with XML for
> > internal documentation purposes?
>
>You mean like C#? :-)
I wasn't specifically referring to that; I w
On Mon, Jul 09, 2001 at 03:48:27PM -0400, Buddha Buck wrote:
> Why can't a general-purpose programming language be augmented with XML for
> internal documentation purposes?
You mean like C#? :-)
Z.
--- Dan Brian <[EMAIL PROTECTED]> wrote:
> Correct. The benefit is not as obvious as some seem to think.
> If the goal is format consistency, then what is gained by format
> consistency? It hardly means that you could translate one language
> to another, or have close interrelations between fu
At 03:07 PM 07-09-2001 -0400, Adam Turoff wrote:
>On Mon, Jul 09, 2001 at 02:36:17PM -0400, Sam Tregar wrote:
> > On Mon, 9 Jul 2001, Adam Turoff wrote:
> > > Don't laugh. It's here now. It's called XSLT. :-)
> >
> > Um, that's not what the article was talking about The proposal is to use
> >
> > Sure, program XSLT in XML. I guess that makes about as much sense as XSLT
> > is ever going to. My question is, if you think programming Perl in XML is
> > such a good idea, why not do it?
"program XSLT in XML"? What does that mean? Have you used XSLT? Do you
understand what it is and wha
On Mon, 9 Jul 2001, Adam Turoff wrote:
> Who said programming Perl in XML was a good idea?
Did you read the article I was responding to? I suggest you do.
Strangely, many people seem to believe XML is ideally suited to every
computing task known to man. This includes programming in Perl,
appar
On Mon, Jul 09, 2001 at 02:36:17PM -0400, Sam Tregar wrote:
> On Mon, 9 Jul 2001, Adam Turoff wrote:
> > Don't laugh. It's here now. It's called XSLT. :-)
>
> Um, that's not what the article was talking about The proposal is to use
> an XML syntax to program in existing "VHLL" languages, incl
Some of you may have seen the discussion going on in p5p about the
current design/implementation of SUPER:: type dispatch. Without
wishing to rehash the whole debate, the current way SUPER:: works
is based on the current package method at the time that SUPER::foo was
compiled, thus, given:
@
On Mon, 9 Jul 2001, Adam Turoff wrote:
> Don't laugh. It's here now. It's called XSLT. :-)
Um, that's not what the article was talking about The proposal is to use
an XML syntax to program in existing "VHLL" languages, including Perl.
This would supposedly allow programmers to embed drawings
On Mon, Jul 09, 2001 at 01:37:36PM -0400, Sam Tregar wrote:
> On Mon, 9 Jul 2001, ivan wrote:
>
> > http://www.ora.com/news/vhll_1299.html
>
> Fascinating article, but his point about XML source code struck my funny
> bone. I've certainly heard the argument before - most recently in Dr.
> Dobbs
On Mon, 9 Jul 2001, ivan wrote:
> http://www.ora.com/news/vhll_1299.html
Fascinating article, but his point about XML source code struck my funny
bone. I've certainly heard the argument before - most recently in Dr.
Dobbs Software Development insert.
I've got just one question: if this is such
> Well, my hope is somehow we can get types to be a bit more implicit
> than the usual mess most people are used to.
I have grave concerns about 'implicit' typing. In my experience DWIM-style
typing can lead to serious hair pulling and long debug sessions over simple
errors. Now, if you can give
28 matches
Mail list logo
