Здравствуйте, hardcase, Вы писали:
H>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму к r9078. Кому интересно, может посмотреть и ужаснуться.
Парсер пристыкован к компилятору в r9249.
С помощью SharpDevelop теперь возможно создавать Windows-формы на C# и компилировать их ncc.
Внимание: судя по тестам (csparser) на достаточно больших исходных текстах (SharpDevelop IDE, Janus, RServer, SharedSource CLR Implementation) в парсере нехаватет лишь поддержки директив препроцессора, в остальном он способен разбирать корректные исходные тексты на C#.
Здравствуйте, hardcase, Вы писали:
H>Внимание: судя по тестам (csparser) на достаточно больших исходных текстах (SharpDevelop IDE, Janus, RServer, SharedSource CLR Implementation) в парсере нехаватет лишь поддержки директив препроцессора, в остальном он способен разбирать корректные исходные тексты на C#.
Давно пора реализовать обработку препроцессора. Там дел-то на пару часов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Давно пора реализовать обработку препроцессора. Там дел-то на пару часов.
Просто там только если делать в два прохода.
Ибо код C# код препроцессора фактически два разных языка переплетающихся в одном файле.
Если же делать в один проход то нужно что-то изобретать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
VD>>Давно пора реализовать обработку препроцессора. Там дел-то на пару часов. WH>Просто там только если делать в два прохода. WH>Ибо код C# код препроцессора фактически два разных языка переплетающихся в одном файле. WH>Если же делать в один проход то нужно что-то изобретать.
Препроцессор настолько примитивен, что его даже руками можно реализовать.
В немерловом лексере он сделан в один проход. Но можно и в два. На это времени почти не уйдет.
ЗЫ
Кстати, для разбора этого дела средствами парсера можно было бы задействовать те самые точки расширения.
В теле #if-а можно было бы менять точку расширения в правиле парсинга пробелов в зависимости от значения выражения #if-а.
Если оно вычисляется в TRUE, в точку расширения запихивать правило которое пропускает все до следующего #endif или #else. Если выражение вычисляется в FALSE, то подставлять обычное правило пропуска пробелов.
При этом останется только корректно среагировать на #endif того #if-а кондишон которого вычислился в FALSE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AngeL B., Вы писали:
AB>эээээ, то есть я правильно понимаю, что компилятор ncc теперь умеет компилировать сразу два языка в зависимости от расширения в рамках одного проекта?
Yep.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AngeL B., Вы писали:
AB>эээээ, то есть я правильно понимаю, что компилятор ncc теперь умеет компилировать сразу два языка в зависимости от расширения в рамках одного проекта?
Да. Но второй язык поддерживается не на 100%.
Во-первых, пока что не поддерживается препроцессор. Но это скоро устраним.
Во-вторых, не все возможности C# 4.0 поддерживаются полностью.
В-третьих, это не совсем C#. Синтаксис поддерживается на 100%, а вот семантика — нет. Фактически — это автоматический конвертер из C# 4.0 в Nemerle, так что в тех случаях когда семантика (поведение) немерла отличается от шарповской, компилируемый код будет вести себя не так как C# 4.0, а как Nemerle. Простейший пример — работа с лямбдами. В отличии от шарпа в немреле есть функциональный тип, так что код вроде:
var f = x => x * x;
WriteLine(f(3));
Будет некорректен с точки зрения шарпа, но корректно с точки зрения немерла, так что оно пройдет компиляцию.
Кроме того будет работать вывод типов немерла.
В основном Немерл расширяет семантику шарпа, так что в большинстве случаев код будет компилироваться, но иногда может встретиться и несоответствие. Надеюсь, что таких случаев будет не много, так как в основном они сводятся к тому, что известно под названием "Этюды Никова" .
Так что можно подключать к проекту немерла имеющиеся исходники на C# и развивать их уже на немреле.
Работают даже partial-классы. Так что можно иметь часть класса на Nemerle, а часть на C#.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
VD>>Работают даже partial-классы. Так что можно иметь часть класса на Nemerle, а часть на C#.
H>Кстати тут и отличие. Ncc потребует указать для всех частей одинаковые модификаторы доступа.
А шарп нет?
Ну, это уже мелочи, думаю... Таких отличий может быть много.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>Только что замечено: автокомплит SharpDevelop в *.cs файлах подсасывает информацию, полученную из *.n файлов.
VD>Чё? Я не представляю как такое возможно.
Видимо всему виной Class View. SD поддерживает его автоматически:
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, hardcase, Вы писали:
H>>Парсер C#4.0, генерирующий AST, вроде как принял законченную форму к r9078. Кому интересно, может посмотреть и ужаснуться.
Теперь посмотреть можно проще: добавил парсер C# в секцию "PowerPack" инсталлятора.
Здравствуйте, hardcase, Вы писали:
H>Заставил компилировться XAML-разметку. H>Для этого пришлось сделать очень смешную вещь в Nemerle.MSBuild.targets:
H>
Здравствуйте, hardcase, Вы писали:
H>Заставил компилировться XAML-разметку. H>Для этого пришлось сделать очень смешную вещь в Nemerle.MSBuild.targets:
H>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, hardcase, Вы писали:
H>>Заставил компилировться XAML-разметку. H>>Для этого пришлось сделать очень смешную вещь в Nemerle.MSBuild.targets:
H>>
Ну, этот хак я сделал у себя локально, ради теста.
Я эти свойства используются для компиляции XAML файлов, возможно файлы моделей EntityFramework также их используют.
Студию не проверял, а SharpDevelop-ный дизайнер виндовсформс на эту настройку точно не смотрит (только на xxx.Designer.cs).
В студии визуальный дизайнер WPF не загружается — жалуется что Немерловая интеграция ему null где-то вертает, но XAML редактировать позволяет. В SharpDevelop визуального дизайнера нет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AngeL B., Вы писали:
AB>>эээээ, то есть я правильно понимаю, что компилятор ncc теперь умеет компилировать сразу два языка в зависимости от расширения в рамках одного проекта?
VD>Да.
а как на практике эту фичу заюзать??? Простого добавления файла *.cs в проэкт недостаточно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Jack128, Вы писали:
J>>а как на практике эту фичу заюзать??? Простого добавления файла *.cs в проэкт недостаточно.
VD>Достаточно. Просто для этого нужно использовать последнюю версию компилятора которая еще не доступна в виде инсталлятора.
VD>Чтобы попробовать это дело можно самостоятельно собрать проект: VD>http://nemerle.googlecode.com/svn/nemerle/trunk/snippets/peg-parser/CSharp/CSharpParser.sln VD>и скопировать получившиеся файлы в каталог где установлен Nemerle (по умолчанию %ProgramFiles%\Nemerle).
Угу, работает, сенкс. Правда студия ошибки показывает, но компилит..
Здравствуйте, Jack128, Вы писали:
J>Угу, работает, сенкс. Правда студия ошибки показывает, но компилит..
Это интеллисенс от MS. Он ни о C# 4.0, ни о Nemerle ничего не знает. Так что комплитить он будет только то, что есть в этом файле и некотором наборе (который известен только кому-то из MS) стандартных сборок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
J>>Угу, работает, сенкс. Правда студия ошибки показывает, но компилит..
VD>Это интеллисенс от MS. Он ни о C# 4.0, ни о Nemerle ничего не знает. Так что комплитить он будет только то, что есть в этом файле и некотором наборе (который известен только кому-то из MS) стандартных сборок.
Извиняюсь... прочел "комплитит" вместо "компилит".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
при подключении такого файлика cs файлика к nemerle проэкту при компиляции вылазит ошибка:
Error 21 bad method name C:\Users\Женя\Documents\Visual Studio 2008\Projects\Project1\WindowsFormsApplication3\WindowsFormsApplication3\Maybe.cs 60 10 WindowsFormsApplication3
на вот этом методе: public static Maybe<U> SelectMany<T, U>(
this Maybe<T> m,
Func<T, Maybe<U>> k)
using System;
using System.Collections.Generic;
using System.Linq;
namespace Es.Common.Monads
{
public class Maybe<T> : IEquatable<Maybe<T>>
{
public readonly static Maybe<T> Nothing = new Maybe<T>();
public T Value { get; private set; }
public bool HasValue { get; private set; }
Maybe()
{
HasValue = false;
}
public Maybe(T value)
{
Value = value;
// ReSharper disable RedundantCast
HasValue = ((object)value != null);
// ReSharper restore RedundantCast
}
public bool Equals(Maybe<T> other)
{
if (ReferenceEquals(null, other)) return false;
if (ReferenceEquals(this, other)) return true;
return Equals(other.Value, Value) && other.HasValue.Equals(HasValue);
}
public override bool Equals(object obj)
{
if (ReferenceEquals(null, obj)) return false;
if (ReferenceEquals(this, obj)) return true;
if (obj.GetType() != typeof (Maybe<T>)) return false;
return Equals((Maybe<T>) obj);
}
public override int GetHashCode()
{
unchecked
{
return (Value.GetHashCode() * 397) ^ HasValue.GetHashCode();
}
}
public static bool operator ==(Maybe<T> left, Maybe<T> right)
{
return Equals(left, right);
}
public static bool operator !=(Maybe<T> left, Maybe<T> right)
{
return !Equals(left, right);
}
}
public static class MaybeExtentions
{
public static Maybe<U> SelectMany<T, U>(
this Maybe<T> m,
Func<T, Maybe<U>> k)
{
return m.HasValue ? k(m.Value) : Maybe<U>.Nothing;
}
public static Maybe<V> SelectMany<T, U, V>(
this Maybe<T> m,
Func<T, Maybe<U>> k,
Func<T, U, V> s)
{
return m.SelectMany(x => k(x).SelectMany(y => s(x, y).ToMaybe()));
}
public static Maybe<T> ToMaybe<T>(this T value)
{
return new Maybe<T>(value);
}
}
}
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, hardcase, Вы писали:
J>при подключении такого файлика cs файлика к nemerle проэкту при компиляции вылазит ошибка:
Попытался воспроизвести этот баг на самом Nemerle:
using System;
using System.Console;
using System.Linq;
public class Maybe[T]
{
public static Nothing : Maybe[T] = Maybe();
public Value : T { get; private set; }
public HasValue : bool { get; private set; }
}
public module Program
{
public static SelectMany[T, U](this m : Maybe[T], k : Func[T, Maybe[U]]) : Maybe[U]
{
if (m.HasValue) k(m.Value) else Maybe.Nothing;
}
public static SelectMany[T, U, V](
this m : Maybe[T],
k : Func[T, Maybe[U]],
s : Func[T, U, V]) : Maybe[V]
{
m.SelectMany(x => k(x).SelectMany(y => s(x, y).ToMaybe()))
}
public static ToMaybe[T](this _value : T) : Maybe[T] { null }
Main() : void { }
}
Код успешно компилируется.
Так что одно из трех:
1. Ошибка все же в конверторе C# -> Nemerle.
2. Я не смог воспроизвести проблему.
3. Я пофиксил данную проблему в последнем комите.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>3. Я пофиксил данную проблему в последнем комите.
Мало-вероятно. Я поставил точку останова в то место обнаруживается зацикливание кортежа, но управление туда не пришло. Так что надо искать ошибку в другом месте.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Jack128, Вы писали: J>>а как на практике эту фичу заюзать??? Простого добавления файла *.cs в проэкт недостаточно. VD>Достаточно. Просто для этого нужно использовать последнюю версию компилятора которая еще не доступна в виде инсталлятора.
А есть где список неподдерживаемых фич? Я так понимаю нет goto, наверное, еще что-то.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Jack128, Вы писали: J>>>а как на практике эту фичу заюзать??? Простого добавления файла *.cs в проэкт недостаточно. VD>>Достаточно. Просто для этого нужно использовать последнюю версию компилятора которая еще не доступна в виде инсталлятора.
ВВ>А есть где список неподдерживаемых фич? Я так понимаю нет goto, наверное, еще что-то.
было. H>Как появится свободное время, соберу все в одном месте.
Да, это было бы полезно.
H>Ко всему прочему еще не в полной мере работают операторы присваивания и инкремента/декремента (сейчас они имею семантику Nemerle и возвращают void).
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Я так понимаю и присваивание возвращает void?
Имеенно.
К сожалению (или счастью?), являясь крайне ленивым человеком, я никак не соберусь отрехакторить конвертер (вернее я уже пытался, но звезды не сошлись на небе) и наконец добавить пару воркэраундов для инкрементов и присваиваний.
Я так понимаю, этот список не совсем точен. ref/out прикрутили (?). Но при этом операции типа инкремента и присваивания работают не так, как в Шарпе. Может, еще какие вещи.
Здравствуйте, VladD2, Вы писали:
ВВ>>А есть где список неподдерживаемых фич? Я так понимаю нет goto, наверное, еще что-то. VD>Как раз goto можно и реализовать. Сложнее буде реализовать goto case.
Почему? По идее особой разницы тут быть не должно.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
ВВ>>>А есть где список неподдерживаемых фич? Я так понимаю нет goto, наверное, еще что-то. VD>>http://rsdn.ru/forum/nemerle/3945731.1.aspx
Здравствуйте, VladD2, Вы писали:
ВВ>>Но при этом операции типа инкремента и присваивания работают не так, как в Шарпе. VD>Не уверен. Они в приципе могут быть реализованы не через немерловые макры ++ и --, а через: VD>
VD><[ { $x++; $x } ]>
VD>
VD>или что-то вроде того. ВВ>>Может, еще какие вещи.
Хардкейс говорит, что такого нет. Понятно в принципе, что это не должно быть большой проблемой в реализации. Не уверен, впрочем, что и отсутствие этого является большой проблемой.
Хотелось бы просто увидеть полный актуальный список, так сказать.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Почему? По идее особой разницы тут быть не должно.
В типизированном AST есть аналог goto. А вот в match такого аналога нет. Эмулирвоать конечно можно, но объем работ будет существенно больше. "goto" же можно реализовать за пол часа.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Хардкейс говорит, что такого нет. Понятно в принципе, что это не должно быть большой проблемой в реализации. Не уверен, впрочем, что и отсутствие этого является большой проблемой.
+1
ВВ>Хотелось бы просто увидеть полный актуальный список, так сказать.
Я поправил тот список. Если еще что-то найдете, сообщите мне, я поправлю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ВВ>>Почему? По идее особой разницы тут быть не должно. VD>В типизированном AST есть аналог goto. А вот в match такого аналога нет. Эмулирвоать конечно можно, но объем работ будет существенно больше. "goto" же можно реализовать за пол часа.
Ну т.е. в AST есть понятие goto, значит должно быть и понятие label? На первый взгляд все, что нужно сделать — это генерировать лабел для каждого вхождения матча. Или я не вижу какие-то нюансы?
Просто дело в том, что raw goto как раз используется очень редко, тогда как goto case/goto default все же почаще.
Re[10]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну т.е. в AST есть понятие goto, значит должно быть и понятие label? На первый взгляд все, что нужно сделать — это генерировать лабел для каждого вхождения матча. Или я не вижу какие-то нюансы?
TExpr.Goto и TExpr.Label, но есть ньюансик — нужно типизировать тело, думаю, задача решается с использованием какого-нить вспомогательного макроса, который типизирует блок и изготовит переход на метку.
ВВ>Просто дело в том, что raw goto как раз используется очень редко, тогда как goto case/goto default все же почаще.
Это сильно сложнее, так как нужно разбираться с лапшой, в которую превращается match после работы DecisionTreeCompiler-а.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[10]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Просто дело в том, что raw goto как раз используется очень редко, тогда как goto case/goto default все же почаще.
Хмм. Я вот ни разу не пользовался goto case или goto default. Только простейшим goto.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[11]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, hardcase, Вы писали:
ВВ>>Просто дело в том, что raw goto как раз используется очень редко, тогда как goto case/goto default все же почаще. H>Это сильно сложнее, так как нужно разбираться с лапшой, в которую превращается match после работы DecisionTreeCompiler-а.
А зачем разбираться с лапшой? Ты же транслируешь C# AST в AST Немерле, т.е. можно просто тупо считать, что каждый case в шарповом свитче — это создание метки. Именем метки может быть индекс кейса, т.е. номер, под которым он идет в теле switch-а.
Re[10]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну т.е. в AST есть понятие goto, значит должно быть и понятие label?
Естественно.
ВВ>На первый взгляд все, что нужно сделать — это генерировать лабел для каждого вхождения матча. Или я не вижу какие-то нюансы?
Много работы. Причем не тривиальной. Но реализовать конечно можно.
ВВ>Просто дело в том, что raw goto как раз используется очень редко, тогда как goto case/goto default все же почаще.
Тем кто использует goto вообще надо ноги отрывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Много работы. Причем не тривиальной. Но реализовать конечно можно.
Со стороны, конечно, совсем не понятно, почему много Казалось бы, нужно просто генерить лабель для каждого кейса в шарповом switch-е.
ВВ>>Просто дело в том, что raw goto как раз используется очень редко, тогда как goto case/goto default все же почаще. VD>Тем кто использует goto вообще надо ноги отрывать.
Э, тут надо быть осторожнее return — это ж тоже по сути подвид goto. И так, глядишь, все C#-программисты без ног останутся.
За корутины, кстати, тоже ноги надо отрывать?
Re[12]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Просто дело в том, что raw goto как раз используется очень редко, тогда как goto case/goto default все же почаще. VD>>Тем кто использует goto вообще надо ноги отрывать.
ВВ>Э, тут надо быть осторожнее return — это ж тоже по сути подвид goto. И так, глядишь, все C#-программисты без ног останутся.
ВВ>За корутины, кстати, тоже ноги надо отрывать?
Вот за подобное и...во тебе минусы и ставят.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, VladD2, Вы писали:
ВВ>>Э, тут надо быть осторожнее return — это ж тоже по сути подвид goto. И так, глядишь, все C#-программисты без ног останутся. ВВ>>За корутины, кстати, тоже ноги надо отрывать? VD>Вот за подобное и...во тебе минусы и ставят.
Ну вот я правда не понимаю, чем простое скромное goto хуже корутины, когда мы прыгаем из одной функции в другую. Тот же goto, вид сбоку. И да, можешь поставить мне минус.
Re[11]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, hardcase, Вы писали:
H>Это сильно сложнее, так как нужно разбираться с лапшой, в которую превращается match после работы DecisionTreeCompiler-а.
А если case в который делается goto завернуть в локальную функцию?
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
ВВ>>>Э, тут надо быть осторожнее return — это ж тоже по сути подвид goto. И так, глядишь, все C#-программисты без ног останутся. ВВ>>>За корутины, кстати, тоже ноги надо отрывать? VD>>Вот за подобное и...во тебе минусы и ставят.
ВВ>Ну вот я правда не понимаю, чем простое скромное goto хуже корутины, когда мы прыгаем из одной функции в другую. Тот же goto, вид сбоку. И да, можешь поставить мне минус.
If тоже подвид goto, и match в какой-то степени тоже. Но if, match, return и корутины код разъясняют, а чистый goto запутывает.
Re[11]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, hardcase, Вы писали:
H>TExpr.Goto и TExpr.Label, но есть ньюансик — нужно типизировать тело, думаю, задача решается с использованием какого-нить вспомогательного макроса, который типизирует блок и изготовит переход на метку.
Не надо ничего типизировать.
Зоворачиваешь TExpr.Goto и TExpr.Label в PExpr.Typed и вперед. Можно даже через квази-цитату <[ $(texpr : typed) ]>.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, hardcase, Вы писали:
H>Это сильно сложнее, так как нужно разбираться с лапшой, в которую превращается match после работы DecisionTreeCompiler-а.
В принципе это опять же можно сделать до типизации. Просто влепить в начало вхождений по лэйблу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А зачем разбираться с лапшой? Ты же транслируешь C# AST в AST Немерле, т.е. можно просто тупо считать, что каждый case в шарповом свитче — это создание метки. Именем метки может быть индекс кейса, т.е. номер, под которым он идет в теле switch-а.
Да, так можно. Но есть одна проблема. Дело в том, что при преобразовании match-а иногда выражения дублируются (копируются). Это может привести к непредсказуемым последствиям.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, catbert, Вы писали:
C>If тоже подвид goto, и match в какой-то степени тоже. Но if, match, return и корутины код разъясняют, а чистый goto запутывает.
Можно еще проще сказать if, match, return и т.п. — это конструкции структурного программирования, а goto средство обфускации кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, VladD2, Вы писали:
C>>If тоже подвид goto, и match в какой-то степени тоже. Но if, match, return и корутины код разъясняют, а чистый goto запутывает. VD>Можно еще проще сказать if, match, return и т.п. — это конструкции структурного программирования, а goto средство обфускации кода.
Выход из цикла? — break, "структурное программирование".
Выход из двух циклов сразу?
Re[17]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Выход из цикла? — break, "структурное программирование".
Ага — структурное, так как ясно откуда и куда осуществляется выход.
ВВ>Выход из двух циклов сразу?
Да хоть из трех — блок немерла:
[img]
exitAllLoops :
{
foreach (...)
foreach (...)
foreach (...)
when (cond)
exitAllLoops(returnValue); // может ничего не возвращать, если тип блока — void
value
}
[/img]
break реализован на его базе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, VladD2, Вы писали:
VD>Зоворачиваешь TExpr.Goto и TExpr.Label в PExpr.Typed и вперед. Можно даже через квази-цитату <[ $(texpr : typed) ]>.
Я правильно понял, что TExpr.Label должен быть с пустым блоком?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[13]: Компиляция C# 4.0 в рамках проекта Nemerle
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, hardcase, Вы писали:
J>при подключении такого файлика cs файлика к nemerle проэкту при компиляции вылазит ошибка: