Re: .il code/file questions
Matt Lewis wrote:
>
> Robert Craig wrote:
> >
> > Pete Lomax wrote:
> > > Am I missing something here?
> >
> > Probably not, though I don't completely understand your point.
> >
> > At this time I feel I've opened things up a lot.
> > I'm giving away 30% of the interpreter source as PD. I'm selling
> > the rest for $79. Wait until 2.5 has been out for
> > a while before trying to get me to consider wonderful new ways
> > of opening things up. I'll be able to make a much better
> > decision when some people actually start to do something with
> > the PD and/or $79 source. Users will also understand better
> > by that time what they can do, and what they want to do.
> > If what they want to do is take full control of the source,
> > add a bunch of "features", run at full speed, and put
> > me out of business, they'll have a long wait.
>
> Rob, I think we understand your concern, however, I don't think anyone
> has properly articulated what they're asking for. We can currently
> examine the PD front end and see the guts of il code and the symbol
> table. What we don't have is a way of turning that into an il file
> that the backend can execute.
>
> What I think is being asked for is basically a breaking up of bind.il,
> so that instead of it compiling the il, it takes this as input, and then
> does the magic shrouding and whatnot. I suppose you could call it an
> il translator.
>
> Basically, you'd have to specify an input format for a pre-il file,
> including anything that's needed from the front end, and then your
> code puts it into the format that the backend needs. You could sell
> this as part of the binding feature, or even separately. Then people
> could distribute their custom code as il files, but anyone who wanted to
> use the custom language would need to buy your binding package. Spun
> that way, it seems like a possible increase on the revenue stream.
> Plus, of course, you could cherry pick what's out there for future
> releases.
>
> It would give nearly immediate relief to those who have namespacing issues
> (like what my modified interpreter addressed--if I can do it in C, then
> I can *definitely* to it in Eu) or the include/cannonical paths issue.
>
> So, to summarize, I don't think it's really opening anything else up,
> but it does give an extra incentive to buy the binding package, and the
> binding process becomes a two step process.
>
> Matt Lewis
>
Hey all,
No, it's not a illusion, I get back online, 3 days after 2.5a is released.
WOOT!
First off, I just have to give my thumbs up to RobC for the work he has
done. It looks exceptionally good.
Now, onto more matters, that actually deal with the thread at question.
I know, alot of people's gripes, and such on this subject, and I first
want to start off by defending RobC. I don't know if many of you realize
this or not, but Robert has tooken a big ass leap from 2.4 to 2.5, and no
one has come to terms with appreciating this. I'm not placing blame on
anyone here, I'm just pointing out the ovious. Putting in full trace
support on the Public Domain Version of Euphoria, Increasing the speed
and compatability of Euphoria, to possibly offer versions on diffrent OS'
(Mac is still one I want to see it on), and even putting out a Open Source,
full version of the Interpreter code, for anyone to see, use, hack, slash,
dice, and slice, then call it thier own, is one tremendous leap forward.
But, at the same time, I do agree, with alot of you, about the restrictions
that still are implaced apon the language. And I think Matt has provided
a more clear explination to what the users want. And I'm gonna to clerify
this to a more certian extent, at which even Rob can appreciate the
possibilities that can come from doing this kind of deal.
As Matt has suggested, there is room to create a Euphoria To IL Tool, in
which Euphoria code, is fed to the system, to create IL Code. This method
is the best, and most suitable causes for anyone here. I don't think
anyone here, can honestly say, they want to see the hard code facts of
every peice of the IL Specification. If I am wrong, please, speak up.
On the other hand, addressing Rob's fear that it would cut into his profits,
I would only like to say this. Imagine if you would Rob, that one of us
creates a Off Bread language, or hybrid. For example, Let's say, I want
to make a Euphoria and BASIC Hybrid. Diffrent Syntax, and such, with my
own way of working things out. I can build off of what euphoria offers
right now, with the PD Eu Version of the Interpreter, and make my own
scheme for binding files, and such. Unfortunatly, this also means, that
as you have said in the release notes, it would be slower then your
Euphoria Interpreter.
But, if we use the previous suggestion, of creating a Intermediate
Euphoria to IL Converter, we bring forth a new way to improve things.
For you see, if I create this EuBASIC language, and say someone wants it,
get's it, and wants to compile programs, to run at fastest speeds, then
they can go back to RDS, and get the Binder System, in which to bind the
EuIL Code, to the backend, and make a Executable.
Because of this, the language relies soely on Euphoria to make executables,
as well as it's own code. Now, to some, this may seem like a pre-proccess
language, but, in truth of it all, Euphoria itself, is a pre-process
language, so is C/C++, and any other language out there. Before the code
can be run, it has to be compiled down into Byte Wise Code, weither it be
by pre-interpretation, or be it from run time interpretation. The only
thing extra, in this hole deal, would be the conversion of whatever syntax
someone decides to use, into Euphoria type syntax. Which euphoria then
turns into IL Code, for use with the Backend. It's only adding a extra
step to the allready well established chain of events to making a program.
It would actually be doing, what C/C++ does allready, as Matt pointed out
with Linking. And you don't see C/C++ Hurting all to much. Personally,
I belive.... no, change that to I know..... that doing something of this
sort, would not be taking away from income that you get on Euphoria now
Robert, infact, you could look at it this way, that it would actually be
putting Euphoria out there, with more flexable features for the user, and
still comes back to you, in any event.
As one wise man once said, `Reap your harvest, but be sure to pay your
workers well.` Think about it.
L8ers,
Mario
|
Not Categorized, Please Help
|
|
