Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20210 > unrolled thread

multi-line Strings

Started bybob smith <bob@coolfone.comze.com>
First post2012-12-10 08:22 -0800
Last post2012-12-29 18:18 +0100
Articles 20 on this page of 146 — 22 participants

Back to article view | Back to comp.lang.java.programmer

Contents

  multi-line Strings bob smith <bob@coolfone.comze.com> - 2012-12-10 08:22 -0800
    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 11:43 -0500
      Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:36 -0800
      Re: multi-line Strings markspace <-@.> - 2012-12-10 09:42 -0800
        Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:51 -0800
          Re: multi-line Strings markspace <-@.> - 2012-12-10 10:27 -0800
            Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 13:43 -0500
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 15:08 -0500
                Re: multi-line Strings markspace <-@.> - 2012-12-10 13:05 -0800
                Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 16:22 -0500
                  Re: multi-line Strings markspace <-@.> - 2012-12-10 13:36 -0800
                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 16:52 -0500
                    Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 18:04 -0500
                      Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 00:17 +0000
                        Re: multi-line Strings markspace <-@.> - 2012-12-10 17:35 -0800
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 01:56 +0000
                            Re: multi-line Strings markspace <-@.> - 2012-12-10 18:00 -0800
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:16 -0500
                                Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:21 +0000
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:12 -0600
                            Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-11 05:01 -0400
                              Re: multi-line Strings markspace <-@.> - 2012-12-11 09:46 -0800
                                Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:26 +0000
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 16:25 -0600
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:10 -0500
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:31 +0000
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:30 -0500
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 03:35 -0600
                              Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 11:54 +0000
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-15 08:53 -0500
                                Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-16 12:19 -0700
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:24 +0000
                                Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:21 -0800
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 14:03 +0000
                                    Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:05 -0800
                                Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:13 -0400
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:38 +0000
                                    Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 19:48 -0400
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 21:07 -0500
                                  Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-19 08:26 -0600
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 16:36 -0500
                                      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 12:51 -0600
                                        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 14:05 -0600
                              Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-15 18:22 +0100
                                Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 00:34 +0100
                                  Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 02:56 -0600
                                    Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 14:07 +0100
                                      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 13:44 -0600
                                  Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-16 17:43 +0100
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:37 -0500
                        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:03 -0600
                        Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-11 10:43 -0600
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:44 +0000
                      Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:09 -0500
        Re: multi-line Strings Sebastian <sebastian@undisclosed.invalid> - 2012-12-12 10:40 +0100
          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-12 20:28 -0500
      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 13:42 -0600
    Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-11 07:58 +0100
      Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-11 10:08 -0500
        Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-11 09:41 -0600
        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 15:02 -0600
          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:27 -0500
          Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-14 23:23 -0600
            Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 02:56 -0600
      Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-11 16:31 -0500
        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 17:07 -0600
          Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-11 15:31 -0800
            Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 19:41 -0600
        Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-13 07:43 +0100
          Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 23:09 -0800
          Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-13 06:34 -0400
            Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 07:35 +0100
              Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 02:44 -0600
                Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:48 +0100
                  Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:10 -0600
                  Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-14 15:18 -0800
                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:16 -0500
              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-14 05:55 -0400
                Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:50 +0100
                  Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:12 -0600
                  Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-14 11:24 -0800
                    Re: multi-line Strings markspace <-@.> - 2012-12-14 11:47 -0800
                      Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:26 -0800
                        Re: multi-line Strings markspace <-@.> - 2012-12-14 12:53 -0800
                          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:36 -0500
                            Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 12:06 +0000
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:23 -0500
                            Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-15 08:16 -0600
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:24 -0500
                            Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:36 -0800
                          Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:36 -0800
                      Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:30 -0800
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:43 -0500
                      Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-14 17:36 -0500
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:46 -0500
                          Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 04:29 -0600
                      Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:45 -0400
                        Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 17:11 -0800
                          Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-17 20:25 -0500
                            Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 18:13 -0800
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 06:34 -0400
                                Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-18 10:54 -0800
                                  Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 18:57 -0400
                                    Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-18 20:02 -0500
                                      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-18 17:13 -0800
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:35 -0500
                                  Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 15:12 -0800
                                    Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-19 10:00 -0800
                                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:31 -0500
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:29 -0500
                                  Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 20:44 -0400
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 21:50 -0500
                                      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 23:15 -0800
                                      Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-20 06:00 -0400
                                  Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-20 08:56 -0800
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:33 -0500
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:43 -0500
                              Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-17 22:09 -0600
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:59 -0500
                              Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:22 +0000
                                Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-18 07:52 -0600
                                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:58 -0500
                                Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:10 -0800
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:56 -0500
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:05 -0400
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:42 -0500
                            Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-17 22:18 -0700
                          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:46 -0500
                            Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 21:01 -0800
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:46 -0500
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:51 -0500
                          Re: multi-line Strings Patricia Shanahan <pats@acm.org> - 2012-12-17 19:41 -0800
                          Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:19 -0400
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:50 -0500
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 05:23 -0400
                                Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 13:25 -0800
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
            Re: multi-line Strings Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-12-14 23:43 +0200
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:20 -0500
                Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:47 -0400
    Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-12 08:33 -0700
      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 11:32 -0800
        Re: multi-line Strings markspace <-@.> - 2012-12-12 11:45 -0800
    Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:33 -0800
      Re: multi-line Strings Sven Köhler <remove-sven.koehler@gmail.com> - 2012-12-29 18:18 +0100

Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8  Next page →

