headers
Ingo | 1 Jul 2006 09:18
Picon
Picon

Re: Scala Eclipse Plug-in 2.3.7

Hi Sean,

Is the source code of the Eclipse plug-in available, e.g. via SVN? Is it 
possible to contribute to it? I am new to Scala and this has probably 
been asked here already, but I haven't found anything tangible.

Thanks,
Ingo

Sean McDirmid wrote:
 > Hi,
 >
 > I'd like to announce that the latest version of the Scala Eclipse
 > plug-in (2.3.7), which includes the latest Scala compiler and early
 > support for debugging (including hot code replacement!). Its available
 > at at http://lamp.epfl.ch/~mcdirmid/scala-plugin (as a remote update 
site).
 >
 > Thanks,
 >
 > Sean
 >
Permalink | Reply | 1 comment |
headers
martin odersky | 1 Jul 2006 11:35
Picon
Picon
Favicon

Re: Multiline string literals

Michal Politowski wrote:
> I would probably also like just changing "standard string literals"
> to be multiline and raw, but this out of the question, I guess.
>
>   
Yes. One of the main design objectives of Scala is to be unsurprising to 
a Java programmer. Certainly string literals should behave the same way. 
The "no surprise" principle was never formalized in relation to other 
languages. It would be impossible anyway to offer no surprises 
regardless of which language someone comes from.

I still like the """...""" syntax, because:

 - to a Java programmer it looks like some sort of string, unlike the 
other proposals, which might admittedly sometimes read better.

 - At the same time, it looks different enough from a plain string so 
that we can justify the switch to raw.

Anyway, it's nice to see a lively discussion on this topic.

 -- Martin
Permalink | Reply | 4 comments |
headers
Lex Spoon | 1 Jul 2006 13:07
Picon
Favicon

Re: Multiline string literals

"John Williams" <shponglespore <at> gmail.com> writes:

> On 30 Jun 2006 14:45:57 +0200, Lex Spoon <lex <at> cc.gatech.edu> wrote:
> > These actually strike my eye maybe even better than """.  """, to me,
> > first reads as a jarring syntax error.  :) How do --- and === look to
> > others?  Or are there any other ideas on how to mark a raw string?
> 
> Those symbols look OK, but aren't they both valid Scala identifiers?
> My best idea so far would be {{...}} or {{{...}}}; I can't think of
> any reason why someone would normally nest curly braces this way.

Good point.  {{...}} has a current meaning, but it is probably not
useful.

Yes, --- and === are legal operators, but they probably are not used a
lot right now.  Ross likes them, though, and I could believe they are
used an epsilon above zero, whereas {{ }} is probably not used at all.

