[REBOL] Re: Rebol > Lisp
From: tim:johnsons-web at: 12-Feb-2003 12:08
Hi Rod:
* Rod Gaither <[rgaither--triad--rr--com]> [030212 11:36]:
> >It would be easier if the target language had an API
> >that accomodated such an effort.
>
> I'm not sure what you mean by this.
/ ***** EXAMPLE ***** /
make block! ; rebol
make_block() // c
> >I have a project to do that entails building an
> >'object-oriented' interface in Ansi C (not C++).
>
> If you are going to tackle such a project I would
> recommend you review the design of Objective-C.
> It has such a simple implementation approach
> that it should be a good basis to start from.
This is specifically target project for a
client. Along with meeting the goals, it's
worth investigating a rebol-to-C angle,
just for edification.
> http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/index.html
>
> I would ask why though - is the goal to have some
> higher level design language that outputs C for
> portability or is it just a learning project?
Again. Specifically targeted project for a client,
but that client is a learning institution.
But I did do a bid not too long ago on converting
a rebol source project to "C". Also, I don't know
many of the details, but one of my brothers is
a Section Engineer for Motorola. He tells me
that they use perl and rebol extensively for internal
programming and frequently convert rebol and/o perl
code to C. Perhaps imbedded programming?
> I know there are valid reasons for wanting C as the
> end result but such goals always bring up questions
> in my mind. Questions that typically lead me to the
> opinion that a better option is being overlooked.
I'm only using C as an example here. But here is
another thought - bear in mind that I am just
think out loud ther - what about an imbedded
programming project where the target was C
or assembler?
Wouldn't it be nice to write it in rebol, than
automagically convert it to C or ASM. God! What
a pipe dream! [recovering ASM programmer here]
> There is however a lot of value in identifying the
> higher level design language ( Dialect :-) ) that will
> address the problem space no matter what the
> final solution is.
>
> >My approach to this would be bearing in mind that
> >I might want to auto-convert from one language to
> >another.
>
> This is an oft sought after, and very elusive goal. It is this
> goal, from a different angle - interoperability rather than
> generation, that makes Microsoft's CLI/CLR technology
> interesting.
I program primarily in REBOL these days, but I would not
be serving myself well, (or my clients) if I focused
on all-rebol-all-the-time. Dare I mention it :-), but
we don't even know if rebol will persist as a programming
language or as a business entity.
I mean, have to tell my clients that I won't be around
forever, right? :-)
> I couldn't find a really good link to CLI/CLR specifics in
> my two minute google searches. I would appreciate it
> it anyone has a nice definitive resource on the topic.
>
> Here is a fluffy starter piece for those interested.
>
> http://www.greymatter.com/Buyers/HardCopy/Issue14/TECHTOPICSs.pdf
>
> >But one has to have means, method, AND motivation.
>
> :-)
And thanks for the links Rod!
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.alaska-internet-solutions.com
http://www.johnsons-web.com
