Re: === and array-refs
On Thu, Aug 17, 2006 at 12:00:17AM -0700, Darren Duncan wrote: > As a lead-in, I should say that Synopsis 3 has a good and complete > explanation of these matters and has had it for several weeks, in my > opinion. > > Since you are wanting to compare two mutable Array, just use the eqv > operator, which will do everything you want in a terse and easy to > understand manner. I'd just like to point out that S03 is back-arsewards here - it explains === first, and then explains eqv in terms of ===. Since eqv is the familiar thing people will want most of the time, and === is the weird thing that isn't used very often, it would make far more sense to explain them the other way around (and probably confuse less people). Understanding === should not be a prerequisite for understanding eqv.
Re: multi-line comments, C macros, & Pod abuse
On Sun, Aug 20, 2006 at 10:50:31AM -1000, Joshua Hoblitt wrote:
> > #{
> >if $baz {
> >$foo.bar
> >}
> > }
> >
> > To uncomment, remove the # before the {.
>
> This is exactly the type of construct that I had in mind. A couple of
> questions. Is code inside of a #{}:
>
> - parsed and required to be syntacticly correct?
> - does it still appear in emitted code?
> - what happens when a goto tries to enter into this block
> or a nested sub is invoked?
> - will the optimizer spend time on this block?
The important question here is this one:
- when 'uncommented', is it a no-op?
Which isn't true for #{}/{}, because {} introduces new lexical
scope. It's still a pretty good idea, but it's not as good as the C
preprocessor. if (0) has the same problem. Pod doesn't. Anybody able
to think up a non-pod construct that doesn't affect the code it wraps?
(Solutions which involve complicated modules are acceptable, so long
as the usage is not complicated and there is no run-time penalty)
Re: multi-line comments, C macros, & Pod abuse
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
> >The important question here is this one:
> >
> > - when 'uncommented', is it a no-op?
> >
> >Which isn't true for #{}/{}, because {} introduces new lexical
> >scope.
> Why would you care about introducing a new lexical scope? You would
> care about that if you used a variable you declared in the commented
> code in the code below it, which is broken.
Typically because you have several versions that you want to switch
between, and you'd rather add a few characters of comment rather than
spend the time rearranging the code to use ifs or subs or
something. It's something you might do when debugging or experimenting
(especially under time pressure) - at least, that's how I use '#if 0'
in C.
Using <<'#END' (or rather, q:to'#END') is actually not that bad an
idea... it'd work in most places where #{} would give trouble. Unless
anybody has any better ideas, that could be a useful idiom to
remember.
Re: clarify: does "Dog is Mammal" load Mammal for you?
On Tue, Aug 22, 2006 at 12:37:33AM -0700, Trey Harris wrote:
> I misstated my worry here. In this case, by the same rule that "my Dog
> $foo" gets the right version because the longname is aliased to the
> shortname in the lexical scope of the use, it would work.
>
> What I'm actually concerned about is the case where the Dog CPAN
> distribution includes Poodle.pm. I think that we need Poodle.pm to be
> written like:
>
> use Dog-1.3.4-cpan:JRANDOM;
> class Poodle-1.3.4-cpan:JRANDOM is Dog { ... }
>
> If it's written:
> use Dog;
> class Poodle-1.3.4-cpan:JRANDOM is Dog { ... }
>
> then in a running Perl program that has previously loaded Dog-2.1-*,
> Poodle-1.3.4 will become a subclass of Dog-2.1, which causes any code
> using Poodle-1.3.4 to be unable to protect itself from an unforseen
> upstream dependency change.
This is precisely the problem which unix shared libraries have to face
(so yes, it's a real problem), and which is handled by a combination
of sonames and versioned symbols. It seems to me that there is some
merit in considering similar features here. The essential features
are:
- independent version labels for the interface and implementation, so
you can change the implementation while promising that the external
interface remains the same
- individual symbols can be optionally decoupled from the interface
version of the library that contains them and versioned
independently, so even though the interface version has changed from
X to Y, the linker knows that only function foo has changed; clients
that use only function bar will still find this version acceptable.
Shared libraries make this behaviour optional, with the first being
all that most people use, and the second only being used by people
writing large libraries with complex needs (like glibc).
You can get interface versions with nothing more than a stipulation
that Poodle-1.* will always have the same interface, but everybody has
to understand what this means for it to work. I'm not sure if this is
the right approach here.
It is not clear to me whether it is practical to version individual
symbols in perl6 as it currently stands, but it would appear to be
worthwhile to make sure this is possible.
I suspect that this will largely be a matter of establishing
appropriate conventions about versioning for CPAN modules.
Uncaught exceptions
What is the behaviour of an *uncaught* exception, particularly with respect to CHECK/END/LEAVE/LAST blocks, destructors, overloading of the stringify operator on exception objects, the order in which these things are executed, and the exit code of the process? (And anything else that I haven't thought of) Perl 5's behaviour in this respect is largely undocumented and doing things during exception-triggered global destruction has a habit of generating messages about attempting to free unreferenced objects, or just crashing the interpreter entirely, and I can't see anything in the synopses about it. A closely related question here: exactly how much can I assume has already been executed when writing destructors and ALAP blocks? Do I have to guard against some of my data mysteriously transmuting into undef?
Re: question - languages with set/foo as only base data type
On Sun, Nov 17, 2013 at 02:10:17PM -0800, Darren Duncan wrote: > I recall reading that at least in certain math/logic papers that a > programming language type system can be defined logically in terms > of pure sets, making it essentially self-defined without needing to > rely on external definitions of for example what a number is. Well, it's true. But there's a more natural way for programming languages. Church's theory of types defines everything using functions as the primitive. While mathematics as a field has mostly settled on set theory as its basis, type theory is equally expressive and is usually preferred in language design. > Does Haskell at least conceptually work in terms like I described? > I seem to recall reading that how it logically thinks about string > values is towards that direction. Haskell, like most vaguely modern languages with a grounding in type theory and a strict type system, is based on functions as primitives. For a thorough primer on the subject, I recommend "An Introduction to Mathematical Logic and Type Theory: To Truth Through Proof" for the theory, and Ben Pierce's spectacular "Types and Programming Languages" for the practical applications. http://gtps.math.cmu.edu/tttp.html http://www.cis.upenn.edu/~bcpierce/tapl/ Most of the newly created programming languages (and all the ones that aren't an embarrassment - Java, I'm looking at you) draw from these ideas to some extent. If you want to look at one that takes the concept out to the cutting edge of what is possible, I'd suggest Coq - not very practical, but interesting.