#20597

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-19 16:36 -0500
Message-ID<50d2336c$0$285$14726298@news.sunsite.dk>
In reply to#20526
On 12/19/2012 9:26 AM, BGB wrote:
> On 12/18/2012 8:07 PM, Arne Vajhøj wrote:
>> On 12/15/2012 6:54 AM, Chris Uppal wrote:
>>> Off-the-top-of-my-head (all classes and method are imaginary):
>>>
>>>      Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
>>>      alpha = alpha.or('_');
>>>      Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
>>>      Regexp alphanum = alpha.or(num);
>>>      Regexp identifier = alpha.followedBy(alphanum.repeated());
>>
>> I think that is what is widely known in the .NET world
>> as a fluent API.
>>
>
> better term maybe than "big pile o' nasty...".
>
> yes, regex syntax could be nicer, but probably not by making it into a
> big pile of API calls.

It is very popular in some .NET circles.

Surprisingly the Wikipedia article 
http://en.wikipedia.org/wiki/Fluent_interface
does not even cover .NET.

Arne

[toc] | [prev] | [next] | [standalone]

#20666

FromBGB <cr88192@hotmail.com>
Date2012-12-21 12:51 -0600
Message-ID<kb2b98$bn2$1@news.albasani.net>
In reply to#20597
On 12/19/2012 3:36 PM, Arne Vajhøj wrote:
> On 12/19/2012 9:26 AM, BGB wrote:
>> On 12/18/2012 8:07 PM, Arne Vajhøj wrote:
>>> On 12/15/2012 6:54 AM, Chris Uppal wrote:
>>>> Off-the-top-of-my-head (all classes and method are imaginary):
>>>>
>>>>      Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
>>>>      alpha = alpha.or('_');
>>>>      Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
>>>>      Regexp alphanum = alpha.or(num);
>>>>      Regexp identifier = alpha.followedBy(alphanum.repeated());
>>>
>>> I think that is what is widely known in the .NET world
>>> as a fluent API.
>>>
>>
>> better term maybe than "big pile o' nasty...".
>>
>> yes, regex syntax could be nicer, but probably not by making it into a
>> big pile of API calls.
>
> It is very popular in some .NET circles.
>
> Surprisingly the Wikipedia article
> http://en.wikipedia.org/wiki/Fluent_interface
> does not even cover .NET.
>

fair enough...

I have sometimes gone the other way though, finding a dedicated textual 
representation to be more compact and easier to work with than an API, 
but either way.

I guess it depends though...

[toc] | [prev] | [next] | [standalone]

#20671

FromBGB <cr88192@hotmail.com>
Date2012-12-21 14:05 -0600
Message-ID<kb2fjt$kec$1@news.albasani.net>
In reply to#20666
On 12/21/2012 1:03 PM, Stefan Ram wrote:
> BGB <cr88192@hotmail.com> writes:
>> I have sometimes gone the other way though, finding a dedicated textual
>> representation to be more compact and easier to work with than an API,
>> but either way.
>
>    See »The March of Progress« on
>
> http://www.horstmann.com/
>
>    .
>

yeah, in my scripting language:
printf("%10.2f", x);