All of them seem available enough to take them over.  So which looks
best?

    ---this is a
    multi line
    string---

    ===this is a
    multi line
    string===

    {{this is a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Matthias Aust | 1 Jul 2006 14:39
Picon

Re: Scala Eclipse Plug-in 2.3.7

Ingo schrieb:

> Is the source code of the Eclipse plug-in available, e.g. via SVN? Is it
> possible to contribute to it? I am new to Scala and this has probably
> been asked here already, but I haven't found anything tangible.

Looks like most (or all) of the source can be found here:

 http://scalasvn.epfl.ch/cgi-bin/viewvc.cgi/plugin/

--

-- 
Stefan Matthias Aust
Permalink | Reply | 0 comments |
headers
Judson, Ross | 1 Jul 2006 16:45
Favicon

XML mode curly brace

I put an embedded stylesheet into an XML literal in Scala today, and
quickly noticed that the CSS curly brace caused a switch to Scala mode.
I'm not sure if I have the most recent version of the language spec, but
it appears not to mention how to "escape" the curly brace.  I pulled up
MarkupParsers.scala to have a look at the "other" reference, and noted:

A double curly brace "{{" is the escape pattern to get a curly brace, so
embedded CSS looks like this:

val styleSheet = 
  <style type="text/css">
    table {{ border="1" cellspacing="0" }
    pre {{ background:#FFFF77; }
    body {{ background:#EEEEEE; }
  </style>

RJ
Permalink | Reply | 4 comments |
headers
Burak Emir | 1 Jul 2006 17:24
Picon
Picon
Favicon

Re: XML mode curly brace

Yes, indeed, that's a feature.

The relevant spec language is found on page 90 (but I realized that it's 
somehow messed up, the braces do not appear in my pdf).

We're basically following XQuery but maybe we should also double the 
closing brace (to make our dated emacs-mode happy).

Could you get around all that by enclosing your CSS in an <!-- XML 
comment -->?

cheers,
Burak

Judson, Ross wrote:

>I put an embedded stylesheet into an XML literal in Scala today, and
>quickly noticed that the CSS curly brace caused a switch to Scala mode.
>I'm not sure if I have the most recent version of the language spec, but
>it appears not to mention how to "escape" the curly brace.  I pulled up
>MarkupParsers.scala to have a look at the "other" reference, and noted:
>
>A double curly brace "{{" is the escape pattern to get a curly brace, so
>embedded CSS looks like this:
>
>val styleSheet = 
>  <style type="text/css">
>    table {{ border="1" cellspacing="0" }
>    pre {{ background:#FFFF77; }
>    body {{ background:#EEEEEE; }
(Continue reading)

Permalink | Reply | 3 comments |
headers
Burak Emir | 1 Jul 2006 17:35
Picon
Picon
Favicon

Re: Multiline string literals

martin odersky wrote:

> Michal Politowski wrote:
>
>> I would probably also like just changing "standard string literals"
>> to be multiline and raw, but this out of the question, I guess.
>>
>>   
>
> Yes. One of the main design objectives of Scala is to be unsurprising 
> to a Java programmer. Certainly string literals should behave the same 
> way. The "no surprise" principle was never formalized in relation to 
> other languages. It would be impossible anyway to offer no surprises 
> regardless of which language someone comes from.
>
> I still like the """...""" syntax, because:
>
Despite the danger of being labeled a blind XML advocate just because I 
happened to read its spec, we would have those multiline literals 
already if we allowed XML comments as xml expressions

val foo = <!-- this is
  a multi-line
  string and all
  whitespace, funny characters
  and whatnot is preserved {{{&&&"""\n\n\n -->.commentText

The only restriction is, comment text may not contain the sequence "-->".

Currently, having an xml comment top-level is not allowed, because the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Burak Emir | 1 Jul 2006 19:04
Picon
Picon
Favicon

addendum Re: Multiline string literals

Burak Emir wrote:

> val foo = <!-- this is
>  a multi-line
>  string and all
>  whitespace, funny characters
>  and whatnot is preserved {{{&&&"""\n\n\n -->.commentText
>
> The only restriction is, comment text may not contain the sequence "-->".

oops, make that "--".

I liked the idea, and checked in some changes! I don't see how it can 
offend anyone, given the minimal nature of the change.

If anybody still misses multiline string literals, feel free to add 
them, but IMHO there's much less reason to do so now.

So the following source file will now pass (spec is below)
---
object Test extends Application {
  val com = <!-- thissa comment -->
  val pi  = <?this is a pi foo bar = && {{ ?>
  val crz = <![CDATA[
"Come, come again, whoever you are, come!
Heathen, fire worshipper or idolatrous, come!
Come even if you broke your penitence a hundred times,
Ours is the portal of hope, come as you are."
                              Mevlana Celaleddin Rumi
]]>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Judson, Ross | 1 Jul 2006 20:13
Favicon

RE: XML mode curly brace

Yup -- I see the reference there.  I looked for it in the "lexical
syntax" part of the reference, at the beginning...

RJ
Permalink | Reply | 0 comments |
headers
John Williams | 1 Jul 2006 20:34
Picon

Re: Multiline string literals

On 7/1/06, martin odersky <martin.odersky <at> epfl.ch> wrote:
> Yes. One of the main design objectives of Scala is to be unsurprising to
> a Java programmer. Certainly string literals should behave the same way.
> The "no surprise" principle was never formalized in relation to other
> languages. It would be impossible anyway to offer no surprises
> regardless of which language someone comes from.

I think there are really two principles hiding in your "no surprise" principle:

1. Scala syntax that looks like Java syntax should have the same meaning.
2. The meaning of Scala syntax should be transparent to a Java programmer.

Scala follows #1 very well, but that principle doesn't offer a lot of
guidance in this case; the only idea in this thread that would violate
#1 is to change the meaning of regular strings. I think #2 is also a
good principle that should be followed when possible, but it can't be
given too much weight because virtually any change from Java violates
#2 to some extent.

There are some other issues that are unique to strings. For one thing,
I expect most Scala programmers to use some sort of syntax
highlighting which would make it entirely obvious what is and is not a
string. Another point is that even if the syntax for raw/multiline
strings is totally alien, most such strings are easy to pick out of
code because they contain either natrual language or some embedded
language (regexp, SQL, etc.) that looks nothing like the host langage.

The conclusion I draw from all of this is that while """...""" is a
nice sytnax for strings, the fact that it looks "string-like" isn't a
compelling reason to choose it over some other syntax.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane