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.
But when people distribute their custom code as EXE files (modified
standalone Euphoria interpreter), things will look different, if I'm not
too much confused. So maybe the license should only allow to distribute
such "customized interpreters" in the form of IL files.
> 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.
That sounds good to me. If it works, both sides (RDS as well as their
customers) would have a benefit.
Regards,
Juergen
--
Have you read a good program lately?
|
Not Categorized, Please Help
|
|