also typically, math functions can be used directly, like in:
y=sin(x);
or:
z=atan2(y, x)/TAU;	//(TAU=2*PI)
or: ...

actually, as-is, these math functions are actually intrinsics, and 
treated similar to operators by the VM (mostly for sake of higher 
performance, as function-calls are more expensive, and these functions 
may often appear in tight loops).

this also includes a few "uncommon" / "non-standard" math functions, 
like "ssqrt" (signed square root), "spow" (signed power), mostly as 
these are sometimes rather useful.


a cost though is that it isn't currently possible to override them, 
though theoretically a person could write something like:
this.sin();
or:
MyClass.sin();
or:
packagename.sin();
or: ...

partly, as these don't invoke the intrinsic (which is specific to the 
direct-function-call usage). (there are a few method-like intrinsics 
though, mostly ".clone()" and ".toString()" and similar, so it isn't 
really free-and-clear either).

(this issue may be resolved eventually, mostly as it would involve 
nailing down some issues regarding scope, as currently scope isn't fully 
nailed down before producing the bytecode, whereas these intrinsics are 
handled in the front-end compiler).


actually, similarly, many things, like vector-math, are built in (note: 
these types are value-types).

(using the "non-canonical" declaration syntax):
vec3d a, b, c;	//vec3(double)
a=#[1,0,0];
b=#[0,1,0];
c=a%b;	//cross product, c=#[0,0,1]
double f;	//canonical: "var f:double;"
f=a*b;	//dot product

vector types: vec2/vec3/vec4/quat (float), vec2d/vec3d/vec4d/quatd 
(double), where quat = quaternion.

well, there is also complex/fcomplex/dcomplex, which I guess also count 
as vectors (complex=dcomplex, or "double complex").

...

granted, yes, a lot of this is a little closer to the core usage-domain 
of the language (namely, stuff useful in 3D gaming).


or such...

[toc] | [prev] | [next] | [standalone]

#20361

From"Peter J. Holzer" <hjp-usenet2@hjp.at>
Date2012-12-15 18:22 +0100
Message-ID<slrnkcpcff.vq7.hjp-usenet2@hrunkner.hjp.at>
In reply to#20343
On 2012-12-15 03:30, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/11/2012 5:31 PM, Martin Gregorie wrote:
>> Its just a bit frustrating that there are languages around that can deal
>> with regexes without turning them into an unreadable mess and that Java
>> isn't one of them.
>
> The regex syntax itself is not exactly a good example of readability.

True, but there are ways to improve it. For example, Perl has a variant
Regexp syntax (indicated with the /x flag) where whitespace (including
newlines) is ignored and comments are allowed. 

Together with variable substitution, even complex regexps can be quite
readable. For example compare this:

my $param = qr{ [-a-z]+ = " [^"]* " }x;
my $start_tag = qr{ < [a-z]+ (?: \s+ $param )* \s* /? > }x;
my $end_tag = qr{ </ [a-z]+ > }x;
my $comment = qr{ <!-- .*? --> }sx;

my $pcdata = qr{ [^<]*? }x;

my $link = qr{
                <a (?: \s+ $param )* \s* >
                (?:
                    $start_tag | $end_tag | $comment | $pcdata
                ) *?
                </a>
           }x;

with this:

    <a(?:\s+(?:[-a-z]+="[^"]*"))*\s*>(?:(?:<[a-z]+(?:\s+(?:[-a-z]+="[^"]*"))*\s*/?>)|(?:</[a-z]+>)|(?^s:<!--.*?-->)|(?:[^<]*?))*?</a>

Oh, and you may notice the use of qr{} instead of // as delimiters. 
The possibility to use alternate start and end delimiter of *any* string
(not just regexps) is quite a nifty feature and often removes the need
for escapes. 

But for all various string syntaxes that Perl supports, it's still
missing a sane multiline string syntax.

	hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR       | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#20368

FromRobert Klemme <shortcutter@googlemail.com>
Date2012-12-16 00:34 +0100
Message-ID<aj4fneFgqhfU1@mid.individual.net>
In reply to#20361
On 15.12.2012 18:22, Peter J. Holzer wrote:
> On 2012-12-15 03:30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 12/11/2012 5:31 PM, Martin Gregorie wrote:
>>> Its just a bit frustrating that there are languages around that can deal
>>> with regexes without turning them into an unreadable mess and that Java
>>> isn't one of them.
>>
>> The regex syntax itself is not exactly a good example of readability.
>
> True, but there are ways to improve it. For example, Perl has a variant
> Regexp syntax (indicated with the /x flag) where whitespace (including
> newlines) is ignored and comments are allowed.

