At 04:52 AM 8/1/2001 +0200, Samuele Pedroni wrote:
>[Eric S. Raymond]
> > No, but we want to be able to interoperate with Perl and have if possible
> > have just one back end on which efforts to do things like native code
> > compilation can be concentrated.
>
> From my experience of the relative pain of a dynamic language over a static
>typed VM, and from the fact that native (dynamic?) compilation of
>Python/Perl would reduce the amount of code that must/is perceived to have
>to be written C, if the goal is to work on the long run on native
>compilation, that's a *great* goal.
This is one of the goals, yes. It's next on the list after getting a
working interpreter. There will probably be a TIL version on the road to
native compilation.
>IMHO also the fact of not merging the type "ontologies" but carrying somehow
>both around is a bit scary.
It's mildly scary, sure. On the other hand, it's not really any more scary
than, say, writing code in COBOL, C++, Basic, or Fortran and calling them
from C. Or vice versa. While that's a tad odd, you can pretty easily get
used to it, and it works out well.
You also don't have to mix languages. That's certainly one of the
advantages, but it's far from required. (This is assuming, of course, that
there's a performance gain to be had in targeting the parrot back end--if
there isn't, then it's reasonably pointless to do so)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4