Parrot & Strong typing
Cameron Zemek
dynamic languages. I was wondering why this is the case.
Also could the Parrot VM be used effectively with strong typing
languages. I would like to at some stage try to implement a proof of
concept of a language that has strong typing. For example:
def name = new string (maxLength = 15)
name = "this name is too long" # throws an InvalidValue exception
def postcode = new integer (minValue = 0, maxValue = 9999)
postcode = -1 # throws an OutOfBoundsException
Basically, the idea is to be able to set constraints on variables, and
define new datatypes that have contraints. Also be able to set methods
that can do custom validation of the new value. The idea of the language
is for use to write database-centric applications.
Brent 'Dax' Royal-Gordon
> The FAQ mentions that the JVM and CLR (.Net VM) are not suited to
> dynamic languages. I was wondering why this is the case.
Dynamic languages have a few features in common:
- Very weak typing with lots of automatic conversion.
- Oddball control flow constructs (closures, co-routines,
continuations, and a few things that don't start with C).
- An "eval" or similar function.
The first feature isn't well-supported in the CLR or JVM, and would
probably require quite a bit of extra code to handle. The second is
at best extremely difficult to implement. The third...well,
ActiveState tried to write a Perl-to-.NET compiler; they almost
succeeded, *except* that runtime code evaluation wouldn't work.
(IIRC, anyway.)
Some languages go even farther than those basic characteristics; Perl
5, for example, has four hooks to run code at odd times (as soon as
it's parsed, once compilation is complete, immediately after execution
starts, and right before the program closes). Perl and Python at
least have object formats that don't quite fit native CLR or JVM
objects.
In general, the CLR and JVM just aren't a good fit for these languages.
> Also could the Parrot VM be used effectively with strong typing
> languages.
I expect so. Parrot's variables are represented by a structure called
a PMC, which is essentially an object with a fixed table of methods.
(It's written in preprocessed C, though, so there isn't really an
"object" involved--it's just a struct.) Those methods can do
anything, including whatever validation you want to add to them.
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
"I might be an idiot, but not a stupid one."
--c.l.p.misc (name omitted to protect the foolish)
Matt Fowles
I don't think that what you are referring to there is actually strong
typing. Strong typing is more generally concerned with detecting type
errors at compile time (as oposed to range errors at runtime). While
it would be possible to detect the errors in the example you gave at
compile time, your mention of exceptions leads me to believe that you
want runtime behavior.
Strong typing can be more clearly seen in something like haskell where
you can define a function
len [] = 0
len [ _ | A ] = 1 + len A
the compile will automatically detect that the len function has the
signature "list of * -> int" and will then issue a compile time error
if you call len "foo".
Hope that helps to clarify things,
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Richard Jolly
> Strong typing can be more clearly seen in something like haskell
Will there be haskell on parrot? How easy/hard would that be?
Just curious, Richard
Michael Walter
On Wed, 1 Dec 2004 09:33:27 -0500, Matt Fowles <uber...@gmail.com> wrote:
> Strong typing can be more clearly seen in something like haskell where
> you can define a function
>
> len [] = 0
> len [ _ | A ] = 1 + len A
Actually, in Haskell this would be:
len [] = 0
len (_:a) = 1 + len a
> the compile will automatically detect that the len function has the
> signature "list of * -> int"
In Haskell this would be:
forall a b. (Num b) => [a] -> b
(A function from a list of things to an arbitrary numeric type. That's
sexy, btw.)
> and will then issue a compile time error if you call len "foo".
As Strings in Haskell are lists of chars, this will work just fine <wink> ;-)
Confusingly yours,
Michael
Michael Walter
to c--, so maybe that has potential?
It would certainly be interesting to see how interopability is handled.
Cheers,
Michael
Matt Fowles
I should have known there would be a real Haskell fan in the room...
Thanks for the catch,
Dirkjan Ochtman
> 5, for example, has four hooks to run code at odd times (as soon as
> it's parsed, once compilation is complete, immediately after execution
> starts, and right before the program closes). Perl and Python at
> least have object formats that don't quite fit native CLR or JVM
> objects.
Actually, I think Python's type system is called strong: it doesn't
change your variable's types implicitly, you have to do it explicitly.
So by supporting Python, Parrot will at least to some extent support
strongly typed languages.
Also, the implementation of IronPython [1] shows that it's quite
possible to run some kind of Python on the CLR infrastructure.
Regards,
Manuzhai
Michael Walter
On Wed, 01 Dec 2004 11:33:33 +0100, Dirkjan Ochtman <dir...@ochtman.nl> wrote:
> Also, the implementation of IronPython [1] shows that it's quite
> possible to run some kind of Python on the CLR infrastructure.
Python is kind of easy to port over to CLR, because it has no
continuations - Closures are pretty trivial to implement via Classes,
and coroutines can be implemented by using Threads, for instance. But
continuations aren't that easy (albeit surely possible).
Cheers,
Michael
Stéphane Payrard
> Cameron Zemek <gr...@capsicumcorp.com> wrote:
> > The FAQ mentions that the JVM and CLR (.Net VM) are not suited to
> > dynamic languages. I was wondering why this is the case.
>
> Dynamic languages have a few features in common:
> - Very weak typing with lots of automatic conversion.
> - Oddball control flow constructs (closures, co-routines,
> continuations, and a few things that don't start with C).
> - An "eval" or similar function.
>
>
> Brent 'Dax' Royal-Gordon <br...@brentdax.com>
I don't think that "oddball control flow constructs" like closures are
proper to dynamic languages. For example, OCAML (another camel related
language :) relies on type inference at compile time so is by nature a
statically typed language. It supports closure and exceptions. I don't
know about continuations, coroutines.
Also, OCAML demonstrates that the existence of a run-eval-loop is
othogonal to the dynamicity of a language. Not that you said anything
to the contrary. Anyway the expression "dynamic typed language" would
be clearer than "dynamic langague".
BTW, the english translation of the French O'Reilly bool on OCAML is
freely available:
http://caml.inria.fr/oreilly-book/
--
stef
Dan Sugalski
[Yeah, I snipped the first question. It's early, and I've not had
enough coffee :)]
>Also could the Parrot VM be used effectively with strong typing languages.
Absolutely. At least some of the languages we're interested in,
specifically perl 5 and perl 6, (I'm less sure about python, ruby,
and tcl, though I'm pretty sure they are also strongly typed, at
least in some circumstances) are very strongly typed.
Parrot, on the other hand, is not going to be well-suited at all to
*static* typing, though since that's generally more a compiler thing
than a runtime thing it's less of an issue. (Though if you're going
to play well with others and the library it may be a bit of a
headache, since many of the types will be "I dunno", and we're likely
not going to do much to keep code from swapping in subs and methods
at runtime with prototypes and type guarantees that are different
from what they're replacing)
For those folks playing along at home, I'll take a bit to talk about
the difference between strong/weak typing and static/dynamic typing.
(I think I blathered on about this on my blog, but I can't be
bothered to go look it up right now :)
A *strong* type system is one that doesn't allow you to violate the
constraints you put on variables, while a *weak* type system does
allow you to do so -- it is, basically, a measure of how badly you
can lie to the compiler about the type of a variable. This is a
continuum, so you'll find languages are strong-ish or weak-ish.
C, for example, is weakly typed. That is, while you tell the system
that a variable is one thing or another (an int, or a float), you're
perfectly welcome to treat it as another type. This is *especially*
true of values you get to via pointers. For example, this snippet
(and yes, it's a bit more explicit than it needs to be. Cope, you
pedants :):
char foo[4] = "abcd";
printf("%i", *(int *)&foo[0]);
tells the C compiler that foo is a 4 character string with the value
"abcd", but in the next statement we get a pointer to the start of
the string, tell the compiler "No, really, this is a pointer to an
int. Really!" and then dereference it as if the string "abcd" really
*was* an integer. If C were strongly typed you couldn't do that.
Perl, on the other hand, is strongly typed. If you try this:
$foo = "abcd";
$bar = \$foo; # Get a reference to $foo
print $bar->[10]; # Treat $bar as if it were a reference to an array
Perl will yell at you, telling you that $bar isn't an array
reference. If perl were weakly typed (like C is) it'd let you, but it
doesn't.
And yeah, I'm throwing perl in here because it has what is reasonably
considered a bizarre type system (it doesn't have integers or strings
as types. It has "singular thing", "aggregate thing accessed via
integer offset", and "aggregate thing accessed by name" as types,
with a lot of autoconversion and context sensitive behaviour to give
people's brains a twist) but it's still a strong one -- you're just
not allowed to violate it.
Static vs dynamic typing, on the other hand, refers to how much
knowledge you have at compile time about the types of your variables.
For example, with Ruby (since I have a manual handy and wouldn't want
to embarrass myself in python with Sam around :) code like:
s = object.bar(1,2,3)
is just fine -- this is the first time we use s, it's never been
declared, and the compiler may well have no clue as to what
object.bar returns (heck, it may not even exist at compiletime). We
can only know the type of s at a point in time. C, on the other hand,
is statically typed -- you must give the compiler a type for each
variable. (Even if you lie about it later)
Strong/weak and static/dynamic typing can mix just fine. You can have
a strong dynamically typed language (this'd be one where you don't
know the type of a variable at compiletime, but once it gets a type
it *keeps* that type) or a weakly statically typed language, like C,
where you *must* give types at compile time to everything but can
like left and right about it at runtime.
(And thus endeth the rant :)
Anyway, Parrot'll do strong typing if you want it to, no big deal.
PMCs are in complete control on assignment, so you can have all the
strong types check to see what they're handed and pitch a fit at
runtime if it's wrong.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>On 1 Dec 2004, at 14:33, Matt Fowles wrote:
>
>>Strong typing can be more clearly seen in something like haskell
>
>Will there be haskell on parrot? How easy/hard would that be?
Dunno if there will (though I'd love it) and it shouldn't be too
hard. That'd be an interesting thing. (I've pondered, more than once,
Prolog for parrot :)
Michael Walter
> On Wed, Dec 01, 2004 at 01:34:57AM -0800, Brent 'Dax' Royal-Gordon wrote:
> > Cameron Zemek <gr...@capsicumcorp.com> wrote:
> I don't think that "oddball control flow constructs" like closures are
> proper to dynamic languages. For example, OCAML (another camel related
> language :) relies on type inference at compile time so is by nature a
> statically typed language. It supports closure and exceptions. I don't
> know about continuations, coroutines.
should be possible as well [1].
Cheers,
Michael
[1] call/cc for Ocaml: http://www.pps.jussieu.fr/~balat/tdpe-popl04.php
Fraser Wilson
On Wed, 1 Dec 2004, Dan Sugalski wrote:
> Dunno if there will (though I'd love it) and it shouldn't be too hard.
Just delurking for a moment to mention that for various reasons I recently
wrote a (much of) Haskell --> lazy SK machine compiler. The SK machine is
reasonably simple, and I have vague plans to implement one in Parrot
assembly for a learning experience (once I work out how to do a garbage
collected binary tree PMC the rest should be a doddle ...)
So, uh, watch this space. The nice thing is that anything it lacks in
efficiency can be explained away as "purposely stressing the Parrot
engine."
Fraser.
Luke Palmer
> I've always thought of Perl5 having two basic types: Scalar and List, with
> Hash and Array being subtypes of List. The reason is that arrays and hashes
> can be easily converted into each other, because of Perl5's list-flatening
> nature:
>
> @array = %hash;
> %hash = @array;
I wouldn't say that:
my $array = [1, 2, 3, 4];
print $array->{1}; # error!
Perl doesn't automatically convert between them; however, you're allowed
to assign them to each other. That is, a hash isn't a list, but in list
context, it turns into one.
Luke
Timm Murray
<>
> And yeah, I'm throwing perl in here because it has what is reasonably
> considered a bizarre type system (it doesn't have integers or strings
> as types. It has "singular thing", "aggregate thing accessed via
> integer offset", and "aggregate thing accessed by name" as types,
> with a lot of autoconversion and context sensitive behaviour to give
> people's brains a twist) but it's still a strong one -- you're just
> not allowed to violate it.
<>
I've always thought of Perl5 having two basic types: Scalar and List, with
Hash and Array being subtypes of List. The reason is that arrays and hashes
can be easily converted into each other, because of Perl5's list-flatening
nature:
@array = %hash;
%hash = @array;
The result may or may not be useful, but Perl will let you get away with it,
since they're really just lists with different means of indexing.
Steve Fink
>
> C, for example, is weakly typed. That is, while you tell the system
> that a variable is one thing or another (an int, or a float), you're
> perfectly welcome to treat it as another type. This is *especially*
> true of values you get to via pointers. For example, this snippet
> (and yes, it's a bit more explicit than it needs to be. Cope, you
> pedants :):
>
> char foo[4] = "abcd";
> printf("%i", *(int *)&foo[0]);
>
> tells the C compiler that foo is a 4 character string with the value
> "abcd", but in the next statement we get a pointer to the start of
> the string, tell the compiler "No, really, this is a pointer to an
> int. Really!" and then dereference it as if the string "abcd" really
> *was* an integer. If C were strongly typed you couldn't do that.
A wholly off-topic comment about how to make use of this:
When running gdb on a C (or better, STL-happy C++) program, it's nice to be
able to set conditional breakpoints.
b myfile.c:328
cond 1 somevar == 17
but gdb can often get confused or very slow if you try to do something
similar with a char* value:
cond 1 strcmp(mystring,"badness") == 0
It goes crazy making a function call every time that breakpoint is reached. I
can get gdb to segfault this way without too much trouble. So instead, use
this trick:
cond 1 *(int*)mystring == *(int*)"badness"
and it'll go back to doing a simple integer comparison. And it's very fast
about that. Note that because you're using a probably 32-bit integer, that
isn't really looking at the whole string; it'll have exactly the same effect
if you say
cond 1 *(int*)mystring == *(int*)"badn"
I often use this in combination with std::basic_string types in C++, since
the templatized types and other implementation-dependent weirdnesses end up
making things much harder than if you were using simple char*'s. So it would
look something like:
cond 1 *(int*)mystring.data() == *(int*)"badn"
Or maybe it's slightly safer to do this, I dunno:
cond 1 *(int*)mystring.c_str() == *(int*)"badn"
Sorry for the diversion. Um... if I had to say something on-topic, I'd point
out that Perl's type system isn't complete ("not THAT strong"), since there
some corners in the language where you can sneak around it. pack("p"), some
system calls, and other things I can't think of. But maybe the very oddness
of those things is evidence that Perl does indeed have a strong type system.
("Strong" in the technical, not comparative, sense.) Not that anyone seems to
be able to agree on the exact definition of "strong typing".