http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html#COMMENTS

> But for all various string syntaxes that Perl supports, it's still
> missing a sane multiline string syntax.

Does it?

$ perl x.pl
a line
another line
yet another line
one more line
$ cat x.pl

$str=<<MULTI;
a line
another line
yet another line
one more line
MULTI

print($str);

Cheers

	robert



-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#20372

FromBGB <cr88192@hotmail.com>
Date2012-12-16 02:56 -0600
Message-ID<kak2g2$6ug$1@news.albasani.net>
In reply to#20368
On 12/15/2012 5:34 PM, Robert Klemme wrote:
> On 15.12.2012 18:22, Peter J. Holzer wrote:
>> On 2012-12-15 03:30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 12/11/2012 5:31 PM, Martin Gregorie wrote:
>>>> Its just a bit frustrating that there are languages around that can
>>>> deal
>>>> with regexes without turning them into an unreadable mess and that Java
>>>> isn't one of them.
>>>
>>> The regex syntax itself is not exactly a good example of readability.
>>
>> True, but there are ways to improve it. For example, Perl has a variant
>> Regexp syntax (indicated with the /x flag) where whitespace (including
>> newlines) is ignored and comments are allowed.
>
> http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html#COMMENTS
>
>
>> But for all various string syntaxes that Perl supports, it's still
>> missing a sane multiline string syntax.
>
> Does it?
>
> $ perl x.pl
> a line
> another line
> yet another line
> one more line
> $ cat x.pl
>
> $str=<<MULTI;
> a line
> another line
> yet another line
> one more line
> MULTI
>
> print($str);
>

I had before imagined the possibility of something like:
#<<identifier; ... identifier

IOW:
str = #<<EOF;
line 1
line 2
line 3
EOF;

but, never really added this, as heredoc syntax is kind of ugly IMO...

[toc] | [prev] | [next] | [standalone]

#20374

FromRobert Klemme <shortcutter@googlemail.com>
Date2012-12-16 14:07 +0100
Message-ID<aj5vcgFqdpiU1@mid.individual.net>
In reply to#20372
On 16.12.2012 09:56, BGB wrote:
> On 12/15/2012 5:34 PM, Robert Klemme wrote:
>> On 15.12.2012 18:22, Peter J. Holzer wrote:

>>> But for all various string syntaxes that Perl supports, it's still
>>> missing a sane multiline string syntax.
>>
>> Does it?
>>
>> $ perl x.pl
>> a line
>> another line
>> yet another line
>> one more line
>> $ cat x.pl
>>
>> $str=<<MULTI;
>> a line
>> another line
>> yet another line
>> one more line
>> MULTI
>>
>> print($str);
>>
>
> I had before imagined the possibility of something like:
> #<<identifier; ... identifier
>
> IOW:
> str = #<<EOF;
> line 1
> line 2
> line 3
> EOF;
>
> but, never really added this, as heredoc syntax is kind of ugly IMO...

I don't really see the difference - or the improvement.  You just added 
a hash and a semi colon.

Cheers

	robert





-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#20385

FromBGB <cr88192@hotmail.com>
Date2012-12-16 13:44 -0600
Message-ID<kal8gj$k52$1@news.albasani.net>
In reply to#20374
On 12/16/2012 7:07 AM, Robert Klemme wrote:
> On 16.12.2012 09:56, BGB wrote:
>> On 12/15/2012 5:34 PM, Robert Klemme wrote:
>>> On 15.12.2012 18:22, Peter J. Holzer wrote:
>
>>>> But for all various string syntaxes that Perl supports, it's still
>>>> missing a sane multiline string syntax.
>>>
>>> Does it?
>>>
>>> $ perl x.pl
>>> a line
>>> another line
>>> yet another line
>>> one more line
>>> $ cat x.pl
>>>
>>> $str=<<MULTI;
>>> a line
>>> another line
>>> yet another line
>>> one more line
>>> MULTI
>>>
>>> print($str);
>>>
>>
>> I had before imagined the possibility of something like:
>> #<<identifier; ... identifier
>>
>> IOW:
>> str = #<<EOF;
>> line 1
>> line 2
>> line 3
>> EOF;
>>
>> but, never really added this, as heredoc syntax is kind of ugly IMO...
>
> I don't really see the difference - or the improvement.  You just added
> a hash and a semi colon.
>

