Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > question on java lang spec chapter 3.3 (unicode char lexing)

Reply
Thread Tools

question on java lang spec chapter 3.3 (unicode char lexing)

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
On 1/3/2013 11:54 PM, Aryeh M. Friedman wrote:
> The only issue is likely a philosophical one in that I have *NEVER*
> trusted code generators of any kind they either produce impossible to
> follow/debug code or have all kinds of fluff in them (the classic
> example in my mind [html which is not really a programming lang ]
> is Dreamweaver that produces 75 lines of HTML for "hello, world").


Sounds like NIH.

The generated code may be hard to follow, but will be more
well tested.

Arne


 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
On 1/5/2013 8:25 AM, Aryeh M. Friedman wrote:
> Machine code was never meant to be readable but high level languages
> can and should be .... on the serious side of the debate there are
> reasons for shying away from code generators in my case that are
> currently proprietary (some of the lesser results will likely be
> FOSS'ed though)... the main reason is we need to (in some cases) deal
> with multiple languages in the same compilation unit and have
> developed fairly good (at least in theory and my "fun work" is really
> nothing more then a proof of concept, without the pressure of
> deadlines and such, with Java as a typical non-trivial language to
> work with from the compiler POV)... due to the above using a parse
> generator would make it very inefficient to create the needed parsers
> since they are (by there very nature) very non-OO in how they deal
> with more then one grammar at once... namely they are designed to
> deal with single languages at a time and not "families" of them


????

You have:

1 handwritten lexer + 1 handwritten parser vs 1 generated lexer + 1
generated parser

and:

N handwritten lexers + N handwritten parsers vs N generated lexers + N
generated parsers

If it is cheaper to generate for 1 then I would expect it to be cheaper
to generate for N as well.

That the generated lexers and parsers may be more procedural than
object oriented should not be a show stopper.

Common languages like C++ and Java can fine call different
functions from different classes.

Arne



 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
On 1/2/2013 11:41 PM, Aryeh M. Friedman wrote:
> On Wednesday, January 2, 2013 9:46:12 PM UTC-5, Arne Vajh°j wrote:
>> On 1/2/2013 9:27 PM, Aryeh M. Friedman wrote:
>>> On Wednesday, January 2, 2013 9:26:03 PM UTC-5, Arne Vajh´┐Żj wrote:
>>>> On 1/2/2013 9:22 PM, Aryeh M. Friedman wrote:
>>>>> an other requirement not satisfied by any IDE we have found is
>>>>> the
>>>>> ability to lay the source tree out in such a way that it can be
>>>>> compiled without the IDE (a requirement for almost all our
>>>>> projects
>>>>> because none of our clients have IDE's and in almost all cases
>>>>> there
>>>>> are minor changes needed to make the code happy on their site
>>>>> that
>>>>> make testing impossible on the development machine)
>>>> The Java IDE's I know put code in a structure that fits
>>>> java tools, ant and maven.
>>> And in almost any non-trivial case this is completely incorrect...

>>
>> Given that a big part (my estimate: 80-90%!) of all Java applications
>>
>> are build:
>>
>> - developer use IDE and checkin to VCS
>> - build process checkout from VCS and use ant/maven to build
>>
>> then it has to be correct.

>
> Correct in what sense?


Same sense as you used incorrect!

>>> even though I love Java as a lang I have a serious issue with some of
>>> the attitudes/assumptions made by tools... namely the universe does
>>> not revolve around the JVM

>>
>> I find it natural that tools developed for Java development are the
>> best for Java development and tools developed for C development are
>> the best for C development and ... PHP ... Python ... etc..

>
> Most real world projects (unless they a part of a larger effort) have
> several components/languages (for us for example it is typical to
> have a HTML/CSS/JS component and a Java/"JSP" component [I am
> defining "JSP" a little loosely because we often need to support more
> then just web front-ends]... it is also common for us to have some
> native code accessed via a JNLP wrapper)...


(JNI wrapper??)

Eclipse and NetBeans can support all those languages.

But if you have sufficient much work in each language then
a different IDE for the HTML/CSS/JS and another for the
C/C++ could make sense.

You may want to use ant for the Java stuff and make for the
C/C++ stuff.

But ant can call make and make can call ant, so they can be integrated.

Arne


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      01-07-2013
On 1/5/2013 8:34 AM, Aryeh M. Friedman wrote:
agreed for example the following is just ugly but perfectly valid Java
code:
>
> Foo.java:
> \u0070\u0075\u0062\u006C\u0069\u0063\u0020\u0063\u 006C\u0061\u0073\u0073\u0020\u0046\u006F\u006F\u00 0A\u007B\u000A\u0009\u0070\u0075\u0062\u006C\u0069 \u0063\u0020\u0073\u0074\u0061\u0074\u0069\u0063\u 0020\u0076\u006F\u0069\u0064\u0020\u006D\u0061\u00 69\u006E\u0028\u0053\u0074\u0072\u0069\u006E\u0067 \u005B\u005D\u0020\u0061\u0072\u0067\u0073\u0029\u 000A\u0009\u007B\u000A\u0009\u0009\u0053\u0079\u00 73\u0074\u0065\u006D\u002E\u006F\u0075\u0074\u002E \u0070\u0072\u0069\u006E\u0074\u006C\u006E\u0028\u 0022\u0068\u0065\u006C\u006C\u006F\u002C\u0020\u00 77\u006F\u0072\u006C\u0064\u0022\u0029\u003B\u000A \u0009\u007D\u000A\u007D\u000A
>
> % javac Foo.java
> % java Foo
> hello, world




It is one of those features that can certainly be misused.

Arne



 
Reply With Quote
 
Aryeh M. Friedman
Guest
Posts: n/a
 
      01-07-2013
On Sunday, January 6, 2013 9:49:17 PM UTC-5, Arne Vajh°j wrote:
> On 1/5/2013 8:25 AM, Aryeh M. Friedman wrote:
>
> > Machine code was never meant to be readable but high level languages

>
> > can and should be .... on the serious side of the debate there are

>
> > reasons for shying away from code generators in my case that are

>
> > currently proprietary (some of the lesser results will likely be

>
> > FOSS'ed though)... the main reason is we need to (in some cases) deal

>
> > with multiple languages in the same compilation unit and have

>
> > developed fairly good (at least in theory and my "fun work" is really

>
> > nothing more then a proof of concept, without the pressure of

>
> > deadlines and such, with Java as a typical non-trivial language to

>
> > work with from the compiler POV)... due to the above using a parse

>
> > generator would make it very inefficient to create the needed parsers

>
> > since they are (by there very nature) very non-OO in how they deal

>
> > with more then one grammar at once... namely they are designed to

>
> > deal with single languages at a time and not "families" of them

>
>
>
> ????
>
>
>
> You have:
>
>
>
> 1 handwritten lexer + 1 handwritten parser vs 1 generated lexer + 1
>
> generated parser
>
>
>
> and:
>
>
>
> N handwritten lexers + N handwritten parsers vs N generated lexers + N
>
> generated parsers
>
>
>
> If it is cheaper to generate for 1 then I would expect it to be cheaper
>
> to generate for N as well.
>
>
>
> That the generated lexers and parsers may be more procedural than
>
> object oriented should not be a show stopper.
>
>
>
> Common languages like C++ and Java can fine call different
>
> functions from different classes.
>
>
>
> Arne


Don't forget domain specific langs some of which may rewrite the actual content of the other embedded langs... bottom line a well designed version of this is cheaper in the long run if one of the goals is to quickly add new langs to each family

besides which I compared my hand written code to that produced by yacc/lex (and antlr to make sure I was not seeing stuff) and 1) mine is a fraction of the line count [about 90% smaller], 2) Has a much lower big-O (O(n) vs. O(n^2)), 3) is trivial to hand trace (why I would want to is any other point), 4) easier to test with unit testing because you can actual get underthe hood unlike the above that is totally opaque
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Isn't java.lang.Character.html#{ isLetterFromLang(int codePoint,String ISOLangDef) missing from the spec? Joshua Cranmer Java 5 12-05-2010 12:17 PM
Re: Isn't java.lang.Character.html#{ isLetterFromLang(int codePoint,String ISOLangDef) missing from the spec? Arne Vajh°j Java 2 12-05-2010 03:48 AM
How to control order of spec execution in "spec specs/* " ? Andrew Chen Ruby 1 03-25-2008 12:36 PM
(const char *cp) and (char *p) are consistent type, (const char **cpp) and (char **pp) are not consistent lovecreatesbeauty C Programming 1 05-09-2006 08:01 AM
/usr/bin/ld: ../../dist/lib/libjsdombase_s.a(BlockGrouper.o)(.text+0x98): unresolvable relocation against symbol `std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostre silverburgh.meryl@gmail.com C++ 3 03-09-2006 12:14 AM



Advertisments