On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via Digitalmars-d wrote:
> that's why warp is faster than cpp? ;-)

Which implementation of cpp?

(Btw, take a look at lexer.c in DMD :-P)

On Sun, 16 Nov 2014 22:09:00 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via Digitalmars-d wrote:
> > that's why warp is faster than cpp? ;-)
> Which implementation of cpp?
gcc implementation, afair. it's slowness was the reason for warping.

> (Btw, take a look at lexer.c in DMD :-P)
c++ has no good string type, so there is no much choice.

as a writer of at least four "serious" scripting languages (and alot more as "toy" ones) i can tell you that zero-terminated strings are PITA. the only sane way to write a good lexer is working with structure which emulates D string and slicing (if we must parse text from in-memory buffer, of course).

Am 16.11.2014 um 20:59 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>":
> On Sunday, 16 November 2014 at 19:24:47 UTC, Walter Bright wrote:
>> This made C far, far more difficult and buggy to work with than it
>> should have been.
>
> Depends on your view of C, if you view C as step above assembly then it
> makes sense to treat everything as pointers. It is a bit confusing in
> the beginning since it is more or less unique to C.
>

My view is of a "kind of" portable macro assembler, even MASM and TASM were more feature rich back in the day.

Actually I remember reading a DDJ article about a Texas Instruments Assembler that looked like C, just with one simple expression per line.

So you could not do

a = b + c * 4;

rather

r0 = b
r1 = c
r1 *= 4
r0 += r1

Just an idea, I don't remember any longer how it actually was.


--
Paulo

On Sunday, 16 November 2014 at 22:18:51 UTC, ketmar via Digitalmars-d wrote:
> On Sun, 16 Nov 2014 22:09:00 +0000
> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via Digitalmars-d wrote:
>> > that's why warp is faster than cpp? ;-)
>> Which implementation of cpp?
> gcc implementation, afair. it's slowness was the reason for warping.

Ok, I haven't seen an independent benchmark, but I believe clang is faster. But…

https://github.com/facebook/warp/blob/master/lexer.d#L173

> PITA. the only sane way to write a good lexer is working with structure
> which emulates D string and slicing (if we must parse text from
> in-memory buffer, of course).

Nah, if you know that the file ends with zero then you can build an efficient finite automata as a classifier.

On Sun, 16 Nov 2014 22:22:42 +0000
via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Nah, if you know that the file ends with zero then you can build an efficient finite automata as a classifier.
FSA code is a fsckn mess. either adding dependency of external tool and alot of messy output to project, or writing that messy code manually. and FSA is not necessary faster, as it's bigger and so it trashing CPU cache.

On Sunday, 16 November 2014 at 11:30:01 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright wrote:
>> On 11/14/2014 4:32 PM, deadalnix wrote:
>>> To quote the guy from the PL for video games video serie, a 85%
>>> solution often is preferable.
>>
>> Spoken like a true engineer!
>
> More like a consultant for self-help:
>
> http://www.amazon.com/85%25-Solution-Personal-Accountability-Guarantees/dp/0470500166
>
>
> Real world 85% engineered solutions:
>
> 1. Titanic
> 2. Chernobyl
> 3. Challenger
> 4. C++
> …

Sorry but that is dumb, and the fact you are on the D newsgroup rather on 100% solution languages newsgroup (Java is 100% OOP, Haskell is 100% functional, Rust is 100% linear types, Javascript is 100% callbacks, erlang is 100% concurrent, LISP is 100% meta, BASIC is 100% imperative, python is 100% slow, PHP 100% inconsistent) tells me that not even you believe in your own bullshit.

On Sunday, 16 November 2014 at 22:19:16 UTC, Paulo Pinto wrote:
> My view is of a "kind of" portable macro assembler, even MASM and TASM were more feature rich back in the day.
>
> Actually I remember reading a DDJ article about a Texas Instruments Assembler that looked like C, just with one simple expression per line.
>
> So you could not do
>
> a = b + c * 4;
>
> rather
>
> r0 = b
> r1 = c
> r1 *= 4
> r0 += r1
>
> Just an idea, I don't remember any longer how it actually was.

Not such a bad idea if you can blend it with regular assembly mnemonics. When I did the course in machine near programming university I believe I chose to do the exam in Motorola 68000 machine language because I found it no harder than C at the time…(?) I surely would not have done the same with the x86 instruction set though.

On Sunday, 16 November 2014 at 22:55:54 UTC, deadalnix wrote:
> Sorry but that is dumb, and the fact you are on the D newsgroup rather on 100% solution languages newsgroup (Java is 100% OOP, Haskell is 100% functional, Rust is 100% linear types, Javascript is 100% callbacks, erlang is 100% concurrent, LISP is 100% meta, BASIC is 100% imperative, python is 100% slow, PHP 100% inconsistent) tells me that not even you believe in your own bullshit.

Define what you mean by 100%? By 100% I mean that you can implement your system level design without bending it around special cases induced by the language.

The term "85% solution" is used for implying that it only provides a solution to 85% of what you want to achieve (like a framework) and that you have to change your goals or go down a painful path to get the last 15%.

ASM is 100% (or 0%). You can do anything the hardware supports.

C is close to 98%. You can easily get the last 2% by writing asm.

Java/C# are 90%. You are locked up in abstracted frameworks.

HTML5/JS is 80%. You can do certain things efficiently, but other things are plain difficult.

Flash/ActionScript is 60%. …

What Jonathan Blunt apparently wants is a language that is tailored to the typical patterns seen in games programming, so that might mean that e.g. certain allocation patterns are supported, but others not. (Leaving out the 15% that is not used in games programming). This is characteristic of programming frameworks.

I think it is reasonable to push back when D is moving towards becoming a framework. There are at least two factions in the D community. One faction is looking for an application framework and the other faction is looking for a low level programming language.

These two perspectives are not fully compatible.

On 11/16/2014 2:22 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Sunday, 16 November 2014 at 22:18:51 UTC, ketmar via Digitalmars-d wrote:
>> On Sun, 16 Nov 2014 22:09:00 +0000
>> via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>> On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via Digitalmars-d wrote:
>>> > that's why warp is faster than cpp? ;-)
>>> Which implementation of cpp?
>> gcc implementation, afair. it's slowness was the reason for warping.
>
> Ok, I haven't seen an independent benchmark, but I believe clang is faster. But…
>
> https://github.com/facebook/warp/blob/master/lexer.d#L173

Notice the total lack of strlen()'s in Warp.


> Nah, if you know that the file ends with zero then you can build an efficient
> finite automata as a classifier.

deadalnix busted that myth a while back with benchmarks.

On Monday, 17 November 2014 at 01:39:38 UTC, Walter Bright wrote:
> Notice the total lack of strlen()'s in Warp.

Why would you need that? You know where the lexeme begins and ends? If we are talking about old architectures you have to acknowledge that storage was premium and that the major cost was getting the strings into memory in the first place.

>> Nah, if you know that the file ends with zero then you can build an efficient
>> finite automata as a classifier.
>
> deadalnix busted that myth a while back with benchmarks.

I haven't seen it, but it is difficult to avoid lexers being bandwidth limited these days.

Besides, how do you actually implement a lexer without constructing a FA one way or the other?