Re: Rationale for a VM + compiler approach instead of an interpreter?

[Tim Bunce]

On Sun, Dec 07, 2014 at 07:58:06AM +0530, Mayuresh Kathe wrote:
> 
> I am training for computer science, and as a "rite of passage", my
> mentor + guide has asked me to write either an interpreter or a
> compiler for any language of my choice. Would prefer to work on Perl6.

Perhaps write either an interpreter or a compiler for any language of
your choice _in_ Perl 6. I hear it's rather good at that :)

Tim.

[perl #123116] [BUG] Weird error for code parameters with subsignatures in Rakudo

[Carl Mäsak via RT]

masak (>):
> I am not 100% sure the `&block (Dog --> Bool)` form should work,
> or is by spec. The `&block:(Dog --> Bool)` form comes from S06:1675.

 at one point we required a : because of the ambiguity with sublists 
of parameters, but we already have a whitespace dep with @foo[3,3] vs @foo 
[$x,$y,$z], so having one for () is probably not terrible
* masak adds TimToady's comment to the ticket

Re: Definitions: compiler vs interpreter [was: Rationale for a VM + compiler approach instead of an interpreter?]

[Parrot Raiser]

The practical distinction, surely, is that the output of a compiler is
usually kept around, to be run one or more times, whereas the an
interpreter always works with the original human-readable source.

The distinction mattered a lot more when compiling even a trivial
program involved at least the order of minutes. Then, it was important
to re-use the binary, to avoid recompiling for as long as possible.
(Although even in the 1970s, a report-writer program could be run from
source without noticeable delay.) Now, the compilation phase is
usually trivial in comparison to run times, for any significant data
set.

Perl 6 just needs a spot of optimisation in the compile phase. :-)*

On 12/6/14, Aristotle Pagaltzis  wrote:
> * Moritz Lenz  [2014-12-06 20:05]:
>> First of all, the lines between interpreters and compilers a bit
>> blurry. People think of Perl 5 as an interpreter, but actually it
>> compilers to bytecode, which is then run by a runloop. So it has
>> a compiler and an interpreter stage.
>
> This is sort of a tangent, but it was a clarifying insight that resolved
> a point of vagueness for me, so I’d like to just talk about that for
> a moment if you’ll indulge me.
>
> Namely, that line is actually very clear in a theoretical sense, if you
> judge these types of program by their outputs:
>
> Interpreter:
> A program that receives a program as input and produces the output
> of that program as output
>
> Compiler:
> A program that receives a program as input and produces another
> equivalent (in some sense) program as output
>
> Now some compilers emit programs that can be run directly by the CPU of
> the same computer that is running them, without an extra interpreter.
> This is what people with fuzzy ideas of the terms usually refer to when
> they speak of a compiler. But the output doesn’t have to be a program of
> this kind.
>
> The blurriness in practice comes from the fact that essentially all
> programming languages in use by humans are very impractical to use for
> direct interpretation. And so almost every interpreter ever written is
> actually coupled to a compiler that first transforms the user source
> program into some other form which is more convenient to interpret. Even
> the BASICs on those famous old home computers of the past are combined
> compiler-interpreters in this sense.
>
> Basically just parsing an input program up front as a whole essentially
> meets the definition of a compiler – even if a rather weak version of
> it. I think that means shells are typically true interpreters, and that
> they are more or less the only real examples of such.
>
> Regards,
> --
> Aristotle Pagaltzis // 
>

Using C structs containing pointers from NativeCall?

[Steve Mynott]

I was trying to wrap GDBM and was having problems with

typedef struct {
char *dptr;
int   dsize;
  } datum;


>From /usr/include/gdbm.h (on Debianish system)

Since I don't seem to able to pass this sort of structure as

use v6;
use NativeCall;

constant LIB = "libgdbm";

class MyPointer is repr('CPointer') {
has Str $.s;
}

class Datum is repr("CStruct") {
has MyPointer $.p;
has int  $.s;
}

sub gdbm_open(Str $name, Int $block_size, Int $flags, Int $mode, Str
$fatal_func) returns OpaquePointer is native(LIB)  { ... }

sub gdbm_store(OpaquePointer $dbf, Datum $key, Datum $content, int
$flag) returns Int is native(LIB)  { ... }

my $dbf = gdbm_open('foo.dat', 512, 2, 0o755, "");

my $key = Datum.new(:p(MyPointer(:s("foo")),:s(3));
my $val = $key;

my $ret = gdbm_store($dbf, $key, $val, 0);



-- 
4096R/EA75174B Steve Mynott