Re: .il code/file questions
Derek Parnell wrote:
>
> Andy Serpa wrote:
> >
> > Robert Craig wrote:
> > >
> > > In theory, I could sell the translator source, but with
> > > the restriction that it can only be used for private use,
> > > and not for creating and distributing new versions of Euphoria
> > > to the masses. It would involve extra
> > > configuration/packaging/documenting/tech suport
> > > work for me, and I don't think there are very many people,
> > > other than potential competitors,
> > > who would have the ability or desire to modify the translator
> > > in a significant way, though some front-end changes might be easy.
> > > In general, it's quite a bit more complicated than the interpreter.
> > >
> > > It provides me with one of my last "fig leaves" in this
> > > age of openness. 
> > >
> >
> > How about this? You already have an open-source front-end. Now we just
> > have to get
> > to the point where that can really be useful. What I would like, and I
> > think it would
> > increase demand for sales rather than decrease it, is this: allow me or
> > anyone to hack
> > to the front-end to our heart's content, and then allow that front-end to be
> > "plugged
> > in" for use with the translator or binder. We would still need to buy the
> > binder from
> > you to make .il files, and we would still have to register the translator to
> > get rid
> > of the delay. Since the translator is now written in Euphoria, couldn't it
> > actually
> > just run as interpreted Euphoria instead of as an .exe? You could shroud
> > the proprietary
> > parts of it, but allow us to replace the unshrouded front-end source files
> > with our
> > modified versions. Isn't this basically what we can do with the interpreter
> > if we
> > register the source? So let's allow it with the translator too -- a fully
> > user-modifiable
> > front-end that emits the same .il as usual, but arrived at differently
> > because the
> > user has modified the parser, etc. I hope I am explaining clearly...
>
> This is the sort of thing I was also suggesting. RDS doesn't lose on the
> deal because the only thing we would be replacing is the free stuff anyway.
>
> In fact, RDS needs to realize that they have multiple products - the free
> Euphoria-to-IL converter(s) - the front-end, and the not-free binder that
> can bind backend.exe to an IL to create a new .exe file.
>
> I want to support RDS's backend because its very very good. Its just that
> I would like to create the IL using a different tool than the free RDS
> product.
>
> I know that the current IL file format is proprietary but that doesn't
> mean that another, public format, can't be devised and supported by
> bind.exe. In fact, I've already started documenting a file format
> that could become the 'official' standard, after lot's of peer review.
>
> It would be only if RDS refuses to support this idea, that some real
> competition could evolve to challenge RDS's income stream. This is
> a real win-win for all.
Sorry for the slow response.
This is a tricky question to answer.
It may be premature to even try to settle this issue now.
After all, 2.5 has been out for all of two days.
Derek and Andy, you have little experience in modifying the
front end, and neither of you has described what
changes you would like to make. You might discover that
you actually need back-end changes as well, to properly implement
some feature. The Euphoria back-end was designed
specifically to execute Euphoria programs, not a wide variety
of assorted programming languages.
The Source Code product lets you make any changes you like,
to either the front end, or the back-end. The only "catch"
is that the interpreter you create must be for your own use.
You can't distribute it to the world (unless it runs on a new
platform).
The Public Domain source lets anyone in the world, for free,
make any changes they like to the way the Euphoria interpreter works.
The only "catch" is that it runs slower than
the official interpreter. Translating it helps, but it's
still slower.
I feel I'm already walking a tight rope, balancing openness
with the need to protect my income. It should be obvious
that I can't make it easy for people to produce their
own "enhanced" versions of Euphoria that run at the same speed
as mine, and can be distributed widely. That would be
financially reckless, if not suicidal. I'm not saying
this proposal would necessarily do that, but I feel the tight rope
getting narrower.
I also feel I have enough product configurations on enough platforms
to keep me busy for now. Adding another configuration that
would be used by only a few people wishing to create fast
personalized versions of Euphoria would probably not be a
good use of my development/testing/documenting time.
But maybe I'll "see the light" after 2.5 has been out a while longer.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
