How to unify first class functions / lexical subs and pir builtins in HLL ?
gabriele renzi
rff.rff at gmail.com
Sun Jun 7 20:05:32 UTC 2009
2009/6/5 Austin Hastings <Austin_Hastings at yahoo.com>:
> Gabriele,
sorry for late replying, I have been bit busy
> I'm in a similar situation with a plain old procedural language. I want to have builtins for things that parrot provides as pir instructions.
>
> However, I've noticed that the pir-provided builtins are generally primitive. For example, the "print" opcode only accepts one argument, the push and unshift opcodes only move one value to the deque, etc.
>
> I think (and have implemented) that the solution is to define "builtins" that mimic the names of the pir opcodes,
> but which do "the right thing" vis-a-vis multiple args, etc.
>
> In my case, that makes the builtins into language-magic. In your case, if you want them to be first class functions you will have to code some functions around them.
I did think about this, it seems somwhat similar to what happens with
the Neko language, but as my problem domain is to just show some of
parrot's features (this is an introductory article for an italian
ezine) I was kind of hoping of there was some builtin way to basically
layer find_lex and (I think) find_name implicitly.
I will probably just end up having the described language as a lisp-2,
and introduce a way to reify functions explicitly.
> What you might consider is building in an "inline pir" function, and defining everything else in terms of that.
> (I put an asm(args) {{ block }} in my language, but my builtins were handled by having the compiler generate the inline code.)
Yes, as a general solution this has some advantages over the other
options I considered, I'll probably use it for my other less toyish
language, thanks :)
More information about the parrot-dev
mailing list