Sorry Kerry (et al).
A full compiler doesn't really seem like the way to go.
I have to agree w/Brennan's suggestion.
Being able to take a script member & export/compile it out as an new
type of 'Xtra' would be a great feature!
It's also something they could PUT ON THE BOX & in the PR RELEASE!
( & this aspect is very important to MACR Marketing ... )
-Buzz
At 11:20 PM +0200 7/5/01, Brennan Young wrote:
>Kerry Thompson <[EMAIL PROTECTED]> wrote
>
>> I don't understand why this isn't at the top of Macromedia's list of
>> upgrades--there is no other single thing they could do to increase
>> performance more, at least for Lingo-heavy apps.
>>
>> At the beginning of a project, the Powers That Be make a decision--do we
>> need performance, or quick development time. If performance is the sine qua
>> non, they use C++. If they can put up with slower performance, they use
>> Director.
>>
>> A Lingo compiler would put Director in the same class with C++ as far as
>> performance, without sacrificing development time.
>
>I can follow you on this, but I would hate to see the loss of the runtime
>interpreter and (especially) the ability to evaluate strings. I don't use
>'do' very often, but I use value() in almost every project. One of the
>biggest problems implementing what you suggest is that Lingo is loosely
>typed, whereas compiled languages are necessarily more tight about what
>datatypes you use, which slows development down. Most compiled languages
>require you to explicitly state the type when creating variables. (C even
>requires you to do it twice. Zzzz).
>
>
>How many Lingo programmers use the same variable to hold strings one minute,
>integers the next, members the next? I don't believe that would be possible
>with a compiled version. It's a genuine convenience to be able to switch
>types like that, or for handlers to receieve parameters of different types.
>
>The compilation cycle itself puts a few seconds between finishing editing
>your code and seeing a result. One thing I love about Director is that,
>barring syntax errors which prevent 'compilation' to bytecode, the 'play'
>button is always ready to go, not to mention the freedom you get
>when debugging.
>
>What might be more useful would be an equivalent of the old 'CompileIt'
>application that used to be available for Hypercard. You'd take a hypertalk
>script - a function, say, run it through 'CompileIt' and get an XFCN out the
>other end. (Something like an Xtra). The performance of these compiled
>modules, while slower than something made carefully in C or (ha) assembler,
>was far better than hypertalk alone, and of course, you had to be quite
>strict about your types, but it was a good middle way.
>
>The mandelbrot example is a typical situation where you would never find a
>commercial Xtra to do that one job, but is just too slow to run in Lingo.
>Rather than compiling *all* the Lingo in a project, it would be more useful
>to isolate some hotspots (such as the number-crunching repeat loops),
>convert them to strictly typed functions, and then compile them. It often
>turns out that the hotspots tend to be those parts of a program which are
>best suited to compilation. None of the datatypes in the mandelbrot example
>are changing. There's no runtime evaluation of strings. It really ought to
>be native compiled binaries.
>
>It can be interesting to look at the way this issue has been treated in LISP
>implementations. LISP, like Lingo, runs in an interpreter, is loosely typed,
>and has a reputation for being slow. LISP is usually 'written in itself',
>with only the lowest level routines constructed in assembler. Eventually,
>someone realised that some of the essential functions made in LISP could be
>compiled to native machine code. Now, any decent LISP implementation also
>features a compiler, and the core routines are all compiled. (I believe the
>compiler also caches the source of each compiled function, so you can always
>go back and edit it). Once you've compiled a function, you can't, for
>example, pass it by value, and all the types are 'set in stone', but it
>retains the advantages of rapid development, with the option of high
>performance where it's needed.
>
>Example: Have a look at the platform game 'Abuse'. It's a LISP program, and
>if you're smart, you can even get at the source code of the higher level
>routines. All the pixel blitting and collision detection stuff is compiled
>to binary, and it's certainly fast enough, but stuff like configuration of
>the levels, and AI remains interpreted, because it makes good sense for them
>to be so.
>
>I'm convinced this is the way forward for Director.
>
>--
>_____________
>
>Brennan
>
>[To remove yourself from this list, or to change to digest mode, go to
>http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
>email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
>Lingo-L is for learning and helping with programming Lingo. Thanks!]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
