столкнулся с проблемой "unbound name IsBig", хотя он стоит рядом. только благодаря астральной экстрасенсорике догадался поставить там this,
после чего компилятор метод узрел. это так и должно быть?

class X
   IsBig(ty : TypeInfo): bool 
     ...
   methodn() : void  
     def type4(ty)
        when (this.IsBig(ty.TypeInfo)) 
          ..

Здравствуйте, _Claus_, Вы писали:

_C_>столкнулся с проблемой "unbound name IsBig", хотя он стоит рядом. только благодаря астральной экстрасенсорике догадался поставить там this,
_C_>после чего компилятор метод узрел. это так и должно быть?

у меня этот код компилируется без this. Возможно здесь есть еще другие ошибки, что метод IsBig не скомпилирован и не виден.

CU>у меня этот код компилируется без this. Возможно здесь есть еще другие ошибки, что метод IsBig не скомпилирован и не виден.
у меня упростить сильно не получилось, но вот это дает ошибку "unbound IsPrimitiveValue"

class X

    isPrimitiveValue(ty : TypeInfo) : bool                          
        
      true 
                                  
    create_pair(gt1 : FixedType, gt2: FixedType) : void
              
      def fld_load(fld, ty)
        when (true)         
          if (ty.ToString() == "string")
            {}
          else
            if (IsPrimitiveValue(ty))
              {}
            else
              {}
            
      _ = fld_load("Key", gt1.TypeInfo)
      _ = fld_load("Value", gt2.TypeInfo)

если create_pair выбрасываю — все билдится без ошибок.

пользуюсь твоим билдом, но вряд ли патч тут замешан.

_C_>пользуюсь твоим билдом, но вряд ли патч тут замешан.

сам увидел, что ошибся в регистре первой буквы, сорри.

_C_>сам увидел, что ошибся в регистре первой буквы, сорри.

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

CU>у меня этот код компилируется без this. Возможно здесь есть еще другие ошибки, что метод IsBig не скомпилирован и не виден.

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

class X
method() : void
def fld_load(fld, ty) //fld — string, ty — TypeInfo
if (ty.isPersist())
<[ if (el.$(fld:dyn) != 0) $(ty:dyn).load(datamap, el.$(fld:dyn)) else null ]>

из-за того, что в квазицитате я вставил $(ty:dyn) у компилятор стал ругаться, показывая на def fld_load строку
и кричать что ty — строка, а я передаю TypeInfo. связать это с ошибкой в квазицитате было сложно, особенно если учесть
что кроме этого он мне еще всякого рассказал, что никак не помогало, а уводило в сторону.
замена ty:dyn на ty.ToString():dyn избавила меня от кучи странных ошибок. но дойти было непросто — 2 часа перебора всего, чего можно.

Здравствуйте, _Claus_, Вы писали:

_C_> class X
_C_> method() : void
_C_> def fld_load(fld, ty) //fld — string, ty — TypeInfo
_C_> if (ty.isPersist())
_C_> <[ if (el.$(fld:dyn) != 0) $(ty:dyn).load(datamap, el.$(fld:dyn)) else null ]>

_C_>из-за того, что в квазицитате я вставил $(ty:dyn) у компилятор стал ругаться, показывая на def fld_load строку
_C_>и кричать что ty — строка, а я передаю TypeInfo. связать это с ошибкой в квазицитате было сложно, особенно если учесть
_C_>что кроме этого он мне еще всякого рассказал, что никак не помогало, а уводило в сторону.
_C_>замена ty:dyn на ty.ToString():dyn избавила меня от кучи странных ошибок. но дойти было непросто — 2 часа перебора всего, чего можно.

ну о квазицитатах было говорено, что они дают очень плохие сообщения об ошибках, поэтому сейчас никак кроме опытом такие ошибки не узнаются, сам много раз долго пытался что то исправить в них. Часто лучше декомпозировать цитаты в несколько простых и их наполнять отдельно. И еще напрасно используете везде dyn, это довольно редкий идентификатор и он привязывает в области видимости к чему угодно, его советуют использовать только при специальной надобности, а вообще гораздо чаще в этих же местах можно использовать usesite.

