Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 30, 2000 at 05:07:32AM +0000, David Grove wrote:
> > >From my understanding, "API" is the set of functions internal to
Perl
> and
> > PerlXS that allow C to access Perl internal structures, functions,
etc.,
> > for the purpose (or effect) of "writing" "Perl" in "C"
(SvPV(whatsis)).
>
> Uhm, no. An API is a *programming interface*. It tells you what
functions
> are
> available. That's all. It's the reference manual to a library. It's a
way
> of
> handing a programmer a black box; you don't need to care how the
functions
> are
> implemented, you're just told what they are and what they do. You can't
> write
> anything "in API". You can write an API, or you can use an API.
You're senselelessly arguing semantics, Simon. I fully realize that API is
not a programming language in itself. However, since an API is a
collection of functions that are used to address a central theme, in this
case, Perl internals. Back when I was writing C code using an add-on
library of C functions that specifically handled dBASE databases (I forget
the name of the library), we considered ourselves to be writing in
"LibraryX". Of course we knew we were writing C. We were also "writing in"
an applied API of that language. If you really want to get semantically
tricky, since a language is defined by the functions and keywords
available to it, though it be a stretch, an API could from a point of view
be seen as a "language". In practicality that's nonsense, but for the
purpose of conversation and discussion, it's just semantics. You don't
write "in DBI", of course, or "in Tk" (or even "tklib"), but you do write
"DBI code". If you semantically object to my use of the word "in" with
something like this, completely ignoring every other word in a 300-word
email, then creating this masterwork will take a long, long, long time.
> > Dan: In any PDD generated from this group, we really need to define
for
> > the "semantically challenged" the terms that are used within it
>
> You know why we have a reading list, right? It's so you can read books
> which
> explain these things for you; this means that *WE DON'T HAVE TO*.
Take that up with Amazon.com. They have a peculiar habit of sending out a
shipping notice, and giving UPS a shipping document, several days before
actually handing the package over to UPS for delivery. When I get my
books, I'll get my semantics in order. Until then, if I use an
inappropriate preposition, or an ill-timed article, or even a slightly
off-kilter pronoun, you'll simply have to figure it out from context.
> I categorically do *NOT* want perl6-internals to turn into a basic
course
> in
> compiler design, purely for the benefit of those who know nothing at
all
> about
> what they're trying to achieve. I'd like Perl 6 to be a masterwork, and
> masterworks require master craftsmen. If you want to partake in
compiler
> design, it makes more than a little sense to find out how to do so.
There's a vast difference between an "introductory course" and
"exclusionary linguistics", as there is a vast difference between
professional skill and pompous elitism. I'm not asking for basics, just
perl peculiarities and definitions of major terms as they are applied.
Some of those definitions have already been sought and given, I'd just
like them written into the PDD coming from this group. I don't think a bit
of cut and paste is too much to ask.
I've specifically skipped discussion of topics and branches that I've not
understood because of a limited knowledge of compiler internals that will
last until I've studied the topic further, but the subject turned to
something that I was already working on, and something in which I have
some contribution to offer, and some work and research already done, and
some brainstorming already brought to a point of making sense. I don't
think that semantic bickering is warranted. You've completely forked from
the topic because of a two letter word.
Can we get back to the topic, please?
Is a "source filter" worth looking into for the creoles / "little
languages", and, if so, does the method that I've proposed make any sense,
regardless of what it's written IN?
I would suggest that keeping this at a higher level would allow greater
freedom for people to modify the input-language to suit their specific
requirements or peculiarities. I wouldn't want to think that a person who
wanted a "switch" statement to translate to an if-elsif-else ladder would
have to go beyond Camel IV. I'd really hope they wouldn't have to wait for
compiler books from Amazon or read mounds of material on perlguts to
accomplish what we have an opportunity to expose as a very simple task.
Could these creoles / "little languages" be effectively translated into
Perl before interpretation, or must they translate directly into
internals? Perhaps this is expressed as exposing a perl-based API to
creole authors, where what they write fits into a definition as well as
the freedom to do as they please until they get to that definition?
