LINUX.ORG.RU

Вышел Ceylon M5 «Nesa Pong»

 ,


0

3

Вышла очередная версия Ceylon - языка программирования со статической типизацией для платформ JVM и JavaScript, разрабатываемого Red Hat.

Основные новые возможности этой версии:

  • Типизация параметров на этапе выполнения (реификация) для generic-типов. Эта возможность давно поддерживается в .NET, но не в Java.
  • Прямое взаимодействие с JavaScript-кодом, с поддержкой динамической типизации, с помощью блока dynamic.
  • Кортежи (tuples).
  • Множество мелких изменений и добавлений синтаксиса, в основном относящихся к категории синтаксического сахара.
  • API даты/времени на основе JSR-310 (javax.time).
  • HTTP-сервер.

Из спецификации языка пока остаются нереализованными:

  • Типобезопасная метамодель.
  • Аннотации, определённые пользователем.
  • Сериализация.

Вместе с самой платформой, как всегда, вышла новая версия Ceylon IDE - плагина для Eclipse. Инструкции по установке находятся здесь.

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 2)

Ответ на: комментарий от reserved

Ну это как на машине. Заявлено что есть отсечка, т.е. как бы на педаль не давил, больше 8000 не раскрутишь движок, но есть кнопка которую водитель может нажать и раскрутить движок пока он не накроется.
С одной стороны заявлено что есть отсчека, а с другой стороны есть шанс увидеть «руку друга».

vada ★★★★★
()
Ответ на: комментарий от vada

Я всё-таки не понимаю, в каком месте эти три возможности языка противоречат друг другу. В .NET всё это есть (только аннотации там называются атрибутами) и вполне сосуществует.

reserved
() автор топика
Ответ на: комментарий от reserved

В C# в документации так и написано что использование нетипизированных переменных не безопасно, но ... бла-бла-бла.

vada ★★★★★
()

долгострой не нужен

Я обычно толерантно отношусь ко всяким недосверх языкам,
Scala определенно нужен для того, что бы доказать что и на приличном функциональном языке, те кто не смогли ничего путного написать на java, тоже ничего не напишут.
Groovy тоже нужен как кросплатформенная замена startup скриптов для приложений типа tomcat(те кто видел шэл крипт для запуска tomcat меня поймут)/activemq/jboss и т.д.

Но вот этот язык, я бы не советовал никому даже трогать смотреть, хотя бы до того момента, пока афторы не напишут на нём хотя бы одно годное приложение.

Лучше прочитайте хоть раз Java Puzzlers, после этой книги обычно хотелок новых фич от языка становиться меньше.

Yilativs ★★★★
()
Ответ на: комментарий от reserved

Ну что не понятного?

очередная версия Ceylon - языка программирования со статической типизацией

т.е. у нас фича «Отсечка».
Но!

Типизация параметров на этапе выполнения

т.е. можем отсечку отключить. Да еще

Аннотации, определённые пользователем.

т.е. мы можем напридумывать свои правила «отсечки»

Заявлено что машина супер-пупер защищена от неправильных действий водилы, но водила может всю защиту отключить и поломать что угодно.

vada ★★★★★
()
Ответ на: комментарий от dave

Там можно объявить IEnumerable и IEnumerable<T>. Это будут два разных типа.

Потому что это два разных интерфейса - один System.Collections.IEnumerable а второй System.Collections.Generic.IEnumerable. А на уровне компиляции тебе ничто не мешает эрейзить типы до object в дотнете - получиться та же джава. Вот в обратную сторону хуже - jvm checkcast плюет на генерики.

r ★★★★★
()
Ответ на: комментарий от dave

уже не существует параметрических типов во время загрузки байт-кода Java и его исполнения.

Они существуют: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/reflect/ParameterizedT...

Просто checkcast/instanceof на них плевать. Единственно такой информации не усществует на уровне праметра инстанциирования - поэтому скала например обходит это ограничение манифестами. Небольшие изменения вполне решают проблему. Просто ее не решили в jvm изначально чтобы все сторонние либы не навернулись с ClassCastException. Имхо лучше бы решили ее как в дотнете с их двумя разными типами и все.

r ★★★★★
()
Ответ на: комментарий от dave

Type erasure в .NET и нет

«пока хватает Common Type System» тут подскажет ехидный голос из зала.

r ★★★★★
()
Ответ на: комментарий от r

Потому что это два разных интерфейса - один System.Collections.IEnumerable а второй System.Collections.Generic.IEnumerable. А на уровне компиляции тебе ничто не мешает эрейзить типы до object в дотнете - получиться та же джава. Вот в обратную сторону хуже - jvm checkcast плюет на генерики.

Типы, различающиеся параметрами, могут находится и в одном пространстве:

> type MyClass () =
-   member x.Name = "MyClass";;

type MyClass =
  class
    new : unit -> MyClass
    member Name : string
  end

> type MyClass<'a> () =
-   member x.Name = "MyClass<'a>";;

type MyClass<'a> =
  class
    new : unit -> MyClass<'a>
    member Name : string
  end

> (MyClass ()).Name;;
val it : string = "MyClass"

> (MyClass<int> ()).Name;;
val it : string = "MyClass<'a>"

Возвращаясь к Scala, проблему вижу в интероперабельности Scala и C#. Думаю, что будет хуже, чем в случае Scala - Java, или язык Scala придется изменить (твою ссылку особо не смотрел, но похоже, что они там именно язык Scala поменяли).

dave ★★★★★
()
Ответ на: комментарий от r

Имхо лучше бы решили ее как в дотнете с их двумя разными типами и все.

В .NET нет вариантности уровня Scala. Что-то частичное добавили в четвертой версии, но этого мало.

Вообще, у меня такое чувство, что генерики Scala - это переработка идеи явовских генериков, второе поколение. По-моему именно Одерский стоял у истоков явовских генериков (точно не помню). В .NET немного другая модель, и там делали другие люди (Дон Сайм - автор F#).

dave ★★★★★
()
Ответ на: комментарий от dave

Типы, различающиеся параметрами, могут находится и в одном пространстве:

Дело не в пространствах имен, а что это разные классы. В java List и List<Int> один и тот же класс - List<T>.

Думаю, что будет хуже, чем в случае Scala - Java

В первой реализации Scala.NET наличествует type erasure. Причина - сохранение одинаковой семантики со Scala JVM, и второе - так быстрее выпустить. Но нарушается интероперабельность с .NET. Например в Java фигурально выражаясь работать будет:

scalacode.newJavaList<String>() instanceof java.util.List<?> == true

Аналогичный код C# вернет противоположное:

scalacode.newNETList<String>() is List<String> == false

Потому что скала типы эрейзнула для .NET а C# нет.

r ★★★★★
()
Ответ на: комментарий от r

Так я примерно об этом и пишу (по обоим пунктам).

dave ★★★★★
()
Ответ на: комментарий от dave

Вообще, у меня такое чувство, что генерики Scala - это переработка идеи явовских генериков, второе поколение.

Не совсем. Несмотря на то что компилер генериков для java разрабатывал Одерский - он просто на этом деле специализируется. В скале есть higher-kinded generics:

[code=scala]
scala> class A[X, L[X]](v:L[X]) { def get:L[X] = v }
defined class A

scala> class B[A]
defined class B

scala> class C[A]
defined class C

scala> class D
defined class D

scala> new A[String, B](new B[String]).get
res6: B[String] = B@70d11f32

scala> new A[String, C](new C[String]).get
res7: C[String] = C@5552e7a4

scala> new A[String, D](new D).get
<console>:10: error: D takes no type parameters, expected: one
new A[String, D](new D).get

[/code]

В C# такого не напишешь.

r ★★★★★
()
Ответ на: комментарий от r

Да, про higher-kinded generics я так же считал. В .NET этого тоже нет (надо бы как-нибудь разобраться с этими higher-kind, а то ума пока не приложу, где они мне могут пригодиться).

Собственно, повторю свой прошлый тезис, что более примитивная система генериков Java (и, соответственно то, как это поддерживается на уровне JVM) оказалась удобнее для Scala, чем чуть-чуть более навороченная система из .NET. Похоже на парадокс :)

dave ★★★★★
()
Ответ на: комментарий от dave

а то ума пока не приложу, где они мне могут пригодиться).

trait Container[E, C[x]] { def map[E2](f:E => E2) : C[E2] }

class Lst[E] extends Container[E, Lst] { def map[E2](f:E => E2) = new Lst[E2] }

class Sset[E] extends Container[E, Sset] { def map[E2](f:E => E2) = new Sset[E2] }

scala> new Lst[String].map(x => x)
res13: Lst[String] = Lst@78e782a8

scala> new Sset[String].map(x => x)
res14: Sset[String] = Sset@7de4605c

Обрати внимание на статические типы результатов функции map.

r ★★★★★
()
Ответ на: комментарий от r

Спасибо за пример. С первого раза вникнуть не удалось :)

dave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.