CU>ну о квазицитатах было говорено, что они дают очень плохие сообщения об ошибках, поэтому сейчас никак кроме опытом такие ошибки не узнаются, сам много раз долго пытался что то исправить в них. Часто лучше декомпозировать цитаты в несколько простых и их наполнять отдельно. И еще напрасно используете везде dyn, это довольно редкий идентификатор и он привязывает в области видимости к чему угодно, его советуют использовать только при специальной надобности, а вообще гораздо чаще в этих же местах можно использовать usesite.

вопрос тогда к тебе, как специалисту по квазицитатам : уместно ли по подстановкам имен в квазицитатах делать их типизацию? (и как следствие получать странные ошибки).
и второй, который сделал бы бессмысленным первый : если подставляется объект, с типом отличным от PExpr и типов, с которыми работают слова ttype, dyn, name и пр. не будет ли уместным применить известное дотнет-соглашение и вставлять его ToString() представление? это чудовищно упростило бы квазицитирование лично для меня, скорее всего и для других. $ty выглядит куда приятней и понятней чем $(ty.ToString() : usesite).

Здравствуйте, _Claus_, Вы писали:

_C_>вопрос тогда к тебе, как специалисту по квазицитатам : уместно ли по подстановкам имен в квазицитатах делать их типизацию? (и как следствие получать странные ошибки).
типизацию по квазицитатам надо делать, но ее практически нет, поэтому плохие сообщения об ошибках.

_C_>и второй, который сделал бы бессмысленным первый : если подставляется объект, с типом отличным от PExpr и типов, с которыми работают слова ttype, dyn, name и пр. не будет ли уместным применить известное дотнет-соглашение и вставлять его ToString() представление? это чудовищно упростило бы квазицитирование лично для меня, скорее всего и для других. $ty выглядит куда приятней и понятней чем $(ty.ToString() : usesite).

это не совсем верно, цитирование работает через лифтинг и разрешение перегрузок, не все вещи можно просто так приводить через ToString(), это только может ухудшить сообщения об ошибках, тем более неявно. Для наиболее частых применений можно сделать упрощение подстановки как мы сделали для подстановки литератов с помощью $str, так же и для других вещей. Действительно не всегда явно что человек подставляет, и что это ошибка или надо вызывать ToString() : usesite неявно, usesite хоть и используется часто, но не всегда, поэтому он по прежнему указывается явно, ну а в остальных случаях либо указывать явно, либо смотреть может какие то вещи можно упростить конкретно, чтобы это не задевало разные применения.

CU>типизацию по квазицитатам надо делать, но ее практически нет, поэтому плохие сообщения об ошибках.
если возможно управление типизацией, то ее вывод из квазицитаты должен быть наименее приоритетным. тогда сообщения будут адекватными (в моем случае).

Здравствуйте, _Claus_, Вы писали:

_C_>если возможно управление типизацией, то ее вывод из квазицитаты должен быть наименее приоритетным. тогда сообщения будут адекватными (в моем случае).

ну мы немного разное подразумеваем в типизации квазицитаты, я имел в виду обработку компилятором, там действительно ее почти нет, это еще хорошо что dyn отказался принимать другое значение, а вообще часто ест что хочет и только потом оказывается что нет необходимой перегрузки чтобы создать АСТ с заданными параметрами и это дает непонятные ошибки. Если бы проводить типизацию, о чем и Влад говорил, то можно было бы избежать всего этого, а когда это будет неизвестно, может быть в Н2, над этим стоит подумать.

Здравствуйте, _Claus_, Вы писали:

_C_>К стати в некоторых языках компилятор при когда не находит при неверном регистре, в ошибку включает
_C_>"может имеете ввиду вот это", где "это" в правильном регистре. я так привык к этой фиче,
_C_>что думал о чем угодно, только не о регистре.

да есть такое, ту иссью что ты создал, Влад поддержал, сказал что идея хорошая, только не первоочередная, так что возможно это будет.