the '#' is mostly to help avoid syntactic ambiguity (and also to help 
visually provide something for the '<<' to "go into"), and the final 
semicolon is a statement terminator (it is not actually part of the 
string, but can help tell the parser "hey, this statement has ended").

[toc] | [prev] | [next] | [standalone]

#20382

From"Peter J. Holzer" <hjp-usenet2@hjp.at>
Date2012-12-16 17:43 +0100
Message-ID<slrnkcruh6.htc.hjp-usenet2@hrunkner.hjp.at>
In reply to#20368
On 2012-12-15 23:34, Robert Klemme <shortcutter@googlemail.com> wrote:
> On 15.12.2012 18:22, Peter J. Holzer wrote:
>> But for all various string syntaxes that Perl supports, it's still
>> missing a sane multiline string syntax.
>
> Does it?
>
[...]
> $str=<<MULTI;
> a line
> another line
> yet another line
> one more line
> MULTI

Note that I wrote "sane". Here documents aren't sane. They cannot be
indented with the rest of the code, so something like

sub print_message {
    my ($verbose) = @_;

    if ($verbose) {
	print <<EOS
This is a 
very long message.

It goes on 
for ever 
and ever.
EOS
    } else {
	print <<EOS
This is a shorter message.
But it is still too long.
EOS
    }
}

not only looks daft, it also makes it hard to follow the flow of the
program.

And I'm not even talking about stuff like

print <<S1, 5, <<S2, "\n";
one
S1
two
S2

which is the same as 
print "one\n", 5, "two\n", "\n";
for those who don't know Perl.

A saner variant of here documents is used in a little-known language
called SPL[1], where you can specify an 'indentation character' together
with the terminator. So the example above would look like:

method print_message(verbose) {

    if (verbose) {
	print <<EOS:
	    :This is a 
	    :very long message.
            :
	    :It goes on 
	    :for ever 
	    :and ever.
	EOS;
    } else {
	print <<EOS:
	    :This is a shorter message.
	    :But it is still too long.
	EOS;
    }
}

Much better. 

(yes, I know various ways to get a similar effect in Perl - but they all
include processing the string at run time - or a source filter).

The YAML[2] indentation rules also look ok to me and might serve as a
basis for multiline strings in a programming language.

	hp


[1] http://www.clifford.at/spl/
[2] http://yaml.org/



-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR       | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#20610

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-19 19:37 -0500
Message-ID<50d25de3$0$282$14726298@news.sunsite.dk>
In reply to#20382
On 12/16/2012 11:43 AM, Peter J. Holzer wrote:
> On 2012-12-15 23:34, Robert Klemme <shortcutter@googlemail.com> wrote:
>> On 15.12.2012 18:22, Peter J. Holzer wrote:
>>> But for all various string syntaxes that Perl supports, it's still
>>> missing a sane multiline string syntax.
>>
>> Does it?
>>
> [...]
>> $str=<<MULTI;
>> a line
>> another line
>> yet another line
>> one more line
>> MULTI
>
> Note that I wrote "sane". Here documents aren't sane. They cannot be
> indented with the rest of the code,

If people want a multi-line as-is syntax, then that is a requirement
not a problem.

Arne

[toc] | [prev] | [next] | [standalone]

#20245

FromBGB <cr88192@hotmail.com>
Date2012-12-10 22:03 -0600
Message-ID<ka6bfe$l03$1@news.albasani.net>
In reply to#20234
On 12/10/2012 6:17 PM, Martin Gregorie wrote:
> On Mon, 10 Dec 2012 18:04:33 -0500, Eric Sosman wrote:
>
>
>>       It's unfortunate that both Java and regex use \ so heavily,
>> because it leads to a lot of escaping-of-escapes and harms readability.
>> But why should it be a given that Java's literals should be different to
>> avoid conflict with regex syntax?  Why not change the regex syntax
>> instead, and use, say, ~ for the role now taken by \?  It might improve
>> regexes to the point where they're merely unreadable, instead of
>> intolerable.  ;-)
>
> I've always liked the Awk and Perl default convention of delimiting
> regexes with slashes: /regex/ - if their compilers can deal with this
> cleanly, the Java compiler could surely do the same.
>

FWIW, my language also inherited this syntax as well (from ECMAScript), 
though the regex is essentially otherwise just a variant of a string.

var str = /[0-9]([0-9]|[A-F]|[a-f])+/;

[toc] | [prev] | [next] | [standalone]

#20252

FromJoshua Cranmer <Pidgeot18@verizon.invalid>
Date2012-12-11 10:43 -0600
Message-ID<ka7nsd$8ua$1@dont-email.me>
In reply to#20234
On 12/10/2012 6:17 PM, Martin Gregorie wrote:
> On Mon, 10 Dec 2012 18:04:33 -0500, Eric Sosman wrote:
>
>
>>       It's unfortunate that both Java and regex use \ so heavily,
>> because it leads to a lot of escaping-of-escapes and harms readability.
>> But why should it be a given that Java's literals should be different to
>> avoid conflict with regex syntax?  Why not change the regex syntax
>> instead, and use, say, ~ for the role now taken by \?  It might improve
>> regexes to the point where they're merely unreadable, instead of
>> intolerable.  ;-)
>
> I've always liked the Awk and Perl default convention of delimiting
> regexes with slashes: /regex/ - if their compilers can deal with this
> cleanly, the Java compiler could surely do the same.

Which works really well until you want to match the / character in 
pathnames. Or you want to lex but not parse the language--note that 
/foo/ is lexed as a regex if the preceding token is an operator and 
lexed as a sequence of tokens (DIV, IDENT, DIV) if the preceding token 
is an operator.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#20263

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2012-12-11 22:44 +0000
Message-ID<ka8d10$68v$4@localhost.localdomain>
In reply to#20252
On Tue, 11 Dec 2012 10:43:49 -0600, Joshua Cranmer wrote:

> On 12/10/2012 6:17 PM, Martin Gregorie wrote:
>> On Mon, 10 Dec 2012 18:04:33 -0500, Eric Sosman wrote:
>>
>>
>>>       It's unfortunate that both Java and regex use \ so heavily,
>>> because it leads to a lot of escaping-of-escapes and harms
>>> readability. But why should it be a given that Java's literals should
>>> be different to avoid conflict with regex syntax?  Why not change the
>>> regex syntax instead, and use, say, ~ for the role now taken by \?  It
>>> might improve regexes to the point where they're merely unreadable,
>>> instead of intolerable.  ;-)
>>
>> I've always liked the Awk and Perl default convention of delimiting
>> regexes with slashes: /regex/ - if their compilers can deal with this
>> cleanly, the Java compiler could surely do the same.
> 
> Which works really well until you want to match the / character in
> pathnames. Or you want to lex but not parse the language--note that
> /foo/ is lexed as a regex if the preceding token is an operator and
> lexed as a sequence of tokens (DIV, IDENT, DIV) if the preceding token
> is an operator.
>
So its context sensitive. It that really a huge issue? 

In practice you'll almost never see a regex in Java that isn't a method's 
argument because of the way the regex package was designed. That means 
you'd be in 'parameter context' when parsing it. I can see there'd be 
issues with something like Perl's 'm' syntax, but straight /regex/ 
notation should not be hard to deal with. If you're piecing a regex 
together StringBuilder, again you'd be in 'parameter context' though I 
grant that if you're trying to build a regex by concatenating strings 
with '+' you may have a problem. But, lets face it, doing that is likely 
to be an unreadable mess no matter what syntactic sugar gets sprinkled on 
it.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#20240

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-10 21:09 -0500
Message-ID<50c695f1$0$293$14726298@news.sunsite.dk>
In reply to#20233
On 12/10/2012 6:04 PM, Eric Sosman wrote:
> On 12/10/2012 4:52 PM, Arne Vajhøj wrote:
>> On 12/10/2012 4:22 PM, Eric Sosman wrote:
>>> On 12/10/2012 3:08 PM, Arne Vajhøj wrote:
>>>> [...]
>>>> PS: And for those that do not know C#, then C# has "" strings
>>>>      with \ as escape like Java, but also has @"" string where
>>>>      \ is not an escape and where line change are allowed.
>>>
>>>      As one of "those," and curious: Can a @"" string have an
>>> embedded " character?
>>
>> Yes.
>>
>> An " inside @"" is encoded as "".
>
>      Aha!  Another FORTRAN legacy!  As of FORTRAN IV you could
> write 'I''M HERE' instead of 8HI'M HERE, which most people
> considered a great advance -- in the late 1960's.

