Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Functional > Re: Better synt...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 5 of 7 Topic 2771 of 3037
Post > Topic >>

Re: Better syntax for a Standard ML derivative

by Jon Harrop <usenet@[EMAIL PROTECTED] > Feb 15, 2008 at 08:53 PM

Joachim Durchholz wrote:
> Am Freitag, den 15.02.2008, 06:10 +0000 schrieb Jon Harrop:
>> Joachim Durchholz wrote:
>> > Just to complement Jon's view: I don't think there are any *serious*
>> > problems with recovering indented code from web pages or mail quotes.
>> > Just make sure that whitespace is properly handed through, that's
all,
>> > and it's not even difficult. Hey, Evolution will even strip the angle
>> > brackets when copying from quoted mail ;-)
>> 
>> Ugh. I was bitten by this *again* yesterday, trying to cut and paste
some
>> F# code from a blog article and Windows removed all "\n"s.
> 
> Strange - I wouldn't have expected to lose line breaks when copying from
> a web page. Possibly it was formatted using <br />, though even then,
> the line breaks should be preserved. This sounds like something awfully
> braindamaged happening in the database->blog->server->browser chain.
> 
> If code is represented using <pre>, you should get everything (including
> indentation) faithfully preserved on copy&paste. I could imagine that
> tab-based indentation could still break in some cir***stances, but I
> wouldn't recommend using that anyway.

The code was color syntax highlighted:

http://jyliao.blogspot.com/2008/02/learning-wpf-with-f-toolbars-and-status.html

>> In the end I used
>> my Linux box to cut and paste into a text file that I loaded into the
>> Windows box using putty and then cut and pasted that (correctly
>> formatted) into Visual Studio...
> 
> Sounds like brain damage in your browser.

MSIE 7.

> Copying from the source might have worked, too.

The source HTML looks like:

<span style="color:#008000;">//</span><br><span style="color:#008000;">//
Defining drop function...couldn't find a Seq equivalent</span><br><span
style="color:#008000;">// I see Seq.take and Seq.truncate but no
Seq.drop</span><br><span style="color:#0000FF;">let</span><span
style="color:#;"> </span><span style="color:#0000FF;">rec</span><span
style="color:#;"> seqdrop n (list:seq&lt;'a&gt;) =</span><br><span
style="color:#;">   </span><span style="color:#0000FF;">if</span><span
style="color:#;"> n&lt;=0 </span><span
style="color:#0000FF;">then</span><span style="color:#;">
list</span><br><span style="color:#;">   </span><span
style="color:#0000FF;">else</span><br><span style="color:#;">     
</span><span style="color:#0000FF;">match</span><span style="color:#;">
(List.of_seq list) </span><span style="color:#0000FF;">with</span><span
style="color:#;"> </span><br><span style="color:#;">      | _ :: []
</span>
....

>> > The argument for indentation is that you indent your code anyway, so
>> > why specify nesting with both keywords and indentation? That's just
>> > silly.
>> 
>> Turn autoindenting on!
> 
> I tend to never get the indenting style that I want. For some reason,
> most IDEs insist on stuff like
>   if (...)
>   {
>     ...
>   }
> where aesthetics wins over vertical space.

The OCaml autoindenter is great, IMHO. Hit ALT+Q and it renindents the
current block of code. I'd much rather have that than a whitespace-
sensitive syntax.

>> > Besides, keywords eat vertical screen estate (if only for the closing
>> > brace or the "end" keyword), and that's a real restriction: the more
>> > code you can see on a screenful, the easier it is to put its
>> > constituents into proper perspective.
>> 
>> True. I think the IDE should compact those keywords though.
> 
> Probably there should be alternate syntax with and without block-end
> tokens, with means to automatically convert between them (initially,
> that would probably be a function of the compiler, later, IDEs would
> catch on and convert on the fly at the flick of an option switch).

I like Torben's idea of making "end" optional. I think that would work
well...

>> Same goes
>> for "+." in OCaml, which should by typeset as "+" in an IDE.
> 
> I don't think that should be done. I'd want to see what addition is
> meant, particularly if the code is polymorphic (unless it's impossible
> to have Integer/Real polymorphism in OCaml).

You can copy the ad-hoc polymorphism of SML but its useless because it
can't
be extended to float32, vector, matrix, quaternions etc.

Regardless, type throwback already solved the problem you're referring to.
F# provides all of these benefits and it works beautifully, a dream come
true!

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
 




 7 Posts in Topic:
Re: Better syntax for a Standard ML derivative
Joachim Durchholz <jo@  2008-02-13 16:49:31 
Re: Better syntax for a Standard ML derivative
"David B. Benson&quo  2008-02-13 14:25:08 
Re: Better syntax for a Standard ML derivative
Jon Harrop <usenet@[EM  2008-02-15 06:10:54 
Re: Better syntax for a Standard ML derivative
Joachim Durchholz <jo@  2008-02-15 11:30:43 
Re: Better syntax for a Standard ML derivative
Jon Harrop <usenet@[EM  2008-02-15 20:53:30 
Re: Better syntax for a Standard ML derivative
Joachim Durchholz <jo@  2008-02-15 22:43:25 
Re: Better syntax for a Standard ML derivative
Jon Harrop <usenet@[EM  2008-02-16 01:47:31 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Sat Oct 11 6:21:27 CDT 2008.