On Wed, Dec 20, 2000 at 12:40:46AM -0500, Mark-Jason Dominus wrote:
>
> > "The new version must be better because our gazillion dollar marketing
> > campaign said so. (We didn't really *fix* anything.)
>
> The part I found interesting was the part about elimination of the message.
>
> Perceiv
> "The new version must be better because our gazillion dollar marketing
> campaign said so. (We didn't really *fix* anything.)
The part I found interesting was the part about elimination of the message.
Perceived slowness is also important.
On Wed, Dec 20, 2000 at 12:25:10AM -0500, Mark-Jason Dominus wrote:
> http://www.xanalys.com/software_tools/mm/articles/lang.html#emacs.lisp
>
>
> Erik Naggum ([EMAIL PROTECTED]) reports:
>
> I have run some tests at the U of Oslo with about 100 users who
> generally agreed that Emac
http://www.xanalys.com/software_tools/mm/articles/lang.html#emacs.lisp
Erik Naggum ([EMAIL PROTECTED]) reports:
I have run some tests at the U of Oslo with about 100 users who
generally agreed that Emacs had become faster in the latest Emacs
pretest. All I had done was to remove
On Tue, Dec 19, 2000 at 06:11:06PM +, David Mitchell wrote:
> Since in real life the types of args are often the same, this will usually
> be a win.
I found that you have to make an effort to make them the same, else generally
enough of them aren't that decision making code outweighs speed ga
I'm wondering if we should explicitly break out the languages that
comprise perl today. That'd be at least toplevel perl, regular
expressions, and pack. Maybe tr// and the second half of s/// are
sufficiently different too. If nothing else, it would highlight the
problems in switching languages mi
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> David Mitchell <[EMAIL PROTECTED]> writes:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> >> What are string functions in your view?
> >> m//
> >> s///
> >> join()
> >> substr
> >> index
> >> lc, lcfirst, ...
> >> & | ~
> >> ++
> >>
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Mon, 18 Dec 2000, David Grove wrote:
>
> >
> > Andy Dougherty <[EMAIL PROTECTED]> wrote:
> >
> I think you misunderstand. I think it should be very easy to *use* a
> hypothetical Pythonish module. I don't expect it will be very easy to
> c
On Mon, 18 Dec 2000, David Grove wrote:
>
> Andy Dougherty <[EMAIL PROTECTED]> wrote:
>
> > The issues of 'use Python' or 'use Pythonish' are a quite different
> issue.
> > I don't think anyone believes it ought to be easy to *write* the
> Pythonish
> > module.
>
> I do.
> That's the probl
Sam Tregar <[EMAIL PROTECTED]> writes:
>
>It comes down to what is meant by "little language". When I hear that
>term I immediately think Scheme and TCL. They both have a small core and
>extremely regular syntax. I can imagine writing a smallish parser that
>spits out Perl bytecode for either.
Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
>Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
>> Something I though of:
>> If you're trying to write an interactive perl inputer - either a perl shell
>> or just the command prompt on the debugger it would be useful if you
>> could tell the parser that t
David Grove <[EMAIL PROTECTED]> writes:
>
>Because what is the parser/lexer/tokenizer parsing? Perl? Pythonic?
>Javanese?
It is entierly possible to use one parser/lexer "engine" for multiple
languages - for example a yacc/byacc/bison LALR(1) parser is a simple
state machine - all the language
12 matches
Mail list logo