Doubling is also used in various Pascal, Basic, SQL.

My guess is that doubling is more common than escaping
in non-C-family languages.

>      My point, of course, is that there's still an escape mechanism
> at work.  It's a different mechanism, yes, but it still has the
> What You See Ain't What You Get problem this thread has been
> complaining about.  And here's a funny thing about inventing an
> escape mechanism: Even if the special character sequences were
> surpassingly uninteresting and spectacularly rare before being
> adopted as escapes, their very adoption makes them suddenly
> interesting and much more common.  You'll find yourself wanting
> to write a regex that looks for "" inside a @"..." string, and
> you'll get something like
>
>      @"@""([^""]*""""")*[^""]*"""
>
> ... leaving you pretty much where you started, just with a new
> suit of clothes on the Emperor.

The doubling mechanism is used only for the string encloser character,
while true escape is used for many other characters as well.

Sp the doubling mechanism should result in fewer problems than
true escape.

Furthermore the suggestion was not to replace the current mechanism
but to supplement it. Which means that one can still pick the current
form if one think that it is more readable for some cases.

>                                  Also, we still need to produce
>
>      "\u0281 is the IPA voiced uvular fricative"
>
> ... on input systems that cannot generate the IPA voiced uvular
> fricative all by themselves.

CHAR(0x0281) // 'is the IPA voiced uvular fricative'

or similar work in other languages.

Arne

[toc] | [prev] | [next] | [standalone]

#20274

FromSebastian <sebastian@undisclosed.invalid>
Date2012-12-12 10:40 +0100
Message-ID<ka9j9m$dfb$1@news.albasani.net>
In reply to#20216
On 12/10/2012 8:43 AM, Arne Vajhøj wrote:
>
> It could be added....
>
> But I would not consider it a high priority.
>
> It is most useful for demo code.
>
> For real code then large chunks of texts would usually
> be stored externally (file, DB etc.) not embedded into
> the code.

I think nobody has mentioned this funny little hack, which just
might be suitable for demo code and unit tests. It requires that the
source code using the multi-line string be accessible in the file
system at run time.

http://blog.efftinge.de/2008/10/multi-line-string-literals-in-java.html

I do believe the blog was posted in a humorous spirit.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#20279

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-12 20:28 -0500
Message-ID<50c92f38$0$290$14726298@news.sunsite.dk>
In reply to#20274
On 12/12/2012 4:40 AM, Sebastian wrote:
> On 12/10/2012 8:43 AM, Arne Vajhøj wrote:
>>
>> It could be added....
>>
>> But I would not consider it a high priority.
>>
>> It is most useful for demo code.
>>
>> For real code then large chunks of texts would usually
>> be stored externally (file, DB etc.) not embedded into
>> the code.
>
> I think nobody has mentioned this funny little hack, which just
> might be suitable for demo code and unit tests. It requires that the
> source code using the multi-line string be accessible in the file
> system at run time.
>
> http://blog.efftinge.de/2008/10/multi-line-string-literals-in-java.html
>
> I do believe the blog was posted in a humorous spirit.

Well - it is funny and not very practical (think more
than one such string), so that seems very plausible.

Arne

[toc] | [prev] | [next] | [standalone]

#20222

FromBGB <cr88192@hotmail.com>
Date2012-12-10 13:42 -0600
Message-ID<ka5e4q$uii$1@news.albasani.net>
In reply to#20211
On 12/10/2012 10:43 AM, Arne Vajhøj wrote:
> On 12/10/2012 11:22 AM, bob smith wrote:
>> Should something be added to the Java language to make multi-line
>> Strings more clear?
>>
>> Maybe like what PHP has?
>>
>> Right now, I have a mess like this:
>>
>>      private final String mLomoishShader =
>>              "precision mediump float;\n" +
>>              "uniform sampler2D tex_sampler_0;\n" +
>
> It could be added.
>
> PHP has it. C# has it.
>

likewise, Lua, as a common extension to JavaScript, ...


in my language, there are several ways of doing it:
var str=
"first line
second line
third line
";

var str=
"""first line
second line
third line
""";

var str=
<[[first line
second line
third line]]>;

where the 3rd form may be nested, but is otherwise about the same as the 
second form.

the main difference between the first form and the latter forms is that 
the first form still interprets \ escapes, whereas the latter forms 
don't use \ escapes.

note, it is also possible to use \ to avoid encoding newlines as well:
"first-word \
	second-word"
where the \ will eat the newline and any following whitespace.


another difference has to do with maximum string length allowed in the 
parser:
the first form is currently limited to around 4096 characters per string 
constant;
the latter forms handle strings of up to 1MB IIRC (it is either a 1MB 
max, or a 1MB initial/expandable buffer, I forget).


> But I would not consider it a high priority.
>
> It is most useful for demo code.
>
> For real code then large chunks of texts would usually
> be stored externally (file, DB etc.) not embedded into
> the code.
>

a lot depends.


at least off in C land, I was using large arrays of strings to represent 
"archives" for embedding collections of smaller resource files into C code.

technically, this was kind of "really annoying and sucked".


a little later on, this was replaced by embedding a WAD-based archive 
format (ExWAD) into the PE/COFF (Windows EXE/DLL) and ELF (Linux 
binary/shared-object) binaries. the WAD is historically related to the 
id Software WAD formats (primarily Quake/Half-Life WAD2), but is not 
exactly the same (different archive header, larger directory entries, 
hierarchical, supports Deflate, ...).

mostly this is used for embedding metadata, script-code, or resource 
data into program binaries (typically post-link). (for example: sticking 
reflection metadata into a DLL so the script VM can use it easier, 
stuffing the class-library into the relevant VM DLLs, ...).


functionally, though, this isn't too much different from embedding 
resource files into the JAR though for Java code.

the main "obvious" difference is mostly that programs like WinZip and 
similar wont be "clever" and assume that it is an archive, mostly 
because they have no understanding of ExWAD.


note that most normal (plain data) data resources have their own files 
or are stored in ZIP-based "pk" files though (for example: 
"resource/data001.pk" for game data), vs say, "resource/gamex86.dll" 
which may contain both Win32 / x86-specific native code, as well as a 
lot of scripting-language code and similar.


or such...

[toc] | [prev] | [next] | [standalone]

#20247

From"William Bonawentura" <nie@ma.mnie.pl>
Date2012-12-11 07:58 +0100
Message-ID<ka6lj0$mgp$1@news2.ipartners.pl>
In reply to#20210
IMHO final code does not need to have any strings literals. Strings should 
be allways created via out-of-code resources.

[toc] | [prev] | [next] | [standalone]

#20250

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-11 10:08 -0500
Message-ID<50c74c8a$0$282$14726298@news.sunsite.dk>
In reply to#20247
On 12/11/2012 1:58 AM, William Bonawentura wrote:
> IMHO final code does not need to have any strings literals. Strings
> should be allways created via out-of-code resources.

In general yes.

There are probably some exceptions. I would not want Java keywords to
come from an external resource for a Java compiler.

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#20251

FromLeif Roar Moldskred <leifm@dimnakorr.com>
Date2012-12-11 09:41 -0600
Message-ID<G--dne94j6a2yVrNnZ2dnUVZ8kydnZ2d@giganews.com>
In reply to#20250
Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/11/2012 1:58 AM, William Bonawentura wrote:
>> IMHO final code does not need to have any strings literals. Strings
>> should be allways created via out-of-code resources.
> 
> In general yes.
> 
> There are probably some exceptions. I would not want Java keywords to
> come from an external resource for a Java compiler.

I'd voice the opinion that for most parsing you'd just confuse the
code if you moved the tokens out into a separate file.

Really, the only Strings literals that _should_ be moved out into a
resource file are values which should be made configurable _anyway_
and any Strings intended, directly or indirectly, for (human-readable)
output (including log-files and similar). Remaining literals will all
have a semantic meaning either directly in the code or in an API (for
example, the key-names in a JSON structure) and should not be hidden
behind a pointless layer of indirection.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web